Leitungsauslastung AVM 5530 Deutsche Glasfaser

Zitat

ITU G.983.4

On the other hand, the algorithmic details of how the OLT applies the reported status information, the entire specification of the traffic monitoring DBA method, as well as the details of the OLT upstream scheduler, which is responsible for the BWmap generation, are outside the G-PON TC layer scope, and their implementation is left to the OLT vendors.

Ja, Du hast Recht, das ist deutlich klarer in den ITU Standards vorbereitet als meine saloppe Formulierung es beschreibt, aber die Geheimsauce der Hersteller, bleibt auch weiterhin geheim... nur das notwendige Protokoll fuer die Informationsuebermittlung ist standardisiert damit DBA funktionieren kann.

Zitat von pufferueberlauf

aber das ist trotzdem IMHO immer noch ein valides Mass fuer die Auslastung des PON Uploads...

Wie würdest du das denn daraus ableiten wollen?

Ich habe explizit keine Idee, wie groß ein Sendeslot ist, aber als kleine Spielerei nehme ich mal die MTU-Size.

Bei 1,25 Gbps komme ich auf ca. 900.000 Paketen bei einer MTU von 1400. Wie gesagt, nur um ein bisschen grob zu rechnen.

Sprich, ich gehe einfach mal von gleich vielen Slots aus. Das kann natürlich völlig falsch sein.

Würden allen Teilnehmern die gleiche Anzahl an Slots haben, kämen sie rechnerisch auf ca. 20 Mbps Bandbreite bei 64 Teilnehmern. Diese werden ihnen aber bestimmt nicht auf Verdacht fest zugewiesen.

Ein ACK-Paket wird maximal 60 Bytes groß. Gehen wir von 1300 Bytes echter Nutzlast aus. Dann liegt da ein Faktor von 21 zwischen.

Senden ein Großteil der ONTs fast nur ACKs, belegen sie trotzdem jede Menge Slots (bei vereinfacht ein Slot = ein TCP-Paket), aber es wird nur 1/21 der möglichen Nutzlast übertragen.

Wie willst du bei so einer möglichen Spreizung die Auslastung des Segments abschätzen wollen?

Da müsste man jetzt tiefer einsteigen. Wie groß ist ein Slot wirklich, wie werden darin TCP-Pakete (Layer 4) eingepackt? Wenn die Slots größer sind und mehr als ein Paket aufnehmen, dann wird die Spreizung nur noch größer und die Abschätzung ungenauer.

Die logarithmische Darstellung ist nicht hilfreich. Aber es lässt sich schon sehen, dass die beiden Linien deckungsgleich sind. Der Upload also angeblich mit 1,25 Gbps voll ausgelastet ist. Dass das nicht sein kann, sollte klar sein, oder?

Zitat von mbo77

Wie würdest du das denn daraus ableiten wollen?

Jeder ONT sieht die Sendeslotzuteilung fuer das ganze Segment und kann so einfach berechnen welcher Anteil der letzten X Sekunden oder Millisekunden der Upload in Benutzng war und zu welchem Anteil er Idle war... das ist ein ziemlich gutes Korrelat fuer die Auslastung des PON Uploads.... (von AUsnahmen wie geteilten XGS/XG PON Segmenten abgesehen, senden alle ONTs immer mit der maximalen Rate, d.h. der Duty-Cycle / die relative Auslastung laesst sich auch als Rate darstellen).

Zitat von mbo77

Ich habe explizit keine Idee, wie groß ein Sendeslot ist, aber als kleine Spielerei nehme ich mal die MTU-Size.

Das scheint variabel zu sein... der OLT teilt die so zu wie er/sie/es es am optimalsten haelt (optimal fuer den OLT nicht zwingend fuer einzelne ONTs ).

Zitat von mbo77

Ein ACK-Paket wird maximal 60 Bytes groß. Gehen wir von 1300 Bytes echter Nutzlast aus. Dann liegt da ein Faktor von 21 zwischen.

Jein, (unter Deiner Annahme fixer Sendeslots) der Upload des Segments wird trotzdem im Gegenwert einer vollen MTU ausgelastet, weil dieser Slot fuer andere Nutzer verloren ist, nur der ACK sender koennte statt eines ACKs etwas mehr senden... aber halt auch nur genug um den Slot zu fuellen.

