Leitungsauslastung AVM 5530 Deutsche Glasfaser

Das kann nicht die echte Auslastung sein. Das hatten wir schon mal.

hmm - testet evtl. doch mal das, was real vom Internet rein/raus-geht bevor Router Satistiken evtl. ein falsches Bild projizieren.
Das Standardtool (bei den Linux'ern) ist nperf.com. Anbei Beispiel meines 1 Gb/s. Anschlusses (ist faktisch DeutscheGlasfaser, die angezeigte "Telekom" ist nur Backup mit erheblich geringerer Bandbreite). Der Test läuft via IP4 (einstellbar in der Option Serverauswahl).
Warum dieser Post - DeutscheGlasfaser hat gewisse Probleme und ich lese gerade das Forum quer mit Bezug auf Meldungen.

Zitat von HubeBube

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.

Ja aber genau das kann passieren, wenn bei Euch der Default ist alle Sendeslots (aktiven) ONTs zuzuweisen und dann dynamisch umzuverteilen. Bei millen sieht es so aus als waere ohne Last nur jeder 10. Sendeslot einem ONT zugewiesen. Aber das ist Kaffeesatzleserei mit Spekulatius meinerseits.

millen hat auch eine PON ID, die gibt es bei mir nicht. Lediglich eine PON Seriennummer, die der Modem ID entspricht.

millen Welche Version des FRITZ!OS verwendest Du?

Zitat von HubeBube

millen hat auch eine PON ID, die gibt es bei mir nicht. Lediglich eine PON Seriennummer, die der Modem ID entspricht.

millen Welche Version des FRITZ!OS verwendest Du?

Ich habe auch keine PON ID, nur eine ONU ID = 73.
(5590 mit FRITZ!OS 8.02 / Modem-Software-Version: 1.20.0_3.19.1.3.68

Moin,

ich habe mir Daten aus meiner Fritzbox mal genauer angeschaut, da ich seit kurzem eine 5590 im Einsatz habe.

In den erweiterten Suppportdaten findet man einen Abschnitt "FIBER 7 Day per Hour Stats" mit Einträgen wie diesen:

Das dürfte die Basis der Auslastungsgrafik sein.

Nun ist es bein GPON Protokoll so, dass ein ONU sehr gut die Gesamtauslastung eines PON ermitteln kann. Dazu muss man ein wenig tiefer in das GPON Protokoll einsteigen.

Grundsätzlich werden alle Daten, Downstream wie Upstream, in Frames von 125 µs Länge übertragen. Im Downstream ergibt das eine Framelänge von 38880 Bytes, im Upstream von 19440 Bytes. Der Downstream geht im Broadcastverfahren an alle ONUs, im Upstream wird vom OLT jedem ONU ein Zeitschlitz im 125 µs langen Upstreamframe zugewiesen (TDMA Verfahren).

Die Zuweisung der Upstream-Zeitschlitze, die eine variable Länge haben, erfolgt über das sog. BWMap-Feld, dass in jedem Downstreamframe mitgesendet wird. In diesem Feld wird für jeden aktiven ONU am PON der Beginn und das Ende des Zeitschlitzes mitgeteilt, in dem er senden darf. Dieses Feld ist, im Gegensatz zu den Datenblöcken, nicht verschlüsselt und kann von allen ONUs ausgelesen werden. Jeder ONU sucht sich seinen Eintrag anhand seiner ID raus. Die Festlegung der Zeitschlitzlänge selbst erfolgt durch den OLT über DBA (Dynamic Bandwidth Allocation) Algorithmen. Da sind mehrere Verfahren definiert. Für den Downstream ist es einfach, denn da kennt der OLT den Füllgrad seiner Warteschlangen je ONU und kann entsprechend die Daten im Downstream-Frame verteilen.

Beim Upstream wird es schwieriger. Das einfachste Verfahren ist die Ableitung der benötigten Zeitschlitzlänge aus dem Verhältnis Idle- vs. gefüllten Paketen. Der ONU muss, wenn er keine Daten zu übertragen hat, Idle-Pakete in seinem Zeitschlitz übertragen. Vereinfacht gesagt wird der zugeteilte Zeitschlitz je ONU quasi mit jedem Idle-Paket kleiner, bis er eine Größe erreicht hat, in die nur noch die Idle-Pakete passen.

Sobald wieder Daten vom ONU im Upstream gesendet werden, wird der zugewiesen Zeitschlitz vom OLT wieder vergrößert. Natürlich wird dabei auch auf eine faire Verteilung unter allen ONUs geachtet. Ein erweitertes Verfahren beruht darauf, dass der ONU dem OLT den Füllgrad seiner Output-Warteschlangen aktiv mitteilt und diese Information vom OLT mit verwendet wird.

Über diese Informationen hat die Fritzbox nun alle Informationen, um die tatsächlich Auslastung des PONs zu ermitteln.

Im Downstream kennt die Fritzbox die Anteile aller ONUS durch das Broadcastverfahren. Die Daten an die anderen ONUs selbst können zwar aufgrund der Verschlüsselung nicht gelesen werden, jedoch kann die jeweilige Länge der sogenannten GEM-Pakete für jeden GEM-Port ermittelt werden. Die GEM-Ports identifizieren mit ihrer jeweiligen ID das Ziel (ONU) des GEM-Pakets. Die aktuell zugewiesen GEM-Port-IDs der eigenen Fritzbox stehen auch in den Supportdaten.

Für den Upstream kann die Box die Auslastung des PONs anhand der BWMap ermitteln. Aus diesen Daten zusammen wird dann die Used- bzw. Idle-Rate des gesamten PONs ermittelt.

Noch was zur Grafik in der Mail. Die durchgezogene dunkelgrüne Linie zeigt einfach nur die gemittelte eigene Datenrate, die tatsächlich genutzt wurde.

AVM hat für den Upstream dann eine etwas ungewöhnliche Darstellung gewählt - Die steht einfach auf dem Kopf!

Zitat von gponner

Noch was zur Grafik in der Mail. Die durchgezogene dunkelgrüne Linie zeigt einfach nur die gemittelte eigene Datenrate, die tatsächlich genutzt wurde.

Ja, das ist relativ eindeutig, die Werte sind IMHO so niedrig weil hier ein Mittelwert/Stunde angezeigt wird und die meiste Zeit ist halt nix los ;).

Ansonsten Dank fuer die schoene Erklaerung, ich bin zu einer aehnlichen Erklaerung gekommen, allerdings ist halt die offene Frage warum bei der Upstream Gesamtauslastung bei einigen nur Werte um 100% Kapazitaet gezeigt werden.

Bei mir liegt die hellgrüne Linie bei ca. 100 MBIT/s. Das deckt sich mit der Upstream Overhead Rate aus den Supportdaten, die sich bei mir zahlenmäßig irgendwo bei 90000 kBit/s bewegt. Die freie Kapazität des PONs im Upstream ist die Upstream Idle-Rate. Die kann das ONU exakt aus der BWMap ermitteln.

Die Werte verändern sich bei Belastung auch entsprechend. Ich habe das mal mit IPerf über eine IPSEC-Verbindung von meinem Homeoffice zur Firma getestet. Mein Anschluss hat 300/150 und ich habe den mal für zwei Stunden jeweils im Up- und Download entsprechend ausgelastet. Man sieht in der stündlichen Fritzbox-Statistik genau die dieser Datenrate entsprechenden Werte.

Grundsätzlich wird ja ohne Ende über die Nachteile des 1:32 Splittings bei GPON diskutiert. Das Ganze ist im Alltagsbetrieb vollkommen ohne Belang. Die Trafficverteilung in einem typischen Anschlußgebiet führt im realen Leben niemals zu einer Beschränkung der individuellen Rate.

Meinen Test, den ich durchgeführt habe, müssten 8-10 Teilnehmer an meinem PON gleichzeitig durchführen, um überhaupt nur irgendeine individuelle Verminderung zu spüren!! Die Wahrscheinlichkeit dafür kann sich jeder sebst ausrechnen (Stichwort: Erlang-Verteilung).

Auch bzgl. der Latenzen hat das GPON Protokoll viele Vorteile. Aufgrund der 8 KHz Taktung der Up- und Downstream-Frames hat jeder Teilnehmer am PON 8000 mal pro Sekunde die Chance ein Paket loszuwerden bzw. zu bekommen. Das Protokoll lässt nicht zu, dass ein Teilnehmer einen kompletten PON nur mit seinen Daten sättigt! 8000 mal pro Sekunde wird jeder Teilnehmer auf jeden Fall bedient.

Bezüglich des Splitnachteils wird um des Kaisers Bart diskutiert ...

Den Nachteil habe ich so auch noch nie gesehen. Die Verschreckung kommt sicherlich von Erfahrungswerten im Kabel. Aber da hängen mehrere hundert Haushalte an weniger Bandbreite.

Zitat von pufferueberlauf

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...

Die Box kann das schon exakt ermitteln. Aus der BWMap geht die exakte Zuteilung des Slots je ONU hervor. Diese, eigentlich zeitliche, Zuteilung ist dort in Bytes innerhalb des Frames von...bis ausgedrückt. Wenn ein ONU einen Slot von 1000 Bytes innerhalb des Frames zugeteilt bekommen hat, ist die daraus resultierende Bandbreite für die anderen verloren. Wenn keiner was zu übertragen hat, sind diese Zuteilungen auch für alle kleiner bzw. kürzer.

Zitat von mbo77

Den Nachteil habe ich so auch noch nie gesehen. Die Verschreckung kommt sicherlich von Erfahrungswerten im Kabel. Aber da hängen mehrere hundert Haushalte an weniger Bandbreite.

Beim Kabel wurde in den alten DOCSIS Varianten CDMA gefahren und erst in den neueren TDMA. Allerdings mit ganz anderen Frequenzen und Bandbreiten.

Da gilt immer noch die nachrichtentechnische Regel, trotz aller ausgefeilten Codierungen, höhere Frequenz ergibt mehr Informationen. Dabei gilt: Gbit/s entspricht GHz!

Kabel liegt im Upstream bei max 0,06 GHz, im Downstream bei max. 0,9 GHz. Das müssen sich alle Teilnehmer teilen! Und das sind häufig mehr als 100 pro Strang.

GPON hat 1,25 GHz im Upstream und 2,5 GHz im Dowstream, meistens auf 32 Teilnehmer, zumindest im Telekom-Umfeld, aufgeteilt.

Zitat von gponner

Bei mir liegt die hellgrüne Linie bei ca. 100 MBIT/s. Das deckt sich mit der Upstream Overhead Rate aus den Supportdaten, die sich bei mir zahlenmäßig irgendwo bei 90000 kBit/s bewegt. Die freie Kapazität des PONs im Upstream ist die Upstream Idle-Rate. Die kann das ONU exakt aus der BWMap ermitteln.

Die BWMap zeigt aber nur welche Slots an welchen ONT verteilt wurden, und nicht ob diese tatsaechlich auch genutzt werden. Ein OLT koennte da IMHO unterschiedliche Strategien fahren z.B.:

a) alle Upload slots werden zugewiesen und alle ONTs senden staendig "idle cells", bei Lastwechsel werden alle Slots umverteilt so dass die ONTs mit echter Last innerhalb des vertraglichen Kapazitaetskorridores befriedigt werden, wenn moeglich.

