Beiträge von gponner

So, ganz frisch - Ich habe die letzten 1,x Stunden meinen Upstream mit IPERF gequält.

Die FritzBox Statistik sieht so aus:

Upstream alles in kBit/s
Stunde Used Idle Ovhd ONUs Summe
15 153073 849326 102912 30 1105311
14 151177 853002 102715 30 1106894
13 69 1021858 92341 30 1114268

Idle geht um den Betrag zurück, den ich übertrage. Sonst nutzt keiner groß den Upstream!

Meine Grafik für die Zeit sieht so aus:

EDIT: Man sieht schön, dass im Downstream der Auslastungsverlauf dem Trafficverlauf am DECIX folgt und selbst am Championsleaguetag 11.2. nur ein bisschen der Schnitt gerissen wird. Sonntags wird wohl viel und länger gestreamt, ist aber auch nicht der Rede Wert ...

Für diejenigen, die es ganz genau wissen wollen, gibt es hier

https://www.ericsson.com/en/reports-and-papers/research-papers/a-comparison-of-dynamic-bandwidth-allocation-for-epon-gpon-and-next-generation-tdm-pon

eine schöne Beschreibung der Zusammenhänge zwischen DBA Polling, also der periodischen Abfrage der Bandbreitenbedarfe der ONUs durch den OLT, und der Bandbreite/Jitter. Nicht wundern, der Beitrag ist uralt, aber die PON-Standards sind auch uralt!

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.

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.

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

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

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

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!

Nee, aber ich habe mich bei der DGF beschwert... Sind unsere einzigen Anschlüsse, die Lahm sind. Aber wie sagt man so schön: Einem geschenkten Gaul schaut man nicht ins Maul - Vor allem, wenn es der einzige Gaul weit und breit ist.

Hab ich was vom Maßstab geschrieben? Fakt ist, dass unser Roundtrip von allen DGF-Anschlüssen Richtung Telekom (und vielen anderen Netzen) bei 22-25 ms liegt, von allen anderen Nicht-DGF-Anschlüssen, seien es EWE, Telekom oder sogar ein Lokalprovider aus Borken, bei 9-14 ms. Macht für flüssiges Arbeiten per RDP schon einiges aus. BTW: Da die Telekom mit das größte Netz betreibt, ist es schon wichtig, wie das Peering dahin ausgestattet ist.

Das Problem ist nicht nur die Peeringbandbreite sondern auch die Anzahl der Peeringpunkte bzw. deren geographische Lage.

DGF (AS60294) hat laut Peeringdb nur 3 öffentliche Peeringpunkte, davon 1 x400 DECIX-FRA. EWE z.B. dagegen 5 Punkte, davon 500GBits DECIX-FRA und 100GBits DECIX-HAM, neben einigen anderen.

Dann wäre noch die Frage wie das Peering zum Telekom-Netz aussieht! Das sind i..d.R private Peerings, die auch bezahlt werden müssen. DTAG ist bei DECIX kaum vertreten!Wir haben doppelt so hohe Laufzeiten von unseren Business DGF-Anschlüssen zu unseren Servern im Telekom-Netz als bei unseren EWE-Glasfaseranschlüssen.

Bitte nicht vergessen, dass sämtliche Billig-Privat-/Geschäftskundenprodukte immer mit der Verkehrsklasse "Best Effort" abgewickelt werden! Anders ließe sich das auch nicht finanzieren ...

Schön, dass es bei dir so glatt gelaufen ist! Ich bin aktuell auch sehr zufrieden mit dem GFNW/Osnatel-Anschluß. Der VDSL2 vorher lief schon sehr stabil und bei dem GF-Ansschluß habe ich, seit der Inbetriebnahme vor zwei Monaten, noch keine Sekunde Ausfall oder irgendwelche andere Mucken gehabt.

Das Glasfasermodem 2 der Telekom läuft wie geschnitten Brot am GFNW-Anschluß. Die einzige "Klippe" die du umschiffen musst, ist das mittelalterliche (telefonische) Anmeldeverfahren der Modem-ID bei der EWETEL. 99,5% der Hotliner haben keine Ahnung von diesem Prozess, selbst die, die an der auf dem Schreiben angegebenen "Glasfaser-Hotline" sitzen.

Liegt wahrscheinlich an der Aufgabenteilung innerhalb der GFNW. Die Telekomseite ist federführend für den Betrieb und Aufbau der aktiven Technik, EWE für den Netzausbau.

Grundsätzlich hast du bei Problemen im Bereich des passiven Verteilnetzes immer ein gehöriges Zeitdelay. Die Bautrupps sind sowieso knapp und mit dem Ausbau beschäftigt. Das merken vor allem die Kunden, die sich erst nachträglich für einen Anschluss entscheiden. Das sind Wartezeiten bis 1 Jahr und darüber nicht selten. Genau so verhält es sich mit nachträglichen Mängelbeseitigungen, wie bei dir.

Das Glasfasermodem 2 der Telekom läuft bei mir wie geschnitten Brot an einem GFNW/Osnatel Anschluß!

Die Seriennummer muß dazu vorher mitgeteilt werden! Das geht, aus mir unerfindlichen Gründen, nur per Telefon. Die Chancen liegen bei 50/50 ob du auf einen Hotliner triffst, der überhaupt schon mal die Begriffe "Modem-ID, Seriennummer, GPON etc." gehört hat. Bei mir waren es gefühlt 10 Anrufe bis ich einen Mitarbeiter dran hatte, der das Thema kannte.

Warum soll das wirtschaftlich sinnlos sein? Wenn die Kosten des eigenen Netzes unterhalb der Kosten des BSA bei der DG liegen, ist das absolut sinnvoll. Leider haben wir keinen Einblick in die Zahlen ...

Ich denke mal, das sich EWE dem Zug IPv6 nicht entziehen kann! Im Backbone läuft es ja schon, zumindest nach PeeringDB...

Welcher "größer werdende Teil" des Internets setzt denn aktuell ausschließlich auf IPv6?