8
Downloadrate sinkt massiv während des Surfens
Moin,
ich habe aktuell ein sehr merkwürdiges Verhalten meines DSL Anschlusses. Bei dem DSL Anschluss handelt es sich um einen 50.000er Anschluss von der EWE. Der Anschluss besitzt aktuell noch kein Vectoring und die Leitungslänge ist ca. 500m.
Folgendes Verhalten:
Wenn ich eine große Datei (z.B. vom Hetzner Speedtest Server) mittels wget herunterlade, erhalte ich meine volle 6,1MB/s Netto Downloadrate, Brutto 53Mbit/s. Dies bleibt auch sehr konstant und sinkt ggf. maximal auf 5,9MB/s ab. Nehme ich mir jetzt ein anderes Gerät im Netzwerk in die Hand oder das Gerät auf dem der Download läuft und rufe eine beliebige Webseite auf mit viel Inhalt, so droppt die Downloadrate auf knapp 2,5MB/s ab und steigt dann langsam wieder auf 6MB/s. Schaue ich mir die übertragenen Bits mit bmon an, so sehe ich einen Einbruch der Gesamtbandbreite und nicht wie man z.B. vermuten könnte, dass sich das Laden der Webseite sowie der Download wieder auf 6,1MB/s summiert. Gewisse Schwankungen sind natürlich normal, aber so massiv, habe ich bisher an noch keinem anderen Anschluss gesehen. Ich habe den gleichen Test an einem 50.000er Anschluss der EWE ohne Vectoring (allerdings mit kürzerer Leitung) gemacht und hier gibt es nur minimale Schwankungen, die nicht mit meinem Anschluss vergleichbar sind.
Ich habe hier einmal die Leitungsdaten angehangen:
Die SNR ist mit 6db zwar an der Grenze, aber auch ein manuelles erhöhen der SNR ändert nichts am beobachteten Verhalten
Das Spektrum der Leitung
Der bmon Graph während eines Downloads. An den Einbrüchen habe ich eine Webseite aufgerufen.
Was ich bereits versucht habe:
- Fritzbox 7490 gegen eine andere Fritzbox 7490 ausgetauscht
- Mein Linux Notebook direkt mittels Draytek Vigor 165 als Modem angeschlossen und mittels PPPoE eingewählt. Auch hier gibt es das gleiche Verhalten, somit habe ich mein eigentlich Heimnetzwerk ausgeschlossen.
- Keine CRC bzw ES Fehler während des Drops.
Ich habe aktuell keine Ahnung mehr woran das liegen könnte und debugge dieses Verhalten schon seit Stunden.
Ob jetzt am Modem TCP Traffic vom Downloadstream oder vom Webbrowser ankommt sollte doch für die Leitung eigentlich egal sein.
Der einzige Unterschied zwischen dem Webbrowser Traffic und dem Downloadtraffic ist die ggf. unterschiedliche MTU des Pakets, aber ich konnte hier noch eine Korrelation mit Wireshark feststellen.
Vielleicht hat einer von euch eine Idee, woran dies liegen könnte bzw. was ich noch probieren könnte?
ich habe aktuell ein sehr merkwürdiges Verhalten meines DSL Anschlusses. Bei dem DSL Anschluss handelt es sich um einen 50.000er Anschluss von der EWE. Der Anschluss besitzt aktuell noch kein Vectoring und die Leitungslänge ist ca. 500m.
Folgendes Verhalten:
Wenn ich eine große Datei (z.B. vom Hetzner Speedtest Server) mittels wget herunterlade, erhalte ich meine volle 6,1MB/s Netto Downloadrate, Brutto 53Mbit/s. Dies bleibt auch sehr konstant und sinkt ggf. maximal auf 5,9MB/s ab. Nehme ich mir jetzt ein anderes Gerät im Netzwerk in die Hand oder das Gerät auf dem der Download läuft und rufe eine beliebige Webseite auf mit viel Inhalt, so droppt die Downloadrate auf knapp 2,5MB/s ab und steigt dann langsam wieder auf 6MB/s. Schaue ich mir die übertragenen Bits mit bmon an, so sehe ich einen Einbruch der Gesamtbandbreite und nicht wie man z.B. vermuten könnte, dass sich das Laden der Webseite sowie der Download wieder auf 6,1MB/s summiert. Gewisse Schwankungen sind natürlich normal, aber so massiv, habe ich bisher an noch keinem anderen Anschluss gesehen. Ich habe den gleichen Test an einem 50.000er Anschluss der EWE ohne Vectoring (allerdings mit kürzerer Leitung) gemacht und hier gibt es nur minimale Schwankungen, die nicht mit meinem Anschluss vergleichbar sind.
Ich habe hier einmal die Leitungsdaten angehangen:
Was ich bereits versucht habe:
- Fritzbox 7490 gegen eine andere Fritzbox 7490 ausgetauscht
- Mein Linux Notebook direkt mittels Draytek Vigor 165 als Modem angeschlossen und mittels PPPoE eingewählt. Auch hier gibt es das gleiche Verhalten, somit habe ich mein eigentlich Heimnetzwerk ausgeschlossen.
- Keine CRC bzw ES Fehler während des Drops.
Ich habe aktuell keine Ahnung mehr woran das liegen könnte und debugge dieses Verhalten schon seit Stunden.
Ob jetzt am Modem TCP Traffic vom Downloadstream oder vom Webbrowser ankommt sollte doch für die Leitung eigentlich egal sein.
Der einzige Unterschied zwischen dem Webbrowser Traffic und dem Downloadtraffic ist die ggf. unterschiedliche MTU des Pakets, aber ich konnte hier noch eine Korrelation mit Wireshark feststellen.
Vielleicht hat einer von euch eine Idee, woran dies liegen könnte bzw. was ich noch probieren könnte?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 517997
Url: https://administrator.de/contentid/517997
Ausgedruckt am: 25.11.2024 um 17:11 Uhr
8 Kommentare
Neuester Kommentar
Das könnte durch Packetloss durch kurzzeitige Überlastung der VDSL-Verbindung erklärbar sein.
Dadurch wird sofort das TCP-Window des Downloads erstmal verringert und dann langsam wieder vergrößert.
Dieser Packetloss muss nicht lange auftreten, es reichen wenige Millisekunden, um Pakete verloren gehen zu lassen.
Würde jedes empfangene TCP-Paket einzeln ge-ACK-ed werden müssen, hättest du bedingt durch die Latenzen nur sehr geringe Bandbreiten.
Deshalb wird über das Receive-Window durch den Empfänger angegeben, wie viele Pakete am Stück empfangen werden können, bis diese dann en bloc mit einem einzigen ACK quittiert werden.
Gehen jetzt aber Pakete verloren, wird das TCP-Window entweder durch den Empfänger oder den Absender verkleinert und dann langsam wieder vergrößert solange die Pakete fehlerfrei ankommen. Das ist dann auch gleichzeitig Congestion Control auf TCP-Basis.
Am Praxisbeispiel erklärt wäre das:
Wenn du 6 MByte pro Sekunde empfangen willst und dein TCP-Payload pro Paket auf der VDSL-Verbindung (MSS) maximal 1452 Bytes groß werden kann, musst du eine Paketrate von 4.333 Paketen pro Sekunde erreichen. Wir nehmen jetzt einfach mal eine Übertragungsdauer von 1/5000 Sekunde pro Paket an.
Würdest du jetzt dein TCP-Window auf - beispielhaft - 10 KByte festlegen und du hättest eine relativ hohe Latenz (RTT) von 50ms zwischen dir und dem Server, käme folgendes Problem auf:
Vergrößerst du jetzt das TCP-Window, bekommst du mehr Pakete pro Sekunde übertragen und reduzierst die Wartezeiten, die jetzt schlicht viel seltener auftreten.
Wenn dann die vom Browser geöffneten TCP-Verbindungen (und es sind schließlich mehrere) jeweils mit relativ großen Receive-Windows anfangen, schicken die Server mehr Daten, als durch deine VDSL-Verbindung transportiert werden können. Das führt auf allen Verbindungen zu leichtem Packetloss und damit auch zur Verkleinerung der Receive-Windows aller betroffenen TCP-Verbindungen.
Denn wenn die Pakete verloren gehen, ist die Ursache nicht selten, dass eine Verbindung so stark ausgelastet ist, dass nicht mehr alle Pakete hindurch passen. Also reguliert TCP hier über das Receive-Window die Anzahl Pakete pro Sekunde herunter, so dass erstmal wieder alles passt.
Dieser Regulierungsmechanismus braucht allerdings immer ein paar Sekunden, bis er wieder auf die ursprüngliche Größe zurückkehrt.
Ob das bei dir die Ursache ist, kannst du mit Wireshark auf deinem Client prüfen. Lasse einen Capture während dem Download laufen und öffne dann woanders Webseiten. Wenn dann TCP-Retransmissions auftreten, sind Pakete verloren gegangen. Dazwischen wirst du dann auch Pakete mit Window-Updates sehen, bei denen die Window-Size verändert wurde.
Dadurch wird sofort das TCP-Window des Downloads erstmal verringert und dann langsam wieder vergrößert.
Dieser Packetloss muss nicht lange auftreten, es reichen wenige Millisekunden, um Pakete verloren gehen zu lassen.
Würde jedes empfangene TCP-Paket einzeln ge-ACK-ed werden müssen, hättest du bedingt durch die Latenzen nur sehr geringe Bandbreiten.
Deshalb wird über das Receive-Window durch den Empfänger angegeben, wie viele Pakete am Stück empfangen werden können, bis diese dann en bloc mit einem einzigen ACK quittiert werden.
Gehen jetzt aber Pakete verloren, wird das TCP-Window entweder durch den Empfänger oder den Absender verkleinert und dann langsam wieder vergrößert solange die Pakete fehlerfrei ankommen. Das ist dann auch gleichzeitig Congestion Control auf TCP-Basis.
Am Praxisbeispiel erklärt wäre das:
Wenn du 6 MByte pro Sekunde empfangen willst und dein TCP-Payload pro Paket auf der VDSL-Verbindung (MSS) maximal 1452 Bytes groß werden kann, musst du eine Paketrate von 4.333 Paketen pro Sekunde erreichen. Wir nehmen jetzt einfach mal eine Übertragungsdauer von 1/5000 Sekunde pro Paket an.
Würdest du jetzt dein TCP-Window auf - beispielhaft - 10 KByte festlegen und du hättest eine relativ hohe Latenz (RTT) von 50ms zwischen dir und dem Server, käme folgendes Problem auf:
- Du empfängst einen Block mit 10 KB Payload (entspricht 8 Paketen). Das dauert 8 * (1/5000) Sekunden = 0,0016s.
- Du sendest einen ACK für diesen Block - aber natürlich erst, wenn du das letzte Paket des Block mit Payload empfangen hast.
- Dadurch entsteht eine Lücke von den 25ms Latenz in eine Richtung, bis das letzte Paket bei dir ankommt und du den ACK sendest.
- Dieser ACK braucht ebenfalls 25ms, bis er beim Absender ankommt
- Dann hast du wieder 25ms Wartezeit, bis du die nächsten 8 Pakete mit Payload erhältst.
- Das macht also 0,0016s + 0,0075s = 0,0091s je Payload-Block.
- Damit sind maximal 109 solcher Blöcke pro Sekunde übertragbar.
- Das entspricht 109 * 10 KByte = ~1,1 MByte/s bzw. 109 * 8 Pakete = 872 Pakete/s.
- Obwohl deine Verbindung viel höhere Datenraten ermöglichen würde, hättest du trotzdem keine ordentlichen Geschwindigkeiten bedingt durch die langen Wartezeiten aufgrund der Latenz ("Long fat line problem")
Vergrößerst du jetzt das TCP-Window, bekommst du mehr Pakete pro Sekunde übertragen und reduzierst die Wartezeiten, die jetzt schlicht viel seltener auftreten.
Wenn dann die vom Browser geöffneten TCP-Verbindungen (und es sind schließlich mehrere) jeweils mit relativ großen Receive-Windows anfangen, schicken die Server mehr Daten, als durch deine VDSL-Verbindung transportiert werden können. Das führt auf allen Verbindungen zu leichtem Packetloss und damit auch zur Verkleinerung der Receive-Windows aller betroffenen TCP-Verbindungen.
Denn wenn die Pakete verloren gehen, ist die Ursache nicht selten, dass eine Verbindung so stark ausgelastet ist, dass nicht mehr alle Pakete hindurch passen. Also reguliert TCP hier über das Receive-Window die Anzahl Pakete pro Sekunde herunter, so dass erstmal wieder alles passt.
Dieser Regulierungsmechanismus braucht allerdings immer ein paar Sekunden, bis er wieder auf die ursprüngliche Größe zurückkehrt.
Ob das bei dir die Ursache ist, kannst du mit Wireshark auf deinem Client prüfen. Lasse einen Capture während dem Download laufen und öffne dann woanders Webseiten. Wenn dann TCP-Retransmissions auftreten, sind Pakete verloren gegangen. Dazwischen wirst du dann auch Pakete mit Window-Updates sehen, bei denen die Window-Size verändert wurde.
2
Moin,
vielen Dank für die schnelle Antwort. Ich habe direkt mal ein paar Wireshark Dumps erstellt.
Das ist nur der Downloadstream der 1GB Downloaddatei. Man sieht einige TCP Fehler und zwischen 28s und 30s gibt es ein Window Update, was leider wegen der Skalierung nicht ganz eindeutig erkennbar ist.
Dies ist ein Graph von allen Paketen auf der Leitung (ich habe auf dem gleichen Laptop die Webseiten aufgerufen). Hier sieht man noch deutlich mehr Retransmissions. Ich habe gesehen, dass ebenfalls TCP Fehler in den anderen TCP Streams der Webseiten auftauchen.
Das sind die TCPFehler die beim Einbruch auftreten.
Und hier habe ich einmal Wondershaper (TrafficShaper) für Linux aktiviert und meine Bandbreite auf 30.000 gedrosselt. Die Fehler treten aber weiterhin auf, was mir sehr merkwürdig vorkommt? Eigentlich müsste die Leitung doch gerade hier noch Reserve nach oben haben? Ebenfalls wenn ich es auf 20.000 reduziere. Das ist schon sehr merkwürdig 
Und auch hier erhalte ich wie oben die TCP Fehler, selbst wenn es auf 20.000 gedrosselt ist.
Bestätigen diese Messungen deine Vermutung?
Wieso tritt das ausgerechnet an meiner VDSL Leitung auf und an anderen nicht? Sind das minimale Störungen? Aber eigentlich sollten Leitungsfehler doch bereits auf deutlich niedrigeren Layern behoben werden (Interleaving etc.) und der Layer4 sollte von physikalischen Leitungsfehler gar nichts mehr mitbekommen.
vielen Dank für die schnelle Antwort. Ich habe direkt mal ein paar Wireshark Dumps erstellt.
Und auch hier erhalte ich wie oben die TCP Fehler, selbst wenn es auf 20.000 gedrosselt ist.Bestätigen diese Messungen deine Vermutung?
Wieso tritt das ausgerechnet an meiner VDSL Leitung auf und an anderen nicht? Sind das minimale Störungen? Aber eigentlich sollten Leitungsfehler doch bereits auf deutlich niedrigeren Layern behoben werden (Interleaving etc.) und der Layer4 sollte von physikalischen Leitungsfehler gar nichts mehr mitbekommen.
Die Kombination aus Retransmissions, tatsächlich fehlenden Paketen ("Previous segment not captured") und Duplicate Acks ist tatsächlich typisch für verstopfte Leitungen. Die ACKs sind im Zweifel nämlich nicht wirklich doppelt, sondern wurden schlicht einfach nur zwei Mal gesendet, weil auf das erste Mal scheinbar keine Antwort zurück kam.
Und insbesondere dieses sägezahnartige Muster bei den I/O-Graphen bis zum nächsten Packet-Drop ist ein sicheres Anzeichen dafür
Die Fehler, die da auftreten, sind nicht zwingend Leitungsfehler, deshalb können sie per CRC auch nicht korrigiert werden.
Die DSL-Linecards beim Provider haben - wie quasi jedes Ethernet-Gerät - einen kleinen Buffer, in den die Pakete hinein kommen wenn sie nicht sofort durch die Leitung gesendet werden können.
Ist die maximale Paketrate für die Leitung also erreicht und es kommen weitere Pakete, stapeln sich diese erstmal im Buffer. Und wenn der voll sind, werden die einfach so lange verworfen, bis wieder Platz ist resp. die Pakete wieder direkt durch die Leitung gesendet werden können.
Manche Router verhindern sowas gezielt, indem in den TCP-Headern herumgepfuscht und die Window-Size beim Traversieren des Routers verkleinert wird. Da sich beide Seiten implizit auf den niedrigsten Wert beider Gegenstellen einigen, ist das technisch auch problemlos umsetzbar. Sowas wird teilweise auch als Teil von QoS unbemerkt von den Routern angewendet, um genau diese Packetloss-Probleme (die ja alle ein- oder ausgehenden Pakete betreffen) für VoIP zu vermeiden.
Diese Probleme können abhängig von der Gegenstelle mal mehr und mal weniger stark ausgeprägt sein, ebenfalls spielt ja insbesondere die Latenz zum Server eine wichtige Rolle. Auch die anderen Clients im Netzwerk spielen eine große Rolle, auch die Software - denn die kann in engen Grenzen Einfluss auf die Window-Size nehmen.
Gerade um Webseitenabrufe zu Beschleunigen, werden manchmal irre viele gleichzeitige TCP-Verbindungen aufgebaut und auch die Receive-Windows direkt von Anfang an sehr groß gewählt - denn wenn man erstmal während dem Download der Seiteninhalt versucht, das Window anzupassen, ist das meiste bereits (langsamer) übertragen worden
So ein Client erzeugt bei entsprechend optimierten Webseiten dann natürlich spürbar mehr Probleme.
Hast du einmal eine andere Downloadquelle getestet, z.B. http://speedtest.tele2.net/ ?
Dort kannst du einen Standort suchen, der Latenzmäßig möglichst günstig für dich liegt und einmal testen, ob das genau so schlimm ist wie bei dem Download vom Hetzner-Server.
Denn dass das beim Hetzner-Server eventuell auch bei 20 Mbps noch relativ schlecht läuft könnte durchaus auch ein Problem bei Hetzner sein. Die Switches werden da gerne mal so lange überbucht, bis sich die Kunden beschweren. Und die scheinen oft hart im Nehmen zu sein
Und insbesondere dieses sägezahnartige Muster bei den I/O-Graphen bis zum nächsten Packet-Drop ist ein sicheres Anzeichen dafür
Die Fehler, die da auftreten, sind nicht zwingend Leitungsfehler, deshalb können sie per CRC auch nicht korrigiert werden.
Die DSL-Linecards beim Provider haben - wie quasi jedes Ethernet-Gerät - einen kleinen Buffer, in den die Pakete hinein kommen wenn sie nicht sofort durch die Leitung gesendet werden können.
Ist die maximale Paketrate für die Leitung also erreicht und es kommen weitere Pakete, stapeln sich diese erstmal im Buffer. Und wenn der voll sind, werden die einfach so lange verworfen, bis wieder Platz ist resp. die Pakete wieder direkt durch die Leitung gesendet werden können.
Manche Router verhindern sowas gezielt, indem in den TCP-Headern herumgepfuscht und die Window-Size beim Traversieren des Routers verkleinert wird. Da sich beide Seiten implizit auf den niedrigsten Wert beider Gegenstellen einigen, ist das technisch auch problemlos umsetzbar. Sowas wird teilweise auch als Teil von QoS unbemerkt von den Routern angewendet, um genau diese Packetloss-Probleme (die ja alle ein- oder ausgehenden Pakete betreffen) für VoIP zu vermeiden.
Diese Probleme können abhängig von der Gegenstelle mal mehr und mal weniger stark ausgeprägt sein, ebenfalls spielt ja insbesondere die Latenz zum Server eine wichtige Rolle. Auch die anderen Clients im Netzwerk spielen eine große Rolle, auch die Software - denn die kann in engen Grenzen Einfluss auf die Window-Size nehmen.
Gerade um Webseitenabrufe zu Beschleunigen, werden manchmal irre viele gleichzeitige TCP-Verbindungen aufgebaut und auch die Receive-Windows direkt von Anfang an sehr groß gewählt - denn wenn man erstmal während dem Download der Seiteninhalt versucht, das Window anzupassen, ist das meiste bereits (langsamer) übertragen worden
So ein Client erzeugt bei entsprechend optimierten Webseiten dann natürlich spürbar mehr Probleme.
Hast du einmal eine andere Downloadquelle getestet, z.B. http://speedtest.tele2.net/ ?
Dort kannst du einen Standort suchen, der Latenzmäßig möglichst günstig für dich liegt und einmal testen, ob das genau so schlimm ist wie bei dem Download vom Hetzner-Server.
Denn dass das beim Hetzner-Server eventuell auch bei 20 Mbps noch relativ schlecht läuft könnte durchaus auch ein Problem bei Hetzner sein. Die Switches werden da gerne mal so lange überbucht, bis sich die Kunden beschweren. Und die scheinen oft hart im Nehmen zu sein
1
Danke für die wieder sehr ausführliche Antwort.
Ich habe noch einmal einen Test mit speedtest.net gemacht im Single Stream Modus, da dort die EWE einen eigenen Server betreibt. Unter 20ms komme ich nicht, da auf der Leitung noch ein Interleaving von knapp 15ms drauf ist. Hier habe ich das gleiche Ergebnis.
Für mich macht das Sinn mit dem Buffer, allerdings ist dann natürlich die Frage, warum passen 53Mbit/s Single Stream durch, aber sobald man mehrere Streams hat droppt alles? Das finde ich nicht ganz nachvollziehbar.
Edit: OK vermutlich, wie von dir geschrieben, weil die diverse TCP Streams öffnen mit großer Windows Size.
Ich glaube nicht, dass das an Hetzner liegt, was auch speedtest.net bestätigt hat. Und das die TCP Fehler ebenfalls mit Traffic Shaping auf 20Mbps auftreten finde ich auch merkwürdig, da die DSL Leitung, dann ja eigentlich noch massig Reserven hätte und sich deshalb gar nichts im Buffer aufstauen sollte. Oder habe ich da einen Denkfehler?
Die Frage ist ja auch, was wäre die Lösung? Gibt keine? :D
Solche Probleme haben andere Leitungen ja definitiv nicht, deswegen kommt mir das mit dem Bufferproblem auch etwas merkwürdig vor und ich glaube nicht, dass die sich bezüglich Hardware im Outdoor-DSLAM groß unterscheiden (habe das ebenfalls an einer anderen Leitung getestet, wo die gleiche Linecard verbaut ist, und an der anderen Leitung treten diese Probleme nicht auf).
Oder gibt es hier ggf. auf Seiten des ISPs eine Störung im DSLAM, sodass ich das Problem habe, auch wenn ich aktuell noch nicht ganz nachvollziehen kann, wo da eins sein könnte, der dies zum Resultat hat?
Ich habe noch einmal einen Test mit speedtest.net gemacht im Single Stream Modus, da dort die EWE einen eigenen Server betreibt. Unter 20ms komme ich nicht, da auf der Leitung noch ein Interleaving von knapp 15ms drauf ist. Hier habe ich das gleiche Ergebnis.
Für mich macht das Sinn mit dem Buffer, allerdings ist dann natürlich die Frage, warum passen 53Mbit/s Single Stream durch, aber sobald man mehrere Streams hat droppt alles? Das finde ich nicht ganz nachvollziehbar.
Edit: OK vermutlich, wie von dir geschrieben, weil die diverse TCP Streams öffnen mit großer Windows Size.
Ich glaube nicht, dass das an Hetzner liegt, was auch speedtest.net bestätigt hat. Und das die TCP Fehler ebenfalls mit Traffic Shaping auf 20Mbps auftreten finde ich auch merkwürdig, da die DSL Leitung, dann ja eigentlich noch massig Reserven hätte und sich deshalb gar nichts im Buffer aufstauen sollte. Oder habe ich da einen Denkfehler?
Die Frage ist ja auch, was wäre die Lösung? Gibt keine? :D
Solche Probleme haben andere Leitungen ja definitiv nicht, deswegen kommt mir das mit dem Bufferproblem auch etwas merkwürdig vor und ich glaube nicht, dass die sich bezüglich Hardware im Outdoor-DSLAM groß unterscheiden (habe das ebenfalls an einer anderen Leitung getestet, wo die gleiche Linecard verbaut ist, und an der anderen Leitung treten diese Probleme nicht auf).
Oder gibt es hier ggf. auf Seiten des ISPs eine Störung im DSLAM, sodass ich das Problem habe, auch wenn ich aktuell noch nicht ganz nachvollziehen kann, wo da eins sein könnte, der dies zum Resultat hat?
Wechsle die Anschluß-Technik!
Bei 500 m ist VDSL2 schon fast überfordert. Außerdem ist das eine "bis zu" Technologie mit der es nur 'manchmal' schnelles Internet gibt.
Du brauchst ungeteilte Resoucen, also kein Funk oder Kabelnetz sondern FTTH oder zumindest FTTB, die kennen kein "bis zu".
Muß ich noch mehr schreiben?
Ich hoffe du findest einen Anbieter dafür, möglichst nicht die 'Telekomiker'.
Bei 500 m ist VDSL2 schon fast überfordert. Außerdem ist das eine "bis zu" Technologie mit der es nur 'manchmal' schnelles Internet gibt.
Du brauchst ungeteilte Resoucen, also kein Funk oder Kabelnetz sondern FTTH oder zumindest FTTB, die kennen kein "bis zu".
Muß ich noch mehr schreiben?
Ich hoffe du findest einen Anbieter dafür, möglichst nicht die 'Telekomiker'.
Wenn es Alternativen auf dem Dorf geben würde. Bin froh dass ich überhaupt VDSL bekomme. Ich kenne mehrere die haben ebenfalls 500m Leitungslänge mit 50Mbit/s, aber eben mit Vectoring, das läuft wie blöd und durch die neuen 60/12 Profile der Telekom bekommt er dort auch 58Mbit/s über VVDSL50 durch.
Bei uns ist das leider so, dass der VDSL 2014 gefördert wurde. Wegen irgendwelchen Auflagen des Bundes darf dieser Outdoor DSLAM erst Ende 2020 mit Vectoring ausgerüstet werden und dann wohl mit viel Papierkram.
Unser Landkreis baut aktuell Glasfaser aus, allerdings nur die Häuser 80m weiter als wir, da wir mit offiziell 37Mbit/s nicht die Förderung des Bundes bekommen, dann baut keiner freiwillig aus.
Alternative Zugangstechnologie wäre Spaten uns Glasfaser einmal Quer durch Nachbarsgarten bis zu den Häusern mit Glasfaseranschluss oder Richtfunk ;P
Aber bis das Kabel liegt habe ich vermutlich dann doch Vectoring :D
Ich finde dieses aktuelle Fehlerbild einfach nur absolut merkwürdig. Wäre die Leitung an der Grenze hätte sie kein FullSync und ich hätte ggf. auch diverse Fehler im Log, aber nichts davon. Sie liefert ja auch 6MB/s, allerdings nur wenn keiner im Internet surft, und das ist das absolut merkwürdige ;)
Bei uns ist das leider so, dass der VDSL 2014 gefördert wurde. Wegen irgendwelchen Auflagen des Bundes darf dieser Outdoor DSLAM erst Ende 2020 mit Vectoring ausgerüstet werden und dann wohl mit viel Papierkram.
Unser Landkreis baut aktuell Glasfaser aus, allerdings nur die Häuser 80m weiter als wir, da wir mit offiziell 37Mbit/s nicht die Förderung des Bundes bekommen, dann baut keiner freiwillig aus
.Alternative Zugangstechnologie wäre Spaten uns Glasfaser einmal Quer durch Nachbarsgarten bis zu den Häusern mit Glasfaseranschluss oder Richtfunk ;P
Aber bis das Kabel liegt habe ich vermutlich dann doch Vectoring :D
Ich finde dieses aktuelle Fehlerbild einfach nur absolut merkwürdig. Wäre die Leitung an der Grenze hätte sie kein FullSync und ich hätte ggf. auch diverse Fehler im Log, aber nichts davon. Sie liefert ja auch 6MB/s, allerdings nur wenn keiner im Internet surft, und das ist das absolut merkwürdige ;)
Moin, ich habe heute mal mit meinem ISP telefoniert. Dieser konnte keine Fehler auf der Leitung entdecken, wie zu vermuten war, da die physikalische Leitung ja scheinbar keine Probleme macht. Dennoch habe ich, wenn ich während eines Downloads eine Webseite besuche weiter diverse TCP Retransmissions. Wenn ich einen Iperf Test mache, sieht man auch diverse Retransmissions:
Ich frage mich gerade, wie man den Fehler weiter eingrenzen könnte? Das Problem tritt ja ebenfalls zu ISP eigenen Servern auf (speedtest.net im Single Download Modus z.B.)
Wenn ich einen UDP Test mit 50Mbit/s (entsprechender kleiner Paketlänge) werden teilweise 50% der Pakete gedroppt. Das wirkt für mich ebenfalls nicht ganz normal
Ich frage mich gerade, wie man den Fehler weiter eingrenzen könnte? Das Problem tritt ja ebenfalls zu ISP eigenen Servern auf (speedtest.net im Single Download Modus z.B.)
Wenn ich einen UDP Test mit 50Mbit/s (entsprechender kleiner Paketlänge) werden teilweise 50% der Pakete gedroppt. Das wirkt für mich ebenfalls nicht ganz normal
Eine mögliche Erklärung wäre, dass da ein Traffic-Shaping auf Seiten des DSL-Ports beim Anbieter stattfindet.
Das ist zwar etwas, was in der Regel nur bei Vectoring eingesetzt wird, da sich hier die Geschwindigkeit des Anschlusses nicht mehr über die Festlegung des DSL-Profils limitieren lässt.
Allerdings könnte ich mir durchaus vorstellen, dass zwecks einheitlicher Konfiguration pauschal alle DSL-Ports immer mit entsprechenden Shapern versehen werden, auch wenn normales VDSL ohne Vectoring benutzt wird - an solchen Anschlüssen entspricht die Shaping-Bandbreite halt der Bandbreite, die das verwendete DSL-Profil bietet.
Allerdings arbeiten die Shaper meistens so, dass die Bandbreite gemessen wird und bei Erreichen der maximal erlaubten Bandbreite teilweise Pakete verworfen werden, bis die Bandbreite wieder passt.
Wenn der Shaper geringfügig weniger Bandbreite erlaubt als das DSL-Profil her gäbe (z.B. weil jemand strikt 50.000.000 bps konfiguriert hat) und auch nur geringe Burst-Toleranzen konfiguriert sind, könnte das zum beobachteten Phänomen passen.
Teilweise werden die Shaper auch an der falschen Seite des DSL-Ports angesetzt und messen den PPPoE-Overhead als Bandbreite mit.
Abhilfe schafft da meistens, die Burst-Toleranzen etwas zu erhöhen und auch das Shaping-Limit um ein paar hundert Kilobit/s zu erhöhen.
Vielleicht kann dir dein Anbieter dazu ja was sagen
Das ist zwar etwas, was in der Regel nur bei Vectoring eingesetzt wird, da sich hier die Geschwindigkeit des Anschlusses nicht mehr über die Festlegung des DSL-Profils limitieren lässt.
Allerdings könnte ich mir durchaus vorstellen, dass zwecks einheitlicher Konfiguration pauschal alle DSL-Ports immer mit entsprechenden Shapern versehen werden, auch wenn normales VDSL ohne Vectoring benutzt wird - an solchen Anschlüssen entspricht die Shaping-Bandbreite halt der Bandbreite, die das verwendete DSL-Profil bietet.
Allerdings arbeiten die Shaper meistens so, dass die Bandbreite gemessen wird und bei Erreichen der maximal erlaubten Bandbreite teilweise Pakete verworfen werden, bis die Bandbreite wieder passt.
Wenn der Shaper geringfügig weniger Bandbreite erlaubt als das DSL-Profil her gäbe (z.B. weil jemand strikt 50.000.000 bps konfiguriert hat) und auch nur geringe Burst-Toleranzen konfiguriert sind, könnte das zum beobachteten Phänomen passen.
Teilweise werden die Shaper auch an der falschen Seite des DSL-Ports angesetzt und messen den PPPoE-Overhead als Bandbreite mit.
Abhilfe schafft da meistens, die Burst-Toleranzen etwas zu erhöhen und auch das Shaping-Limit um ein paar hundert Kilobit/s zu erhöhen.
Vielleicht kann dir dein Anbieter dazu ja was sagen
1
