Tarifwechsel

Fuer den Upstream ist das in gewissen Grenzen erwartbar gewesen (haette mir klar sein sollen) wegen DBA (dynamische Zuweisung von Sendeslots) aber ich haette erwartet, dass irgebdwo auf BNG Ebene (wenn die Ebende denn existiert) noch ein Traffic shaper sitzt der die vertraglichen maximal Raten durchsetzt. Danke fuer die Richtigstellungen, FTTH ist wie ich lernen muss wohl noch "Neuland" fuer mch

Ach ja, Danke fuer die MTR Traces, leider sehen die rechtschaffen normal aus, mir faellt da nichts direkt ins Auge was zu Deiner lokalen RTT Beobachtung passen wuerde.

Zitat von goppinath

, nach den Informationen, die ich von Nokia erhalten habe, wird das Profil auf das ONT angewendet, und das ONT setzt die Geschwindigkeitsbegrenzung durch.

Nein, das ist definitiv Unfug. Der ONT ist einfach nur ein Medienwandler. Sonst hätten ja alle passiven Anschlüsse keine Begrenzung. Ich weiß nicht, ob OLT oder BNG, aber sicher nicht ONT.

Also meine Lektuere der ITU Standards bezueglich GPON und XGSPON bringen mich zu der Ueberzeugung, dass ein ONT etwas mehr ist als ein "dummer" Medienwandler (aber zur Intelligenz des Wandlers hattest Du Dich gar nicht geaeussert )... klar die Provider ONTs dienen oft als Bridge zwischen dem PON und Ethernet, in so fern wandeln sie das Medium, aber die PON Seite ist dabei massiv komplizierter als z.B bei Ethernet. Da die PONs als Request/Grant Systeme arbeiten (wegen Shared-Medium auch eine naheliegende Loesung will man statische Zuordnung der Transmit-Zeitfenster vermeiden) ist ein guter Teil der Kompexitaet halt erforderlich um zu Verhindern, dass Anschluesse gegenseitig Download Daten lesen koennen oder sich beim Upload in die Quere kommen. Dabei ist es natuerlich so, dass der OLT die Upload Zeitschlitze zuteilt und damit die Kontrolle behaelt was die ONTs denn genau machen, aber man kann sicher einen Teil der Kontrolle in die ONTs auslagern, so macht z.B. ein AQM im ONT Sinn fuer den Upload (wie es z.B. in Docsis 3.1 Modems auch vorgeschrieben ist, und das ist ja auch ein Request/Grant System). Ob die normalen ONTs allerdings darueber hinaus noch Traffic Shaper Funktionen uebernehmen kann ich nicht sagen, aber bin da wegen des geringen Stromverbrauchs etwas skeptisch, Traffic Shaping ist relativ "teuer".

frank_m weiß schon, das im ONT einiges an Intelligenz steckt .

Genauso wie meine Wenigkeit simplifizieren wir manchmal unsere Postings, damit diese für Laien (das ist die Mehrheit der Teilnehmer, das darf man nie vergessen!) besser verständlich ist.

Wuerde das gerne mal durchmessen, bisher waren solche Massnahmen der Geraetehersteller eher enttaeuschend, bzw. fuer hohen Durchsatz optimiert und nicht fuer niedrige Latenz und Jitter. Und Deine Smokeping Resultate deuten an, dass da durchaus Luft nach oben ist...

So doof ich den Fokus auf Durchsatz, Durchsatz, Durchsatz auch finde, ich verstehe schon warum ISPs das versuchen zu optimieren. Das ist halt das was uns Kunden erzeaehlt wird was wichtig sei, und was mit "Speedtests" leicht zu messen ist (eigentlich sind das Kapazitaetstests, der "Speed" in Meter/Sekunde ist bei allen Tarifstufen etwa gleich bei ca. 2/3 c in Vakuum, und bei DSL und DOCSIS ist das aehnlich). Und auch der Test bei breitbandmessung.de kuemmert sich hauptsaechlich um den Durchsatz.

Nach meiner Kenntnis betrachtet die BNetzA eine Latenz bis 150 ms als akzeptabel.

Tests in Fachzeitschriften gehen aber darauf an. Dort gibt es die Kategorie bis max 10 ms.