b) Nur ein Teil der Upload slots werden regulaer verteilt der Rest bleibt als Reserve bei Lastwechsel werden ONTs aus der Reserve bedient (wenn sie ihr statisches Kontigent verbraucht haben)

Das hat fuehrt dann zu unterschiedlichen Plots der Auslastung... aber ist natuerlich Spekulation.

Zitat von gponner

Grundsätzlich wird ja ohne Ende über die Nachteile des 1:32 Splittings bei GPON diskutiert. Das Ganze ist im Alltagsbetrieb vollkommen ohne Belang. Die Trafficverteilung in einem typischen Anschlußgebiet führt im realen Leben niemals zu einer Beschränkung der individuellen Rate.

Das ist IMHO etwas mutig... niemals ist eine laaaange Zeit, Aber ja, bei durchschnittlicher Auslastung pro Anschluss (gemittelt ueber die Spitzenzeit) von <10 Mbps sind da wohl Reserven fuer die naehere Zukunft... das mag sich aber aendern sollte sich denn endlich eine Killerapplikation fuer schnelle Anschluesse finden.

Zitat von gponner

Meinen Test, den ich durchgeführt habe, müssten 8-10 Teilnehmer an meinem PON gleichzeitig durchführen, um überhaupt nur irgendeine individuelle Verminderung zu spüren!! Die Wahrscheinlichkeit dafür kann sich jeder sebst ausrechnen (Stichwort: Erlang-Verteilung).