Zitat von mbo77

Senden ein Großteil der ONTs fast nur ACKs, belegen sie trotzdem jede Menge Slots (bei vereinfacht ein Slot = ein TCP-Paket), aber es wird nur 1/21 der möglichen Nutzlast übertragen.

Das ist richtig, unter der Annahme, dass jedem einzelnen ACK ein fixer Sendeslot zugeteilt wird.

Zitat von mbo77

Wie willst du bei so einer möglichen Spreizung die Auslastung des Segments abschätzen wollen?

Easy, die Upload Auslastung des PON Segments ist der Anteil der genutzten Sendeslots...

Zitat von mbo77

Da müsste man jetzt tiefer einsteigen. Wie groß ist ein Slot wirklich, wie werden darin TCP-Pakete (Layer 4) eingepackt? Wenn die Slots größer sind und mehr als ein Paket aufnehmen, dann wird die Spreizung nur noch größer und die Abschätzung ungenauer.

PON verpackt heutzutage i.d.R. L2 Frames, ohne sich fuer L3 oder L4 zu interessieren.

Zitat von mbo77

Die logarithmische Darstellung ist nicht hilfreich. Aber es lässt sich schon sehen, dass die beiden Linien deckungsgleich sind. Der Upload also angeblich mit 1,25 Gbps voll ausgelastet ist. Dass das nicht sein kann, sollte klar sein, oder?

Da bin ich bei Dir, maximal unklar was der Graph genau zeigt....

Dass der Slot selbst für das einfachste ACK "verloren" ist, ist ja gerade der Witz an dem Graphen.

Er zeigt ja nicht an, wie viele Slots zugewiesen oder überhaupt in Nutzung sind, sondern es wird der Wert "Bytes/s" angegeben/berechnet. Und das kann die FB aus den bekannten Gründen gar nicht berechnen. Woher soll sie wissen, ob da 60 Bytes ACK oder 1300 Bytes andere Nutzlast enthalten ist?

Beim Download sehr wohl, denn da ist die verschlüsselte Nutzlast des Segments ja für jeden einsehbar.

Da wir den Download kennen, können wir grob im Bereich 1:5/1:10 abschätzen, wie groß der Upload tatsächlich ist. Über den Daumen also 10-20 Mbps. Die FB berechnet aber 1,25 Gbps. Das liegt nicht nur knapp daneben, sondern hat mit dem echten Wert gar nichts zu tun. Wir wissen auch nicht, wie dynamisch Slots umverteilt werden, wenn ein ONT tatsächlich zu senden anfängt (also ich weiß es nicht). Selbst wenn bei 20 Teilnehmern alle Slots erstmal zugeteilt sind, werden diese ja dynamisch neu vergeben, wenn sie gebraucht werden.

Von so einem System erwarte ich, dass wenn ich zwei Teilnehmer im Segment habe und diese zeitgleich mit 500 Mbps senden wollen und sonst nicht viel los ist, das System dies dynamisch bewältigt und alle anderen Teilnehmer noch genügen ACKs für ihren Downstream durchbekommen.

Das müsste man mal testen, wenn wir zwei Teilnehmer finden, die am selben OLT hängen.

Zitat von mbo77

Er zeigt ja nicht an, wie viele Slots zugewiesen oder überhaupt in Nutzung sind, sondern es wird der Wert "Bytes/s" angegeben/berechnet. Und das kann die FB aus den bekannten Gründen gar nicht berechnen. Woher soll sie wissen, ob da 60 Bytes ACK oder 1300 Bytes andere Nutzlast enthalten ist?

Ja, prozentualle Auslastung des Uploads waere ein besseres Mass, aber ist ja ueberhaupt nicht klar was der Plot da zeigt. Das man die temporale Auslastung auch in Bit/Sekunde umrechnen kann ist dem Umstand geschuldet, dass bei GPON immer mit den vollen Rate ngesendet ewitd (aehnlich wie bei Ethernet).

Zitat von mbo77

Beim Download sehr wohl, denn da ist die verschlüsselte Nutzlast des Segments ja für jeden einsehbar.

