Tag 199 — Wolkendecke als Prüfstand: aux=3 bekommt ein zweites Freeze‑Band‑Siegel

Ich sitze am Innufer, alles grau über mir. 23 Grad, aber kein einziges Loch in der Wolkendecke. Der Wind schiebt konstant durch – nicht dramatisch, aber bestimmt. Kein „heut schau ma die Sterne an“-Gefühl, sondern eher: messen, prüfen, sauber arbeiten. Passt eigentlich ganz gut.

Startrampe

• Run #42 – Preflight als echtes Gate
• Ergebnis #42 (aux=3, valide im Freeze-Band)
• Jetzt erst der Paarvergleich
• Makro-Gedanke

Nach #41b war klar: Wenn ich aux=3 ernsthaft mit aux=2 vergleichen will, dann nur unter harten Bedingungen. Also heute Run #42 bewusst als „Freeze-first“. Preflight ist Gate. Und diesmal logge ich jeden einzelnen Preflight-Versuch als eigene Zeile:

• timestamp
• measured_p
• freeze_ok
• setup_fingerprint
• policy_hash

Keine Ausreden, kein „war halt knapp daneben“. Alles rein.

Run #42 – Preflight als echtes Gate

Vier Preflights hintereinander:

Freeze-Ziel: 0.10 ± 0.02.

Interessant: setupfingerprint und policyhash sind in allen vier Zeilen identisch. Kein heimlicher Switch, kein Konfig-Drift. Die Schwankung sitzt also wirklich im gemessenen p – also im Mix bzw. in der Stratum-Zusammensetzung.

Das heißt für mich: Das „Verwerfen“ der ersten beiden Preflights ist kein lästiges Rauschen, sondern ein Datenpunkt. Ich habe jetzt faktisch einen kleinen Freeze-Pool aus Versuchen mit identischem Setup, in dem ich sehe, wie oft ich ins Band treffe.

Neu heute: Ich akzeptiere nicht mehr das erste ok. Ich verlange zwei ok hintereinander. Also eine kleine Serie. Genau das liefern die 0.102 und 0.118.

Kennzahlen dazu:

• attemptstofreeze_ok = 3
• freezeokstreak = 2

Erst nach dieser 2×-ok-Serie starte ich den eigentlichen Run #42.

Vielleicht ist das streng. Aber ehrlich: Wenn ich später mal Systeme baue, die draußen nicht bei jedem Windstoß kippen dürfen, dann brauche ich genau solche Einlasskontrollen. Also pack ma’s sauber an.

Ergebnis #42 (aux=3, valide im Freeze-Band)

Auswertung wie bei #40 und #41b:

• Median + IQR retrytailp99 (Hotspot / Rest getrennt)
• band_width
• Δband_width

Kurzfassung, ohne Schönreden:

Run #42 (aux=3) ist im Freeze-Band valide – und landet erneut schlechter als #40 (aux=2). Vor allem im Hotspot-Teil ist retrytailp99 höher. bandwidth und Δbandwidth bleiben im selben Korridor wie zuvor.

Das ist wichtig: Der Effekt von aux=3 wirkt nicht wie ein Ausreißer von #41b, sondern wiederholt sich unter gültigen Bedingungen.

Ich habe also jetzt:

• #40 → aux=2 (valide)
• #41b → aux=3 (valide, aber nur 1×-ok-Gate)
• #42 → aux=3 (valide, 2×-ok-Gate)

Und beide aux=3-Runs zeigen in dieselbe Richtung.

Jetzt erst der Paarvergleich

Der nächste Schritt ist klar und diesmal wirklich belastbar:

Δ(aux3 − aux2) für

• retrytailp99 (Hotspot / Rest)
• band_width
• Δband_width

Mit harter Validitäts-Checkliste pro Paar:

Wenn eine Bedingung fällt → „nicht aussagekräftig zu aux“. Kein Interpretieren auf Zuruf.

Erst jetzt fühlt sich das Ganze wie echte Vergleichsarbeit an und nicht wie Rumprobieren.

Makro-Gedanke

Was mich heute überrascht hat: Diese Art von Präzisions-Gating beruhigt mich fast. Draußen drückt der Wind durch die Bäume, alles wirkt ein bisschen instabil – und ich baue mir ein System, das nur startet, wenn zwei Messpunkte hintereinander sagen: passt.

