Beiträge von pufferueberlauf

Wobei der Provider letztlich nur Informationen vom ONT anfordern kann um dessen Identitaet zu ueberpruefen. Und die kann man letztlich auch "clonen", wenn man denn weiss welche Informationen ausgewertet werden.

Cool, welche Betriebssysteme stehen Dir zur Verfuegung? Koenntest Du, wenn beide Lunks aktiv geschaltet sind ein paar Vergleichsmessungen machen und die Resultate hier im Forum posten?

Interessant waere je Messungen mit:

LibreQoS Bufferbloat Test - Cloudflare Edition

https://www.waveform.com/tools/bufferbloat

Sowie vergleichende Traceroutes mit Trippy zu relevanten Endpunkten wie:

trip --mode tui --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --tui-preserve-screen --dns-resolve-method cloudflare --tui-custom-columns holsravbwdtKM --icmp --tos 181 -4 HIER_KOMMT_DIE_ZIELADRESSE_HIN

one.one.one.one

http://www.gstatic.com

9.9.9.9

8.8.8.8

Telekom | Mobilfunk, Festnetz & Internet, TV Angebote

Zitat von HubeBube

Wie ist es nun mit "1&1 over DG"?

DHCP oder PPPoE?

VLAN-ID für Internetaccess und oder Telefonie notwendig?

Ich schaetze 1&1 duerfte versuchen das ganze einheitlich zu halten, und wuerde mich nicht ueber eine "PPPoE mit VLAN7" Loesung wundern

Zitat von HubeBube

In der Theorie.

Ja, die Argumente die gegen ONT Freiheit voegebracht wurden, sind IMHO alle sehr theoretisch konstruiert. Den Grund dafuer sehe ich in dem was ich fuer die eigentliche Motivationen halte, Kontrolle durch den ISP. Fuer einen ISP hat es Null Vorteil Fremd-ONTs zu provisionieren, aber er muss sich dann mit den Eigenheiten allef verwendeter ONTs runschlagen, und im Zweifel eine andere (teurere) Provisionierungssoftware (ich vermute proprietaere Loesungen eines jeden Ausruesters duerften billiger sein).

D.h. der Grund fuer die Ablehnung von Fremd-ONTs sind wirtschaftlicher Natur, aber das TKG macht keine Ausnahme wegen Wirtschaftlichkeitserwaegungen.

Das gleiche gilt fuer Fremd-Router, da kommt sogar noch groesseres Potential fuer Fehlkonfigueationen mit einhergehender Belastung des Supports dazu. Aber da haben EU und Bundesregierung und BNetzA dankenswerterweise klar gemacht, dass die Routerfreiheit verpflichtend ist.

Wir hatten hier im Forum allerdings bereits einen Bericht von einem DG Neukunden der einen XGSPON ONT bekommen hat, obwohl Stand heute keiner der DG Tarife XGS benoetigt und das neue Segment duerfte auch ehef nicht ueberfuellt sein.

Ja, das ist kein harter Beweis fuer gar nichts, aber zumindest ein weiches Indiz was die DG eventuell in neuen Segmenten machen will.

IMHO macht das viel Sinn, wenn denn mal Tarife kommen, die XGS brauchen, dann erspart sich die DG den ONT Wechsel und das wuerde potentiell schnellere Tarifwechsel erlauben. Aber dafuer braeuchte es halt Tarife >> 1 Gbps, und wir wissen alle wie gering die Nachfrage danach momentan ist.

Na ja, ein fehlerhafter ONT koennte durchaus auch die Abschaltaufforderung des OLT ignorieren...

Ich denke es ging nicht um das theoretische Potential zur Koexistenz von G und XGS PON, sondern darum was die DG in neuen Segmenten zu machen schient...

Nein bei AON gibt es entweder eine Faser pro Richtung, oder wenn wie beim Internetzugang ueblich nur eine Faser verwendet wird, zwei nicht ueberlappende Frequenzfenster fuer Down und Upload. Und weil bei AON nur jeweils ein Geraet auf jeder Seite haengt besteht keine Bedarf fuer irgendwelche Zeitschlitzzuweisungen.

Was EPON angeht, das ist IMHO aehnlich wie GPON und verwendet zeitbasiertes Multiplexing in Upstreamrichtung.

Mei, bei GPON (und XGSPON, 25GPON, 50PON) ist es so, dass der OLT den einzelnen ONTs Zeitschlitze zuweist in denen die jeweils senden duerfen. Wenn sich ein ONT nicht daran haelt besteht das Risiko, dass 2 ONTs gleichzeitig senden und beim OLT kommt dann eine Mischung aus beiden Sendungen an, die keinen Sinn macht.

Zitat von Edding

Zieht sich in einem durch.

Was fuer mich bestaetigt, dass die reine Zugangslatenz < 5 ms sein duerfte, ansonsten waere eine RTT von 4.227 zu Hop 5 nicht erklaerbar...

Mmmh, gerade noch mal in meine Aufzeichnungen gesehen:

Zitat

AS60294/8899 Deutsche Glasfaser: die inneren Hops sind oft langsamer als die Endpunkte, ungeeignet zu Abschaetzung der Zugangslatenz

Hatte ich wohl falsch in Erinnerung, zur Zugangslatenz bei der DG kann ich nichts sinnvolles Beitragen, ausser dass die Latenz zu den RIPE Atlas Ankermessungsendpunkten oft um 4-5 Millisekunden liegt*, womit die Zugangslatenz << 5ms sein deurfte... das passt fuer mich immer noch zu den 2ms Werten der Telekom... aber klar, das ist ein Schaetzung und keine praezise Messung.

*) Mitunter liegt die auch bei 2ms, unklar ob das AON Anschluesse sind.