Ein ISP meines Vertrauens nutzt zur Dimensionierung folgende Daumenregel:

(Segment-capacity - ((N/25) * max-rate)) / average_rate_per_user = number of max users

Bei einem 32er GPON Segment mit maximal 1000er Tarifen gibt es da brutto Luft bis zu einer average_rate_per_user von:

(2488.32 - ((32/25) * 1000)) / 32 = 37.76 Mbps

bzw. der Haelfte im Upstream. Netto faellt da noch etwas ab, aber solange bis die Durschnittsnutzung in der Spitzenzeit auf groesser 30/15 steigt ist ein 32er GPON Segment ganz passabel. UHD Streaming braucht etwa 15 Mbps, d.h. so ein Segment duerfte sogar 2 unabhaengige Streams pro Anschluss noch passabel verkraften.

Die Formel ist empirisch bestimmt, und dient dem ISP Kaazitaeten zu bemessen (bzw. wie viele Anschluesse pro Segment geschaltet werden koennen). Das beinhaltet Reserven, dass auch waehrend der Spitzenzeit Speedtests noch eine realistische Chance haben die vertragliche maximale Rate zu zeigen.

Zitat von gponner

Auch bzgl. der Latenzen hat das GPON Protokoll viele Vorteile. Aufgrund der 8 KHz Taktung der Up- und Downstream-Frames hat jeder Teilnehmer am PON 8000 mal pro Sekunde die Chance ein Paket loszuwerden bzw. zu bekommen. Das Protokoll lässt nicht zu, dass ein Teilnehmer einen kompletten PON nur mit seinen Daten sättigt! 8000 mal pro Sekunde wird jeder Teilnehmer auf jeden Fall bedient.

