Beiträge von pufferueberlauf

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.

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

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.

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.

Wuerde mir ein ausreichend langes Cat6 Flachbandkabel holen (farblich der Wnad angepasst also z.B. weiss) und die Strecke von ONT zu Router so ueberbruecken, Flachbandkabel passt oft noch mit durch wohnungsinterne Tueren, im Zweifel auf dem Boden direkt an der Tuerzarge. Ist nicht super-schoen, aber mit vorkonfektionierten Kabel schnell erledigt, mit ein paar Schellen ist das schell an oder nahe der Fussleiste fixiert und zumindest ich kann das gut ignorieren.

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

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

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.

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

Zitat von kingpin42

Das weiß ich nicht, die WCO/EON macht es nicht in den BNGs, sondern über OLT Profile.

Interessant, verhaelt sich das eher wie ein Traffic Shaper (mit eigenen Queues) oder wie ein Traffic Policer (shallow queue drop on overload)? Ich vermute das erste.

Zitat von goppinath

Ich habe den Verdacht, dass die Verwendung des ICMP-bezogenen „ping“ nicht die beste Methode ist, um die Qualität einer Internetverbindung zu testen. Viele Leute haben auch behauptet, dass zahlreiche ISPs ICMP-Anfragen in ihren Gateways sehr niedrig priorisieren.

Naja, mit MTR kannst Du auch mit UDP oder TCP Probes arbeiten, aber die Infrastrukturhops auf dem Weg antworten dann auch nicht zuverlaessiger oder schneller... einfach --udp oder --tcp als Argument zum mtr aurfuf dazu packen...

Zitat von goppinath

pufferueberlauf Während des „mtr“-Tests zeigt mein System eine beträchtliche Anzahl von verworfenen Paketen an.

Da ist ein ICMP Ratenlimiter am laufen (die verworfenen Packete kommen ja von Deinen eigenen Ping Targets sind also Packete die nicht direkt was mit dem MTR zu tun haben, ausser halt bei 1.1.1.1), vielleicht in Deinem Router, vieleicht bei der DG, da kann es helfen UDP oder TCP probes zu verwenden...

Zitat von goppinath

Ist es für jemanden hier möglich zu sehen, wie sich eure Verbindung auch verhält? Vielleicht ein Diagramm wie dieses oder eine gleichwertige Messung erstellen?

Kann ich wohl posten, aber ich habe weder FTTH noch bin ich DG Kunde daher lass ich das erstmal, es sei denn Du bist an Vergleichsdaten von einem VDSL2 Link von O2 (Vorleister Telekom) interessiert.

Zitat von kingpin42

Ich tippe auf ein Problem im Shaper/QoS Einstellungen des OLT, die Strecke dahinter dürfte gleich sein.

Hat die DG keine BNgs mit den Traffic-Shapern sondern ueberlaesst das den OLTs?

Zitat von frank_m

Ich denke, dass tatsächlich die Tarifumstellung eine entscheidende Rolle spielt. Der Traffic muss nun auf 400 MBit/s gedrosselt werden, das war vorher nicht der Fall. Je nachdem, ob gerade anderer Traffic auf der Leitung ist, kann das mal ein paar ms ausmachen, wenn ein Paket gepuffert wird.

Naja vorher wurde der auf 1000 Mbps gedrosselt... kann natuerlich sein, dass der Pufferspeicher der fuer 1000 Mbps passabel dimensioniert war, jetzt bei 400 Mbps auffaelig wird, aber eigentlich sollte das nicht zu so grossen Schwankungen fuehren wie sie ganz oben in den Smokepingplots zu sehen sind (die selbe Puffergroesse sollte bei 400 Mbps halt zu maximal 2.5 laengerer Servicezeit fuehren).

Zitat von bayerflyer

Da ich nur Laie bin, aber sehr interessiert, kann mir bitte jemand in kurzen Worten erklären, was mit diesem Kommando getestet wird?

Vielen Dank für Eure Bemühungen.

mtr ist ein traceroute der ueber die Zeit akkumuliert und fuer jeden hop getrennt Paketverlustrate und RTT zeigt, die RTT dabei schon als, kleinstem groesste, mittlere, zusaetzlich wierden Statistische Werte zum Jitter, also der Varianz der RTT angezeigt. Damit kann man versuchen zu verstehen was auf dem Netzwerkpfad passiert. (Aber Vorsicht, traceroute/mtr zu interpretieren ist gar nicht so einfach, hier ein Link zu einer guten Erklaerung).

Zitat von DLMttH

IPv6 ist erstens Voraussetzung für DS Lite, zweitens verwendet DG CG-NAT und nicht DS Lite.

Ja, mit "ich meine die machen ds-lite" wollte ich sagen, ich denke ein IPv6 Test macht Sinn, aber da lag ich wohl falsch, Danke fuer die Information.

Zitat von goppinath

Ich denke mehr oder weniger dasselbe. Früher hätte ich wegen der 1000 Mbit/s vielleicht einen eigenen GPON-Port zugewiesen bekommen, und jetzt teile ich mir ein GPON mit 2,5 Gbit/s mit den wahrscheinlich 32 anderen Nutzern.

Dafuer muesste ein Mitarbeiter im PoP, bzw. am Splitter, mindestens etwas umstecken, wenn nicht gar umspleissen, das waere IMHO fuer die DG ziemlich Personal-aufwendig, vielleicht zu aufwendig?

Mach doch mal ein:

mtr -ezb4w -c 1000 -o LSNBAWVJMXI one.one.one.one

und ein (wenn die DG IPv6 ueberhaupt anbietet, ich meine die machen ds-lite?)

mtr -ezb6w -c 1000 -o LSNBAWVJMXI one.one.one.one

und poste das Resultat (Achtung, vielleicht willst Du da IP Adressen redigieren vor dem Posten)

UNd zum Vergleich einen DNS-Server von der DG:

mtr -ezb4w -c 1000 -o LSNBAWVJMXI dnsauth002.dg-w.de

Zitat von Bohni

Hallo zusammen,

Ich bin Teamleiter bei Vodafone/OXG und kann zu OXG sagen, dass wir noch keine Endkundenprodukte haben.Bei uns wird nur die Gestattung für den Bau der Infrastruktur mit dem Kunden abgeschlossen. Diese ist in FttH Bauweise ohne Wenn und Aber kostenfrei. Open Access Partner sind derzeit noch nicht bekannt, bzw.gibt es auch noch keine eigenen Tarife. Ich würde daher auch bei uns und EON unterschreiben. Ein finanzielles Risiko gibt es nicht.Der Kunde kann sich sogar für einen EON Internetvertrag entscheiden und spart die Aktivierungsgebühr.

Sag mal kannst Du etwas zur FTTH-Bauform bei der OXG sagen?

Also interessante waeren:

a) PON oder AON? (Ich vermute PON)

b) Welches Zielsplitting 1:32 oder 1:64

c) Wieviele durchgaengige Fasern zwischen TAs und PoP?

d) Bietet Ihr nur Bitstrom oder auch Dark-Fiber an?

e) Ist es korrekt, das Ihr hautsaechlich den aktuellen Kabel-Footpring von VF bearbeiten wollt?

Die OXG Seite gibt zu diesen Fragen leider wenig her, wenn Du also etwas dazu sagen kannst (natuerlich ohne Gewaehr, also als private Meinung) waere das grossartig.

Dank im Voraus.