Wenn das das CG-NAT Gateway ist, dann ist das bereits mehr als die Zugangslatenz ueber das GPON Segment. Bei mbo77 hat das CG-NAT Gateway sogar hoehere Latenz als der Endpunkt... was fuer mich bedeutet, das ist kein geeigneter Reflektor fuer ein Abschaetzung der Zugangslatenz. Aber hey, ich mag da einem Zirkelschluss erliegen und nur besonders niedrige GPON RTTs vorselektieren...

Zitat von mbo77

Dann käme das in etwa hin. 5 ms GPON-Latenz, 3 ms bis FFM.

IMHO, nur wenn zwischen Deinem OLT und dem Server in FFM kein weiterer Hop waere... aber da ist ja noch das CG-NAT Gateway/AFTR dazwischen, das auch Zeit braucht...

Andererseits gut moeglich, dass meine 2ms fuer das PON-Segment etwas optimistisch ist und fuer netservices habe ich noch gar nicht nach Atlas Nodes gesucht

Ich habe bei RIPE Atlas in der Tat primaer auf Telekomanschluesse geblickt, bei denen ist die Netzstruktur klarer und der BNG ein IP Hop der i.d.R. nahe am OLT Standort liegt, aber ich habe auch bei der DG aehnliche Latenzen gesehen, wenn ich mich nicht irre, muss ich wohl mal schauen wie ich das per API abfrage statt mich haendisch Probe fuer Probe durch Traceroutes zu klicken...

Wenn ich fragen darf, hast Du eine Referenz fuer die ~5ms, waere sehr interessant.

Nach meinen Beobachtungen von RIPE Atlas Nodes hat man bei GPON geschaetzt meist ca. 2ms Zugangslatenz, dazu kommt dann halt die weitere Strecke uund Verzoegerungen fuer alle L2/3 Hops die von Licht zu Strom ubd wieder zu Licht umwandeln, so wie eventuelle Queueingdelays. Nach einer Faustregel reicht 1 ms RTT fuer ca. 100km Glasfaserstrecke, d.h. bei Dir erklaert die Distanz >= 3.5 ms, zusammen mit der PON Latenz bleiben nur ca. 2.5 ms uebrig die erklaert werden muessten... sieht OK aus...

Zitat von mbo77

Im Layer 3 wird mein Anschluss wohl in FFM terminiert. Wie an anderer Stelle hier im Forum zu lesen, hat net services noch weitere Knotenpunkte, von denen inbesondere Hannover, aber auch Hamburg für mich näher liegen. Das ist aber schon fast Schmuck am Kleid.

Dazu kommt, dass Traffic oft so oder so ueber FFM geroutet wird, selbst wenn der PoP in Hamburg oder Hannover sitzt, wenn man nicht vel lokalen Traffic hat innerhalb def eigenen Stadt, wuerde ich vorsichtig FFM als guten PoP Standort bewerten...

(Habe selber die umgekehrte Situation, wohne etwas naeher an FFM aber mein PoP ist zuverlaessig in/nahe HH, auch kein Weltuntergang, aber halt direkt ~10ms hoehere Latenz zu allen Zielen in.hinter FFM).

Zitat von mbo77

Beim Upload fällt während des Tests auf, dass der Upload zunächst höher startet und sich dann in Richtung 250 Mbps einpendelt:

Das mag schlicht der Effekt des ueblichen Endes der Slow-Start Phase sein, da wird dann kurzfristig mit einem Congestionwindow von ca. 2 x des tatsaechlich gewuenschten gearbeitet und das fuehrt, vor dem eigentlichen Flaschenhals zu einer Spitze im Egress-Traffic, wenn die gross genug ist, sieht man die auch in OpenWrts Echtzeit-Traffic-Graphen.

Wobei der Cloudflaretest andeutet, dass der Traffic-Shaper wohl so konfiguriert ist, dass er intiale Bursts durchlaesst (der maximale Durchsatz ist nicht bei der maximalen Dateigroesse zu finden sondern etwas unter dem Maximum), das mag auch Teil der Erklarung sein.

Ja, wenn sich ein ONT nicht an die ihm zugewiesenen Sendezeitslots haelt sind Probleme vorprogrammiert, weil wenn zwei ONTs im selben Slot senden kommt beim OLT nur Gruetze an. Das ist ganz generell bei Zeit-basiertem Multiplexing so...

Wie oft das in der Praxis vorkommt, kann ich nicht sagen, aber ich vermute selten, weil so ein ONT nicht gut nutzbar sein duerfte (hohe Latenz/Jitter und vielleicht auch Paketverlustraten).

Zitat von hipp

Denke mal größere Umwege würden mich zumindest nicht betreffen, da aus der nähe von Frankfurt. Also bei O2 kann man ausschließen im Telekom Netz zu landen? Worst case, die Route wird länger?

Jein, O2 kann auch ueber UGG FTTH anbieten... aber ja bei Telekomvorleistung wird der Traffic erstmal per L2-Tunnel zu einer Uebergabe zu O2 verschifft. Dadurch kann die Route auch mal laenger werden, wie in meinem Fall, waere ich Telekomkunde wuerde Traffic nach Frankfuert nicht die szenische Route ueber Hamburg waehlen

Zitat von hipp

Tendiere auch zu O2, da ich viel gutes über ihre Peeringpolitik gehört habe und es sicher DualStack gibt. Allerdings etwas teurer im Gesamtpaket als z.B. 1und1.

1&1 habe ich selber keine Erfahrung mit, daher kann ich nicht sagen ob die besser oder schlechter sind als O2

Mmmh, muss ich spaeter mal meine VM auspacken und austesten...