Das ist ein eher theoretisches Limit in der Praxis liegt die Zugangslatzenz bei GPON/XGSPON eher im niedrigen einstelligen Millisekundenbereich statt bei 0.125 ms. Das ist aehnlich wie bei VDSL2 mit G.INP Retransmissionen oder bei low latency DOCSIS. Das Protokoll laesst IMHO sehr wohl zu, dass Nutzdaten nur von/zu einem ONT fliessen...

Zitat von gponner

Die Box kann das schon exakt ermitteln. Aus der BWMap geht die exakte Zuteilung des Slots je ONU hervor. Diese, eigentlich zeitliche, Zuteilung ist dort in Bytes innerhalb des Frames von...bis ausgedrückt. Wenn ein ONU einen Slot von 1000 Bytes innerhalb des Frames zugeteilt bekommen hat, ist die daraus resultierende Bandbreite für die anderen verloren. Wenn keiner was zu übertragen hat, sind diese Zuteilungen auch für alle kleiner bzw. kürzer.

IMHO zeigt die BWMap nur welche Slots ein ONT exklusiv nutzen darf, und nicht ob er diese auch mit Nutzdaten verwendet oder ob er idelt.

Interessante Infos, danke dafür.

Aber rein praktisch kann die Grafik nicht korrekt sein.

Die Auslastung Upload wird beim typischen Nutzer bestenfalls 1:5 gegenüber dem Download sein. Eher 1:10 oder weniger.

Die Segmente, die wir hier gelegentlich sehen, sind niemals im Upload ausgelastet. Der Download erreicht ja kaum 10% des Segments..

Zitat von gponner

Wenn keiner was zu übertragen hat, sind diese Zuteilungen auch für alle kleiner bzw. kürzer.

Bin nicht sicher ob das zwingend so sein muss. Die Daten hier im Thread passen da nicht ganz zu, aber natuerlich immer moeglich, dass die FBs da ewnen Bug haben.

pufferueberlauf Ich mache mir jetzt mal nicht die Arbeit alles zu zitieren.

Im großen und Ganzen hast du natürlich Recht. Meine Ausführungen beziehen sich auf die theoretischen Rahmenbedingungen.

Zum Thema Upstream-Nutzung: Die echte übermittelte Datenrate kann der ONU natürlich nicht ermitteln, da er nicht ins Paket sehen kann. Aus der BWMap ist aber ersichtlich was vom OLT zugeteilt wird. Und da ist eindeutig auszumachen, wenn kein ONU signifikante Timeslots zugewiesen bekommt, also keiner was zu übertragen hat. Und wenn ONUs Timeslots zugeteilt bekommen, hat das DBA Traffic erkannt.