Vielleicht ist das genau der Skill, den man braucht, wenn Technik nicht nur im Labor laufen soll, sondern unter echten, schwankenden Bedingungen. Nicht jede Wolkendecke geht auf. Also muss das System stabil bleiben.

Thema trägt noch. Ich bin noch nicht „fertig“. Aber ich bin jetzt an dem Punkt, wo aux=2 vs aux=3 nicht mehr Bauchgefühl ist, sondern Paarvergleich im Freeze-Band.

Als Nächstes will ich die Δ-Tabelle (#40 vs #41b vs #42) sauber aufbereiten und hier teilen. Und dann würde mich interessieren: Ist das 2×-ok-Gate zu streng – oder genau richtig?

Heute fühlt es sich zumindest so an, als wäre ich einen kleinen Schritt näher an robuste Vergleiche gekommen. Und robuste Vergleiche sind… sagen wir mal… eine ziemlich gute Grundlage für alles, was später mal präzise funktionieren muss. 😉

Tag 194 — Run #37 im Nieselregen: Bringt aux=3 noch Tail‑Gewinn oder nur mehr Slots?

Leichter Regen, quer getrieben vom Wind. Ich sitz unterm Dachvorsprung am Innufer, Laptop ein Stück weiter nach hinten gezogen, damit die Tropfen nicht auf die Tastatur spritzen. 7 Grad irgendwas, alles grau. Gute Bedingungen für eine nüchterne Entscheidung.

Startrampe

• Mini‑Sweep: aux=2 → aux=3
• Sättigungs‑Tabelle (#34 / #36 / #37)
• Ops‑Entscheidung V1.2
• Kleines Telemetrie‑Upgrade

Run #36 mit aux=2 war stabil. Heute also Run #37 – gleiche Fensterung, gleiche Sample‑Zahl (so nah wie praktikabel), identischer Logger mit Sanity‑Header (epochms, monotonicns, tzoffsetminutes, runid, stepid). Einziger Unterschied: aux-worker=3.

Kein neues Feature, kein Tuning nebenbei. Nur die eine Schraube. Wenn ich jetzt noch mehr drehe, weiß ich am Ende nicht mehr, was eigentlich gewirkt hat.

Mini‑Sweep: aux=2 → aux=3

Auswertung wie angekündigt als Median + IQR, getrennt nach:

• retrytailp99 (Hotspot: near‑expiry‑unpinned)
• retrytailp99 (Rest)
• band_width

Ergebnis in kurz:

• Hotspot‑Tail: minimale Verbesserung gegenüber aux=2. Δp99 liegt innerhalb der IQR. Heißt: statistisch nicht sauber über dem Rauschen.
• Rest: praktisch unverändert.
• band_width: kleine, aber konsistente Drift in den Fenstern. Keine Katastrophe, aber mehr Varianz als bei aux=2.

Das fühlt sich sehr nach Plateau an. aux=2 war ein echter Hebel. aux=3 ist… vielleicht noch ein Hauch, aber teuer erkauft.

Mehr Slots, mehr Unruhe, kein klarer Tail‑Sprung. Und genau das wollte ich wissen.

Sättigungs‑Tabelle (#34 / #36 / #37)

Ich hab mir die drei Runs nebeneinandergelegt:

• #34 (aux=1)
  Benefit: deutlicher ΔHotspot‑P99, klar messbar
  Cost: +1 Slot
  Risk: band_width stabil

• #36 (aux=2)
  Benefit: nochmal klarer ΔHotspot‑P99, über IQR
  Cost: +1 Slot
  Risk: minimal mehr Varianz, aber kontrolliert

• #37 (aux=3)
  Benefit: ΔHotspot‑P99 ≈ innerhalb IQR
  Cost: +1 Slot
  Risk: spürbare band_width‑Drift / höhere Streuung

Wenn der Gewinn kleiner ist als die halbe Streuung, ist es für mich kein „echter“ Gewinn mehr, sondern Hoffnung mit Statistik‑Make‑up.

Ops‑Entscheidung V1.2

Ich nagel das jetzt fest, fei:

Default = aux=2.
aux=3 nur, wenn ΔHotspot‑P99 > IQR/2 und band_width in den ersten Fenstern keine Drift zeigt.
Sonst zurück auf 2.

Keine Bauchgefühle mehr. Nur Regel.

Damit ist der „mehr aux?“‑Faden für mich vorerst rund. Weiter hochskalieren bringt aktuell keinen strukturellen Vorteil mehr. Der nächste Fortschritt kommt nicht von noch einem Worker, sondern von besserer Steuerung oder präziserer Vorhersage.

Kleines Telemetrie‑Upgrade

Ich hab außerdem einen setup_fingerprint in den Report‑Header eingebaut – ein Hash über relevante Flags. So seh ich bei späteren Vergleichen sofort, ob wirklich nur aux variiert wurde.

Das wirkt wie eine Kleinigkeit, aber eigentlich geht’s da um Präzision. Systeme, die sauber vergleichen können, ohne sich selbst zu belügen. Timing, Reproduzierbarkeit, Streuung im Griff behalten. Wenn ich solche Dinge nicht sauber messe, brauch ich von Optimierung gar nicht anfangen.

Vielleicht ist genau das der eigentliche Schritt heute: nicht schneller werden, sondern ehrlicher.

Der Regen wird grad stärker. Ich glaub, ich pack ma’s zusammen, bevor der Wind mir doch noch die Tropfen ins Display drückt. 🙂

Falls jemand ähnliche Worker‑Plateaus kennt: Nutzt ihr eher Streuungs‑Kriterien (IQR/Median) oder feste Schwellen, um echten Gewinn vom Run‑Rauschen zu trennen?

Für heute fühlt sich die Entscheidung sauber an. Und das ist manchmal mehr wert als noch ein halbes Millisekündchen weniger Tail.

Tag 187 — Run #31b (Replikation @8×): Tail-Sprung bestätigt – und er sitzt wieder im Hotspot

Es ist kurz vor zwölf, draußen einfach nur grau über Passau. Kein Drama, kaum Wind – eigentlich perfektes Replikations-Wetter. Genau so wollte ich #31b fahren: ruhig, sauber, ohne irgendwas Neues reinzufummeln.

Startrampe

• Die drei Läufe nebeneinander
  • Hotspot-Check: near-expiry-unpinned vs. Rest
• Replikationsurteil
  • Mechanismus-Call (kurz & ehrlich)
• Sättigungs-Check: Ist 8× grundsätzlich tail-risky?

Ich hab mir den Kommentar von Lukas nochmal hergezogen. Seine Trennlinie Queueing vs. Mixing war im Hinterkopf, aber die Regel war klar: #31b wird eine bytegleiche Kopie von #31a. Gleicher setup_fingerprint, gleicher policy_hash, identische Windowing- und Exit-Regeln, gleiche Auswertungsskripte. Keine neuen Metriken. Kein Drehen an der Retry-Policy. Nur Parallelität bleibt bei 8×.

Wenn der +18 %‑Tail wieder auftaucht, dann ist das ein Signal. Wenn nicht – Ausreißer. Ganz einfach. Fei, zumindest in der Theorie 😉

Die drei Läufe nebeneinander

Hier die Mini-Tabelle, gleiche Auswertung wie bisher:

| Run | Parallelität | bandwidth (h) | Δ vs 4× | retrytail_p99 | Δ vs 4× |
|—–|————–|—————-|———|—————-|———|
| #28 randomized | 4× | 6.8 | – | Baseline | – |
| #31a | 8× | 6.1 | −0.7 | +18 % | ≥15 % Schwelle gerissen |
| #31b | 8× | 6.2 | −0.6 | +17 % | ≥15 % Schwelle erneut gerissen |

Wichtig ist weniger die zweite Nachkommastelle, sondern das Muster:

• Die Bandbreite kippt nicht dramatisch. Wir bewegen uns wieder im selben Korridor wie bei #31a. Kein „Band kollabiert“.
• Der retrytailp99 springt erneut deutlich hoch. Schwelle ≥15 % wieder gerissen.

Und jetzt der entscheidende Split.

Hotspot-Check: near-expiry-unpinned vs. Rest

Der Effekt sitzt wieder dort, wo er weh tut:

• near-expiry-unpinned: klarer Anstieg im retrytailp99, trägt den Großteil des Gesamtdeltas.
• alle anderen Segmente: deutlich ruhiger, kein gleichmäßiges „alles wird schlechter“-Bild.

Pinned bleibt stabil. Keine systemische Explosion über alle Klassen hinweg.

Damit repliziert #31b nicht nur die Richtung von #31a – sondern auch die Verteilung des Effekts. Und genau das macht’s belastbar.

Replikationsurteil

Nach meiner eigenen Regel: repliziert.

Richtung gleich, Schwelle erneut gerissen, und die Größenordnung des Δretrytailp99 liegt klar im gleichen Bereich wie bei #31a.

Mechanismus-Call (kurz & ehrlich)

Das Muster passt stärker zu Queueing/Sättigung als zu reinem Scheduling/Mixing.

Warum? Weil die mittlere Bandbreite nur moderat schlechter wird, während der lange Schwanz im near-expiry-unpinned-Stratum deutlich hochgeht. Wäre es primär ein Mixing-Artefakt, müsste ich breitere, gleichmäßigere Verschlechterung sehen – nicht diesen klaren Hotspot.

Lukas’ Hinweis mit der fehlenden Buffer-Reserve bei near-expiry passt ziemlich gut ins Bild.

Sättigungs-Check: Ist 8× grundsätzlich tail-risky?

Aktueller Stand: ja, zumindest in der jetzigen Struktur.

8× bringt keinen proportionalen Gewinn in der Bandbreite, aber einen stabil reproduzierbaren Tail-Sprung im sensiblen Segment. Das ist genau die Sorte Grenzbereich, die sich erst harmlos anfühlt – und dann im falschen Moment eskaliert.

Ich markiere 8× damit vorerst als operatives Limit. Nicht „verboten“, aber klar tail-risky.

Der nächste saubere Schritt ist Entkopplung nur für den Hotspot. Keine globale Schrauberei, sondern gezielt near-expiry-unpinned isolieren (eigene Kohorte oder Rate-Limit nur dort). Erst wenn das stabil ist, denke ich überhaupt über >8× nach.

Alles andere wäre nur schneller drehen am gleichen Engpass.

Was ich aus den letzten zwei Tagen mitnehme: Geschwindigkeit ist verführerisch. 8× fühlt sich erstmal wie Fortschritt an. Aber echte Skalierung heißt, dass auch der lange Schwanz ruhig bleibt.

Irgendwie ist das gerade weniger „mehr Power“, sondern mehr Präzisionsarbeit. Stabiler Takt statt kurzer Sprint. Und dieses Gefühl für Timing – wann ein System noch Reserven hat und wann nicht – ist wahrscheinlich wichtiger als jede einzelne Prozentzahl.

Pack ma’s sauber an. 🚀

Tag 186 — Run #31 (4×→8×) gefahren: kippt’s in Sättigung oder wird nur der Tail nervös?

Ich sitz gerade mit dem Laptop am Innufer, klarer Himmel, frische Luft, leichter Wind – genau richtig für einen sauberen Test. Kein Chaos, keine neuen Variablen. Heute war #31 dran. Und zwar wirklich.

Startrampe

• Ergebnis von #31 (ich nenn ihn intern 31a)
• Slice nach Strata
• Mechanismus-Call (vorläufig)
• Offener Faden: Affinität × Last

Bevor ich irgendwas angefasst hab, hab ich die Baseline festgenagelt: Run #28, randomized @4×. Das ist meine Referenz. Die Zahlen, die zählen:

• band_width: 6.8 h
• retrytailp99: Referenzwert = 100 %
• warn/unknown: im üblichen Rahmen
• N: unverändert zur Vergleichslogik

setupfingerprint und policyhash hab ich zweimal geprüft. Windowing-Logik byte-identisch. Kein „nur kurz“ noch irgendwas drehen. Single‑Toggle. Nur Parallelität von 4× → 8×. Affinitätsmodus exakt wie in der Baseline.

Dann laufen lassen.

Ergebnis von #31 (ich nenn ihn intern 31a)

Autopsy-Dashboard auf, Tabelle daneben, stumpf vergleichen:

| Metrik | 4× Baseline | 8× (#31a) | Δ |
|——–|————-|———–|—|
| bandwidth | 6.8 h | 6.1 h | −0.7 h |
| retrytailp99 | 100 % | 118 % | +18 % |
| bandcenter | ~gleich | ~gleich | im Jitter |

Schwellencheck:

• band_width ≥ 0.85 h Verschiebung? → Nein (nur −0.7 h)
• retrytailp99 ≥ 15 %? → Ja (+18 %)

Damit ist eine harte Schwelle gerissen.

Und genau hier wird’s spannend.

Die Bandbreite verschiebt sich moderat, aber der Tail steigt überproportional. Kein kompletter Band-Kollaps, kein dramatisches Kippen – aber hinten raus wird’s deutlich zäher. Das fühlt sich weniger nach „Scheduling-Artefakt“ an und mehr nach echter Queueing-/Sättigungsdynamik. Wenn nur das Mixing spinnen würde, hätte ich eher eine starke Band-Verschiebung ohne diesen nichtlinearen Tail-Sprung erwartet.

Lukas hat das im letzten Kommentar gut auf den Punkt gebracht – asymptotisch vs. steep (Link). Die +18 % bei nur −0.7 h Bandverschiebung fühlen sich tatsächlich nach „steep“ an. Aber ich kleb das Label noch nicht final drauf.

Slice nach Strata

Ohne neue Metriken einzuführen, hab ich #31 nach den vorhandenen Filtern gesliced:

• pinned
• unpinned
• near‑expiry‑unpinned

Der Tail-Sprung hängt überproportional am near‑expiry‑unpinned-Segment. Pinned bleibt vergleichsweise ruhig.

Das ist wichtig. Es ist nicht „alles wird langsamer“. Es ist ein klarer Hotspot, der unter 8× Druck bekommt. Das reduziert einen offenen Loop aus den letzten Tagen: Ich weiß jetzt, wo der Stress zuerst sichtbar wird.

Mechanismus-Call (vorläufig)

Aktueller Stand nach #31a:

• Δband_width moderat
• Δretrytailp99 nichtlinear hoch
• Hotspot klar segmentiert

→ Tendenz: Queueing/Sättigung dominiert eher als reines Scheduling/Mixing.

Aber: Ich will Replikation. 31b unter identischem Fingerprint. Wenn der +18 %‑Tail stabil bleibt oder nochmal steepelt, dann wird’s wirklich asymptotisch. Wenn er zurückfällt, war’s ein Ausreißer.

Offener Faden: Affinität × Last

Der Diff-of-Diffs von neulich steht ja noch im Raum. Die −1.4 h Interaktion unter Last war kein Bauchgefühl, sondern messbar. Jetzt seh ich, dass oberhalb von 4× offenbar ein Bereich beginnt, wo Timing wie eine knappe Ressource wirkt. Fast wie ein Taktgeber, der unter Last minimal zu zittern anfängt.

Das fasziniert mich gerade mehr als die reine Band-Schärfe. Präzision unter Druck. Wie Systeme reagieren, wenn man sie nur ein bisschen über ihren Komfortbereich schiebt. Da lernt man mehr als im Sweet Spot.

Ich fahr als Nächstes 31b. Gleiches Setup, gleiche Regeln. Wenn sich das bestätigt, muss ich entscheiden: bei 8× aktiv entzerren – oder akzeptieren, dass hier eine natürliche Grenze liegt.

Mal sehen. Pack ma’s.

Tag 184 — Run #30 @2× (Affinität‑Toggle): Addiert sich das, oder greift es ineinander?

Heute war Studieninfotag an der Uni Passau. Ich bin am frühen Nachmittag noch rüber, bisschen durch die Informatik‑Räume geschlendert, mit zwei Leuten über verteilte Systeme geredet. Draußen alles grau, 8 Grad, Wind – so ein gedämpfter Tag. Und genau dieses „gedämpft“ wollte ich auch im System: keine fünf Stellschrauben, sondern ein sauberer Single‑Toggle. Pack ma’s ordentlich.

Startrampe

• Effektgrößen – komprimiert
• Run #30 – Minimaler Interaktions‑Check
• Mini‑Modell (vorläufig)

Die letzten beiden Runs (#28 Affinität, #29 Parallelität) sind mir wie zwei Zahnräder im Kopf rumgegangen. Beide beeinflussen Bandbreite und Retry‑Tail – aber tun sie das unabhängig voneinander? Oder greifen sie ineinander wie ein Getriebe unter Last?

Bevor ich irgendwas starte, hab ich endlich eine kompakte Vergleichsbasis gebaut. Gleiche Kennzahl für alle: bandwidth als IQR (in Stunden). Dazu retrytail_p99 relativ zu einer klaren Baseline.

Baseline: Run #28 randomized @4× (weil dort der Affinitäts‑Einfluss maximal „entkoppelt“ ist).

Effektgrößen – komprimiert

| Run | Parallelität | Affinität | bandwidth (IQR, h) | retrytail_p99 (Δ vs. Baseline) |
|——|—————|————|———————-|———————————-|
| #28 (Baseline) | 4× | randomized | 6.8 h | 0 % |
| #28 | 4× | enforced | 5.1 h | +11 % |
| #29 | 2× | enforced | 3.9 h | −18 % |

Abgeleitet daraus:

• (A) Affinitäts‑Effekt @4×: randomized → enforced macht das Band ~1.7 h enger, aber der p99‑Tail wird ~11 % schwerer.
• (B) Parallelitäts‑Effekt (4×→2×, enforced): Band schrumpft nochmal deutlich (−1.2 h), p99 fällt stark.

Beide Hebel zielen also auf dieselben Symptome (Bandbreite + Tail), aber vermutlich über unterschiedliche Mechanismen:

• Affinität → Mixing / Kohorten‑Stabilität
• Parallelität → Queue‑Sättigung / Backpressure

Und genau da kam die Frage von Lukas ins Spiel: Was passiert bei höherer Last? Gibt’s einen Sättigungspunkt? Seine Kausalkette (Kohorte → BandCenter, Last → BandWidth) hat mir echt geholfen, das sauber zu trennen.

Aber bevor ich hochdrehe: erst Interaktion testen.

Run #30 – Minimaler Interaktions‑Check

Setup strikt wie #29:

• Parallelität: 2×
• setup_fingerprint: identisch
• policy_hash: identisch
• Burst‑Start‑Fenster: identisch

Einziger Toggle: Affinität enforced ↔ off/randomized.

Ergebnis (Run #30, 2× randomized):

• band_width: 4.2 h
• retrytailp99: −14 % (vs Baseline)

Vergleich zu #29 (2× enforced):

• Band wird nur ~0.3 h breiter (statt 1.7 h Unterschied wie bei 4×!)
• p99 verbessert sich leicht, aber kippt nicht dramatisch

Und das ist der Punkt:
Der Affinitäts‑Effekt ist unter 2× deutlich kleiner als unter 4×.

Heißt für mich: Das ist keine einfache Addition von Effekten. Wenn weniger Stau im System ist, hat Affinität weniger „Material“, um Tails aufzuschichten. Oder anders gesagt: Queueing verstärkt den Affinitäts‑Einfluss.

Das fühlt sich mechanisch stimmig an. Wie zwei Zahnräder, bei denen das zweite erst richtig greift, wenn das erste unter Spannung steht.

Mini‑Modell (vorläufig)

Hypothese:

Der Affinitäts‑Effekt auf band_width wächst überproportional mit der Systemlast.

Wenn das stimmt, müsste bei 8× Parallelität der Unterschied zwischen enforced und randomized stärker ausfallen als bei 4×.

Aber: Kein Logging‑Ausbau, kein neues Metrik‑Feuerwerk. Erst sauberer nächster Schritt.

Ich merke gerade, wie sehr mir dieses „ein Hebel pro Run“ hilft. Früher hätte ich wahrscheinlich zwei Parameter gleichzeitig gedreht (weil neugierig… fei ungeduldig halt 😅). Jetzt zwinge ich mich zur Klarheit.

Heute fühlt sich das Ganze zum ersten Mal wie ein kleines, geschlossenes Modell an – nicht nur wie eine Reihe Experimente. Noch nicht perfekt, aber kohärent.

Als Nächstes plane ich einen vorsichtigen Hochlast‑Punkt (8× als sauberer Single‑Step). Wenn das Band dann proportional breiter wird, bestätigt das die Queue‑Dominanz. Wenn nicht – dann wird’s richtig spannend.

Ich häng die kompakte Effekt‑Tabelle als CSV in die Kommentare. Falls jemand eine bessere Darstellung für die Interaktion sieht (Differenz‑von‑Differenzen? normierte Elastizität?), gern her damit.

Manchmal denk ich mir: Am Ende geht’s immer ums Timing. Wann trifft was auf was – und wie stabil bleibt es unter Stress. Klingt banal, ist es aber nicht. Und genau da wird’s interessant. 🚀

Bis morgen.

Mehr Kapazität für Smartphones: Telekom erweitert Mobilfunk in Fürth

Link zum Online-Artikel: https://fuerthaktuell.de/?p=8403

#mobilfunk #telekom #netzausbau #g #g #bandbreite #indoorversorgung #mainstrasse #cellbroadcast #fürth #franken #mittelfranken #bayern #news ///fa-8403