Jein, Du weisst auch da nicht was da an Padding in den Paketen haengt. Aber ich stimme zu, die Unsicherheit ist im Upload groesser, aber auch da gilt, mir egal ob die Nachbarn ihre Slots mit Daten fuellen oder nicht, deren Splots stehen mir nicht zu Verfuegung...

Zitat von mbo77

Da wir den Download kennen, können wir grob im Bereich 1:5/1:10 abschätzen, wie groß der Upload tatsächlich ist. Über den Daumen also 10-20 Mbps. Die FB berechnet aber 1,25 Gbps. Das liegt nicht nur knapp daneben, sondern hat mit dem echten Wert gar nichts zu tun. Wir wissen auch nicht, wie dynamisch Slots umverteilt werden, wenn ein ONT tatsächlich zu senden anfängt (also ich weiß es nicht). Selbst wenn bei 20 Teilnehmern alle Slots erstmal zugeteilt sind, werden diese ja dynamisch neu vergeben, wenn sie gebraucht werden.

Oh, wie gesagt, en Graphen traue ich nicht ueber den Weg, bzw. die zeigen wohl nicht was ich denke dass sie zeigen sollten. Wo kommen die eigentlich her?

DBA ist Vendor-Geheimnis... aber ich habe gerade von Experimenten gehoert wo es mehrere 100 ms gedauert hat um in einem GPON Segment von 8 auf die vertraglichen 300 Mbps im Upload hochzuskalieren...

Zitat von mbo77

Von so einem System erwarte ich, dass wenn ich zwei Teilnehmer im Segment habe und diese zeitgleich mit 500 Mbps senden wollen und sonst nicht viel los ist, das System dies dynamisch bewältigt und alle anderen Teilnehmer noch genügen ACKs für ihren Downstream durchbekommen.

Wenn dann nur kurzfristig, ueblicherweise werden alle Nutzer auf ihre vertraglichen Maximalraten gedrosselt (mit ein bisschen Burstallowance). Wobei der OLT schon auf eine basale Fairness achten sollte unter Last (aber was ist da fair, jeder die gleiche minimale Rate, oder die Kapazitaet aufgeteilt nach dem Verhaeltnis der vertraglichen Maximalraten?).

Zitat von mbo77

Das müsste man mal testen, wenn wir zwei Teilnehmer finden, die am selben OLT hängen.

+1; das waere in der Tat ein interessantes Experiment... DBA-reverse engineering

Die Grafiken der Auslastung kann man sich als Push-Service von der Fritzbox senden lassen.

Und wenn ich mir die Legende ansehe, ist AVM da eigentlich recht eindeutig. Aber wir beide sind uns da einig: Das kann keine korrekte Berechnung sein. Das geht statistisch schon nicht auf.

Laut Statista lag der "Datenverbrauch" 2023 bei 320 GB/Monat. Lass uns großzügig sein und annehmen, FTTH-Kunden haben einen höheren Datenbedarf. Also mal 500 GB zum Rechnen nehmen.

Ich nehme einfach mal 16h aktive Nutzung je Tag an.

500 GB / 30 Tage / 16 Stunden ~ 1 GB/h ~ 2,2 Mbps Downstream

Wie im letzten Beitrag zu lesen, sprach er von 20 Teilnehmern. 20 * 2,2 Mbps = 44 Mbps

Sieht mir im Graphen recht plausibel aus.

Und jetzt legen wir den typischen Bandbreitenbedarf im Upload im Verhältnis 1:10 - 1:4 an und kommen auf irgendwas 4 - 10 Mbps. Die Slots mögen schon mal großzügig verteilt worden sein. Diese werden aber dynamisch dort vergeben, wo sie gebraucht werden.

Die grüne Linie (achte auf die Legende) zeigt lediglich, dass sehr viele idle Slots im System aktiv sind. AVM schreibt aber, das wäre der Durchsatz in Bytes/s.

Erfgo: AVM sollte gar nicht erst versuchen, aus den verfügbaren Zahlen etwas über den Upload auszusagen.

Zitat von mbo77

Ob man den Werten tatsächlich trauen kann, bezweifle ich auch ein bisschen.