Die 8kHz Framerate bedeutet natürlich nicht microsekundenlatenz auf der Gesamtstrecke! Allerdings ist hier ein wichtiger Teil von der Protokolldefinition her schon mal nicht das Bottleneck.

Splitverhältnis: Natürlich ist meine Formulierung schon recht schwarz/weiß. Allerdings würde ich ein Monatsgehalt darauf verwetten, dass es in 99,9% aller Fälle passt und es zu keiner Bottlenecksituation auf der ersten Meile bis zum OLT kommt.

AON u.ä. ist nur notwendig, wenn man aus Sachgründen oder (bloßem Wollen) unbedingt Bandbreiten garantiert haben möchte. Und selbst da hat man das nur auf der ersten Meile. Ab der ersten Aggregationsschicht hängt man wieder am Fliegenfänger von Transit und Peering.

Das berücksichtigt natürlich keine evtl. kommenden Killerapplikationen wie z.B. Quantenteleportation kompletter menschlicher Körper. Da ist dann die Übertragung der Quantenzustände von ca. 7 x 10^27 Atomen in Echtzeit notwendig

Zitat von mbo77

Interessante Infos, danke dafür.

Aber rein praktisch kann die Grafik nicht korrekt sein.

Die Auslastung Upload wird beim typischen Nutzer bestenfalls 1:5 gegenüber dem Download sein. Eher 1:10 oder weniger.

Die Segmente, die wir hier gelegentlich sehen, sind niemals im Upload ausgelastet. Der Download erreicht ja kaum 10% des Segments..

Ich würde auch sagen, dass die angezeigten 1 GBit/s Auslastung in der ersten Grafik des Threads ein Darstellungs bzw. Ermittlungsfehler in der FritzOS-Version ist. Wenn es mich heute Abend juckt, werde ich nochmal meinen IPERF-Test machen und schauen was die Fritzbox in den Supportdaten für Werte bei der Auslastung anzeigt.

Zitat von gponner

Zum Thema Upstream-Nutzung: Die echte übermittelte Datenrate kann der ONU natürlich nicht ermitteln, da er nicht ins Paket sehen kann. Aus der BWMap ist aber ersichtlich was vom OLT zugeteilt wird. Und da ist eindeutig auszumachen, wenn kein ONU signifikante Timeslots zugewiesen bekommt, also keiner was zu übertragen hat. Und wenn ONUs Timeslots zugeteilt bekommen, hat das DBA Traffic erkannt.

Jein, wie der OLT Zeitslots bei DBA zuweist liegt in der Hand des jeweiligen Vendors, das klammern die ITU Standards explizit aus. Da geht letztlich alles was der Vendor will.

Waere interessant zu sehen ob das beobachtet Verhalten vom OLT Hersteller oder der Software Version abhaengig ist?

Zitat von gponner

Die 8kHz Framerate bedeutet natürlich nicht microsekundenlatenz auf der Gesamtstrecke! Allerdings ist hier ein wichtiger Teil von der Protokolldefinition her schon mal nicht das Bottleneck.

Na ja, der Vergleichswert fuer VDSL ist da 4KHz... und interessanterweise ist die Zugangslatenz bei GPON und VDSL2 (ohne Interleaving) aehnlich...

Bei mir lagen die Latenzen zum ersten Hop im Netz zu VDSL-Zeiten(100/40) bei ca. 8 ms, jetzt bei 2-3 ms.

Bei der Zeitslotszuordnung sieht der Standard alles vor. Von fixen Bandbreitenzuordnungen via Konfiguration im OLT je ONU bis hin zu unterschiedlichen, mehr oder weniger ausgefeilten, DBA Algorithmen. Es wird aber dringend von den Herstellern empfohlen, die Bandbreite dynamisch zuzuweisen. Da kann dann auch besser auf QOS-Anforderungen (VOIP, IP-TV, normaler Traffic) eingegangen werden.

Die Latenz und Jitter in PON Systemen hängt von der Konfigurierten Polling und Max Burst Size ab.

0.9ms Latenz und Jitter schafft man bei XGS aber mit hohem Overhead so das nur noch etwa 7.4-7.7Gbit/s Nutzdatenrate möglich sind.

Bei VDSL habe ich schon verschiedene Werte beobachtet.

Mein Anschluss liegt bei 3 ms, ein anderer bei eher 6.

Wobei ich im Netz schon GPON-Werte von 1-2 ms gesehen habe.