Die BNetzA sagt zur Latenz nicht viel, lediglich bei der Mindestversorgung ist festgelegt, dass die Latenz zu den Servern <= 150ms sein soll, aber das ist als OWD gemint, d.h. die RTT darf bis zu 300ms sein.

Wobei die Wahrscheinlichkeit des Bufferbloats stark nachlässt.

Es steht für die meisten Haushalte selbst in den günstigsten Tarifen ausreichend Bandbreite zur Verfügung, so dass die Leitung selten überhaupt ausgelastet wird.

Und je mehr Bandbreite ich buche, desto geringer wird die Auslastung.

Zitat von goppinath

Ein wichtiger Faktor ist der Bufferbloat, der oft übersehen wird. Dies kann durch einen Test ermittelt werden, der über eine Ethernet-Verbindung empfohlen wird.

Meines Erachtens der am meisten überschätzte Wert in der Internet Welt. Immer bedenken: Buffer-Bloat wird nur relevant, wenn die Internetleitung sehr stark oder voll ausgelastet ist. Wie oft spielt man Online Spiele, wenn die Leitung im Hintergrund ununterbrochen auf Vollast läuft?

Zitat von goppinath

Vielleicht ein Missverständnis. Hier sind die Gründe.

Nö, in dem Artikel steht ja auch drin, dass die Leitung am Anschlag sein muss, damit Bufferbloat relevant wird. Habt ihr euch nie gefragt, warum die üblichen Bufferbloat Tests die Leitung bis zum Anschlag auslasten, wenn sie die Werte messen? Der Vergleich ist immer Leerlauf <-> Volllast.

Zitat von mbo77

Wobei die Wahrscheinlichkeit des Bufferbloats stark nachlässt.

Es steht für die meisten Haushalte selbst in den günstigsten Tarifen ausreichend Bandbreite zur Verfügung, so dass die Leitung selten überhaupt ausgelastet wird.

Und je mehr Bandbreite ich buche, desto geringer wird die Auslastung.

Das ist in der Tat ein oft gehoertes Argument. IMHO ist das etwas zu optimistisch gedacht. Bufferbloat tritt auf wenn zu grosse schlecht verwaltete Puffer auf dem Pfad uebervoll werden und dei Kontrollschleife von z.B. TCP unscharf werden lassen. Die Loesung dafuer ist die Pufferspeicher zu verkleinern (so dass das schlimmste Queuing-Delay ueberschaubar bleibt) oder besser noch die Puffer besser zu verwalten, so dass der Fuellstand der Puffer nie/selten bedenklich wird.

Jetzt ist TCP so gebaut, dass es jeden Link auslasten wird (da muessen allerdings Sender und Empfaenger mitspielen), d.h. unabhaengig von der Linkkapazitaet kann und wird TCP (oder Bulk-Transfer mit QUIC) diese versuchen auszureizen, und das fuehrt dann zur Ueberfuellung der Pufferspeicher. Ja, wenn dsich am Traffic-Muster nichts aendert ist die Wahrscheinlichkeit die Puffer zu ueberfuellen bei hoherer Zugangskapazitaet kleiner (gerade bei Nutzungen, wie Browsing oder Streaming die normalerweise die Link-Kapazitaet nur selten voll auslasten), aber es reicht ein groesser Download mit TCP oder QUIC (oder µTP?Torrent) und dier Pffer sind zu...

Jetzt ist es natuerlich jedem Nutzer/Heimnetzwerk freigestellt selber zu waehlen was man als akzeptabel/erstrebenswert haelt, d.h. ich will niemandem der mit seinem Netz zufrieden ist ungefragt "tolle" Aenderungsvorschlaege machen. Aber wenn es z.B. bei gleichzeitiger Nutzung von sagen wir Steam-Downloads und RemoteDesktop/VideoConferenz (aka neudeutsch HomeOffice) knirscht, dann will ich einwerfen, dass statt "buche einen Tarif mit hoeherer Kapazitaet" eventuell "sorge dafuer dass Deine WAN-Kapazitaet besser gemanaged wird" ein Ansatz ist der wert ist getestet zu werden.