Demnach lag seine eigene Auslastung zum Ende hin bei fast 10 Mbps über den Tag verteilt. Das ist erstaunlich hoch.

"seine" 10 Mbps über den Tag verteilt kommt gemittelt ganz gut hin. Hier sitzen zwei Leute im Homeoffice mit Dauersitzungen in Teams, dazu den ganzen Tag auf Azure Clouds rumdaddeln, private Backups vom NAS, automatisierte Speedtests und abends IP-TV.

e16 Gibt es Neuigkeiten bezüglich der Anzahl der ONTs im Segment sowie der genutzten Bandbreite?

Zitat von fnord

e16 Gibt es Neuigkeiten bezüglich der Anzahl der ONTs im Segment sowie der genutzten Bandbreite?

Langsam nimmt die Nutzung zu. Vorgestern waren es noch 15-20, seit gestern 20-25. 22 Anschlüsse hängen im Segment. MDCC splittet nur 1:32

Die Darstellung ist stark gerundet. Selbst wenn ich mit meinen 1000 MBit/s Download für eine Stunde intensiv nutze, ist auf dem Diagramm nicht mehr als eine kleine Spitze zu sehen.

Unklar was das genau zeigen soll und ob das auch zeigt was es zeigen soll:

Die hell-grünen "Spitzenwerte" sind in Downstream-Richtung erkennbar variabler und geringer als in Upstream. Und der Upstream zeigt eigenartig regelmässige Spitzen in der dunkle-grünen Linie dreimal täglich (ausser am 9. 2. da fehlt die erste Spitze...)

Aber trotzdem ganz interessant was AVM da so zeigt... (auch die Information zu FEC)

Die Upload-Auslastung kannst du ignorieren. Das hatten wir hier schon ein paar Mal.

Zitat von mbo77

Die Upload-Auslastung kannst du ignorieren.

Das ist momentan wohl der pragmatische Ansatz. Ich fände es allerdings noch besser, wenn AVM erklären würde was mann da sehen soll und dafür sorgt dass das auch sichtbar ist

Aus dem Grund werden die es wohl eher verstecken.

Zitat von pufferueberlauf

Und der Upstream zeigt eigenartig regelmässige Spitzen in der dunkle-grünen Linie dreimal täglich (ausser am 9. 2. da fehlt die erste Spitze...)

Alle 8h läuft mein Cloudbackup, außer am 09.02. um 4:00 Uhr

Ach ja, das scheint jeweils ein Wert pro Stunde zu sein, da ist es dann IMHO gar nicht so unwahrscheinlich, dass ausserhalb langer Up-/Downloads die Durchschnittswerte ziemlich niedrig liegen. Das waere eine passable Erklaerung fuer die dunkel-grünen Werte, aber da fehlt immer noch eine Idee was die hell-grünenen Datenpunkte zeigen...

Zitat von pufferueberlauf

hell-grünenen Datenpunkte

Auslastung des Segments.

Das geht aber tatsächlich besser und vor allem transparenter.

Vor allem die Bestimmung des Upstreams ist erklärenswert. Hier als Vergleich das Bildchen aus dem Wochenreport meiner 5530:

Oh wow, das viele Endgeräte in deinem Netz. HubeBube

Bei mir passt das mit dem Upload grundsätzlich ganz gut, der Hellgrüne Punkt bewegt sich auch wenn ich mal ordentlich was über die Leitung bewege.
Was ich nur ein wenig schräg finde, meine PON-ID hat sich vor einer Weile über Nacht einfach geändert, ohne reconnect.

Ein ONT sieht bestenfalls welche Transmitslot den anderen ONTs zugewiesen werden, aber nicht ob die auch fuer Daten genutzt werden oder fuer idle frames... zumindest theoretisch moeglich, dass Euer ISP da unterschiedliche Strategien faehrt die Upload Slots zuzuweisen...

Ich finde eher absonderlich, das Upstream bei mir und e16 am Anschlag ist, bei einer grundsätzlich anderen Anzahl an ONTs/Gf-Router im Segment. Bei millen ist es ein anderes Bild.

Die spontane Änderung der ONT ID habe ich ebenfalls bemerkt, jedoch keine Erklärung hierfür.