Ein Beispiel, mit einem alten Router (Netgear WNDR3700v2, wenn das noch jemandem etwas sagt) war bei mir bei ˜70 Mbps Traffic Shaping Schluss, mehr ging wegen der alten MIPS CPU nicht, nach dem ich von 50/10 auf 100/40 gewechselt bin, habe ich festgestellt, dass ˜40/30 Mbps mit kompetenten Traffic-shaping/-scheduling/AQM deutlich besser nutzbar war als 100/40 mit dem was mein ISP selber an Queuemamagement geleistet hat. Das soll nicht heissen, dass dies der einzig wahre Weg ist, sondern nur, dass manchmal "mehr Kapazitaet" nicht die allgemein beste Loesung ist.

Im OpenWrt Forum kommen regelmaessig Posts vor, bei denen Nutzer mit Gigabit+ Links davon berichten, dass fuer Ihre Nutzung kompetentes shaping/scheduling/AQM die Nutzbarkeit und Schwuppdizitaet ihres Anschlusses spuerbar verbessert hat. Aber um es noch mal zu wiederholen, das gilt bestimmt nicht fuer alle und jedermann/frau. Ich wuerde jedoch empfehlen das einfach amal am eigen Link auszuprobieren, ausser ein bisschen Zeit kann man bei so einem Test eigentlich nichts verlieren

Zitat von frank_m

Meines Erachtens der am meisten überschätzte Wert in der Internet Welt. Immer bedenken: Buffer-Bloat wird nur relevant, wenn die Internetleitung sehr stark oder voll ausgelastet ist. Wie oft spielt man Online Spiele, wenn die Leitung im Hintergrund ununterbrochen auf Vollast läuft?

Oefter als man denkt, reicht aus wenn ein Mitnutzer des Netzes Updates runter laedt und bei niedrigeren Zugangskapazitaeten reicht auch oft Video-Streaming.... Videostreaming, muss man wissen sendet naemlich nicht einen glatten Stream konstant mit der gewunschten Bitrate, sondern der Client laedt, oft ueber TCP kleine Snippets des Materials vom Server, und zwar alle paar Sekunden so schnell es geht, was dann zu Bursts in der Download Queue beim ISP fuehrt und das kann schon den Jitter von zeitkritischen Anwendungen erhoehen. Je nach Nutzung ist das allerdings auch egal, bzw. nicht bemerkbar

Zitat von frank_m

Nö, in dem Artikel steht ja auch drin, dass die Leitung am Anschlag sein muss, damit Bufferbloat relevant wird. Habt ihr euch nie gefragt, warum die üblichen Bufferbloat Tests die Leitung bis zum Anschlag auslasten, wenn sie die Werte messen? Der Vergleich ist immer Leerlauf <-> Volllast.

Wie gesagt, um einen Anschluss transient an den Anschlag zu brigen, reicht schon ein TCP Download, das ist jetzt weder unrealistisch noch ausserhalb des normalen Nutzungsverhaltens, wenn man nur an Gigabitgrosse Updates denkt?

Zitat von goppinath

Der Langzeitzuckertest sollte nach dem Fasten durchgeführt werden, nicht nach starkem Essen und Trinken. Der Grund dafür ist, dass Fasten der relevante Punkt in der Definition ist. Bufferbloat kann unter allen Netzwerkbedingungen auftreten, insbesondere bei der Datenübertragung auf Abruf wie bei YouTuben. Es ist nicht erforderlich, dass Sie die gesamte zulässige Bandbreite ausschöpfen.

Jein, der Ingress Traffic in den Pufferspeicher muss groesser sein als der Egress Traffic ansonsten waechst die Warteschlange nicht an, aber das muss nicht unbedingt durch kontinuierlichen langanhaltenden Traffic geschehen, das kann z.B. auch passieren wenn verschiedene Anwendungen transient gleichzeitig (jeweils relativ wenige) Daten anfordern.

Aber nur weil das so passiert bedeutet nicht, dass jeder das gleich bewertet, fuer manche ist das ein Problem das sich lohnt zu beheben, waehrend es anderen egal ist. IMHO ist beides voll OK, persoenlich falle ich in das "lohnt sich zu beheben" Camp, aber das ist IMHO nicht besser oder schlechter als das "ist egal/merke ich nicht" Camp.

Ja, es mag sein, dass Video Streaming die Daten stoßweise herunterlädt. Aber auf einer schnellen Leitung bedeutet das auch nur sehr kurze Peaks, oder - wenn der Server so schnell nicht liefern kann - keine voll ausgelastete Leitung: Die Wahrscheinlichkeit einer Kollision mit zeitkritischen Daten sinkt.

Grundsätzlich ist Buffer-Bloat nur ein Problem, wenn die Leitung voll ausgelastet ist, und damit es in zeitkritischen Anwendungen zum Problem wird, muss es zu einem sehr hohen zeitlichen Anteil der Fall sein. Ein schönes Beispiel ist der AVM Traffic Shaper: Ungefähr 10% der Bandbreite werden für zeitkritische Anwendungen aufgespart, und das ist mehr als hinreichend.

Auch wenn man sich mal durch die Foren liest, durch die üblichen Gamer-Threads: Wie oft helfen denn Maßnahmen zur Bufferbloat Bekämpfung wirklich? Die Quote ist grausam, üblicherweise ist das Resultat Enttäuschung.

Zitat von frank_m

Ja, es mag sein, dass Video Streaming die Daten stoßweise herunterlädt. Aber auf einer schnellen Leitung bedeutet das auch nur sehr kurze Peaks, oder - wenn der Server so schnell nicht liefern kann - keine voll ausgelastete Leitung: Die Wahrscheinlichkeit einer Kollision mit zeitkritischen Daten sinkt.

Jein, die Google Youtube Server sind mit 10G und groesser angebunden die koennen mehrere 1 Gbps Links gleichzeitig in die Saettigung treiben. Bei Netflix sieht das aehnlich aus, die Cache Boxen sind auch mit >>= 10 Gbps angebunden.

Zitat von frank_m

Grundsätzlich ist Buffer-Bloat nur ein Problem, wenn die Leitung voll ausgelastet ist, und damit es in zeitkritischen Anwendungen zum Problem wird, muss es zu einem sehr hohen zeitlichen Anteil der Fall sein. Ein schönes Beispiel ist der AVM Traffic Shaper: Ungefähr 10% der Bandbreite werden für zeitkritische Anwendungen aufgespart, und das ist mehr als hinreichend.

Oder einer Streamt und die andere spielt ein on-line FPS Spiel, da reicht es auch wenn die Streamingpeaks den Jitter der Gaming-Pakete erhoehen um dem SPieler Nachteile zu schaffen.

Zitat von frank_m

Auch wenn man sich mal durch die Foren liest, durch die üblichen Gamer-Threads: Wie oft helfen denn Maßnahmen zur Bufferbloat Bekämpfung wirklich? Die Quote ist grausam, üblicherweise ist das Resultat Enttäuschung.

Ja, oft wird versucht mit lokalen Massnahmen Probleme zu loesen die gar nicht im lokalen Netz enstehen, das ist meist weniger erfolgreich, aber wnn das Problem tatsaechlich am Zugangslink liegt, dann ist es in meiner Erfahrung mit SQM oft moeglich das Problem deut;ich abzumildern oder gar zu beheben. Meine Erfahrung speist sich aus dem OpenWrt Forum, da ist die Quote noch weit von 100% entfernt aber "grausam" ist anders.

Aber hez\y, wenn das nicht Deine Tasse Tee ist, kein Problem, "Dein Netz, Deine Regeln"

Zitat von pufferueberlauf

Jein, die Google Youtube Server sind mit 10G und groesser angebunden die koennen mehrere 1 Gbps Links gleichzeitig in die Saettigung treiben

Ja, aber für wie lange? Das sind immer nur Bruchteile von Sekunden. Die Wahrscheinlichkeit für Kollisionen, die sich wirklich spürbar auf die Übertragung zeitkritischer Daten auswirkt, ist und bleibt sehr klein.

Zitat von pufferueberlauf

bei niedrigeren Zugangskapazitaeten reicht auch oft Video-Streaming.... Videostreaming, muss man wissen sendet naemlich nicht einen glatten Stream konstant mit der gewunschten Bitrate,

Im Gegensatz zum IGMP Broadcast ... Der kennt das Problem eher nicht ...