Sendepuffer des Kabelmodems (Thomson THG540)

[Matze88]

Hallo zusammen,

ich bin immernoch geplagter des Problems, dass mein Ping bei Auslastung der Leitung sehr sehr stark einbricht; Dabei hilft nichteinmal vernünftiges QoS, da scheinbar meine Leitungskapazität bei zunehmender Last abnimmt. Unabhängig davon nun einmal ein neuer Bericht. Situation:
FritzBox 7270, Thomson THG 540, Kabel D 32 Mbit/2 Mbit in 22880 Wedel.
Speedtest z.Zt. unbekannt da mich Speedtests nicht interessieren sondern die normale Nutzung. Ich würde mich selbst als Poweruser bezeichnen, z.B. nutze ich auch häufig Bittorrent und habe große Up- und Downloads häufiger zu tätigen. Auch wenn es mir niemand glauben mag, mein Traffic beschränkt sich zu 99,9 % auf völlig legale Aktivitäten.

Gerade lade ich 100 MB per FTP ohne Speedlimit hoch. Fritzbox QoS ist auf 900 kBit/s Senden eingestellt. Nebenbei erstelle ich einen Ping (1 Ping pro Sekunde) zu google.de:
Bei icmp_seq 53 stelle ich das Speedlimit auf 800 kBit/s.

Code: Alles auswählen

64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=45 ttl=49 time=1984 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=46 ttl=49 time=2024 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=47 ttl=49 time=1942 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=48 ttl=49 time=1876 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=49 ttl=49 time=1859 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=50 ttl=49 time=1875 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=51 ttl=49 time=1949 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=52 ttl=49 time=2010 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=53 ttl=49 time=1880 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=54 ttl=49 time=1705 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=55 ttl=49 time=1569 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=56 ttl=49 time=1545 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=57 ttl=49 time=1422 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=58 ttl=49 time=1344 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=59 ttl=49 time=1276 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=60 ttl=49 time=1044 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=61 ttl=49 time=913 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=62 ttl=49 time=657 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=63 ttl=49 time=533 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=64 ttl=49 time=500 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=65 ttl=49 time=448 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=66 ttl=49 time=106 ms
64 bytes from gv-in-f104.1e100.net (216.239.59.104): icmp_seq=67 ttl=49 time=49.2 ms [nachfolgende Pings zwischen 30 und 40 ms] 

QoS ist übrigens so eingestlelt, dass ICMP bevorzugt behandelt wird.
Nun kann mir kein Speedtest der Welt sagen, dass meine Leitung zur Zeit eine Kapazität von 1400 kBit/s oder sowas aufweist. Ich sehe ja hier, dass bei allem über 800 kBit/s irgendwelche Sendepuffer, die ja nur im Kabelmodem liegen können, da die Fritzbox selbst wegen QoS ja Daten nicht schneller rausschickt, so voll laufen, dass ein normaler Internetverkehr nicht möglich ist. Die Antwortzeiten können übrigens bei entsprechendem Traffic noch weiter steigen, in anderen TEsts mit Torrent etc. komme ich trotz QoS << 2000 kBit/s auf Pingzeiten von 20 bis 40 SEKUNDEN.
Warum schreibe ich das alles hier? Hmm, vielleicht finden sich gleichgesinnte oder so. Mich regt die Situation auf, KDG macht absolut garnichts. Zuletzt habe ich vor einigen Monaten mit der Hotline telefoniert, da hieß es nur, ich solle mich doch bitte freuen, dass ich überhaupt solche Bandbreiten erreiche. Ich stehe ehrlich gesagt kurz davor, außerordentlich zu kündigen. Problem ist nur, dass ich dann wieder (wegen des Preises) zu Alice müsste; und mit Alice habe ich so schlechte Hotlineerfahrugnen gemacht, dass ich da nie wieder hin möchte (die haben mich sozusagen um 50€ betrogen und sehen das nicht ein, Rechtsanwalt lohnt bei dem Betrag nicht).

[_mrice_]

Das Problem kenne ich von Fritz-Boxen an normalen DSL-Anschlüssen, offensichtlich kommen die damit nicht klar, wenn zu viele gleichzeitige Verbindungen offen sind. Hast du das Szenario mal ohne die Fritte direkt am Modem getestet ?

[Thyrael]

Ohne FritzBox am Modem rbauch er doch auch wieder nen anderes Programm was für Traffic Shaping sorgt? Von Haus aus macht das doch kein Betriebssystem so "out of the Box"?

[VBE-Berlin]

Das Problem kenne ich von Fritz-Boxen an normalen DSL-Anschlüssen, offensichtlich kommen die damit nicht klar, wenn zu viele gleichzeitige Verbindungen offen sind.

Dieses Problem haben eigentlich alle SOHO-Router.
Irgendwann ist der Prozessor/Speicher des Routers auch mal ausgelastet.

MB-Berlin

[Matze88]

Ja, ich habe selbst auch die FritzBox in Verdacht, bei einer gewissen (und zwar nicht gerade hohen) Anzahl Verbindungen ein enormer Flaschenhals zu sein, ohne das dies aus der Systemlast erkennbar ist. Leider konnte ich dies bisher nicht ausreichend nachtesten, da ich momentan nicht in der Lage bin, das Kabelmodem direkt an unserem Internet-Verteilserver zu betreiben.
Dennoch ist das ja für das Problem des Sendepuffers unerheblich, ich rede hier von 2,5 gleichzeitigen Verbindungen: FTP Data hochladend, FTP Kommando inaktiv und dazu das ICMP...

Leider habe ich hier in der Vergangenheit schon bemerkt, dass es zu wenig hochqualifizierte Diskussion hier gibt, sodass ich solche Tests wohl garnicht mehr hier schreiben brauch. Ist nicht bös gemeint (vor allem Danke ich sehr gerne allen, die Versuchen dazu was beizutragen), aber es scheint ja irgendwie nichts zu bringen.

Zum Thema Bittorrent nebenbei:
Ich bin schon froh, dass ich seit längerem nicht mehr von der KD-Drosselung betroffen bin; Andrerseits seh ichs ja auch ein, dass ich nicht abends zu Stoßzeiten größere Datenübertragungen machen muss, die ich genausogut früh morgens erledigen kann.

[Ronnenberg]

Diese Probleme mit Torrent hat meine Fritte nicht. Ich muss nur Kaspersky richtig Configurieren und upnp muss an sein sowie Fritzbox Tunning (wie erkläre ich morgen) und Azureus sowie guten PC und Anschluss.

[Matze88]

Diese Probleme mit Torrent hat meine Fritte nicht. Ich muss nur Kaspersky richtig Configurieren und upnp muss an sein sowie Fritzbox Tunning (wie erkläre ich morgen) und Azureus sowie guten PC und Anschluss.

Mooooment, du bringst hier was durcheinander:
a) Desktop"sicherheitssysteme" haben keinen Einfluss auf die Performance einer von ihnen unabhängigen Hardware
b) upnp hat keinen Einfluss auf die Geschwindigkeit der FritzBox
c) Es sollte egal sein, welches Programm man verwendet und sowieso egal, welchen PC (für Bittorrent), einzig mag hier die Art, wie (schnell, häufig) Verbindungen aufgebaut werden variieren.

Selbstverständlich habe ich die Speedmessungen nicht auf dem PC gemacht, der auch die Torrents laufen hatte.

Den guten Anschluss den du vorraussetzt habe ich eben gerade nicht, deshalb meine Beschwerde

Auf dein Fritzboxtuning bin ich gespannt, werde ich mir sehr gerne durchlesen.

Wie dem auch sei, ich habe gerade eben nocheinmal ein paar einfache Speedtests gemacht; Nach diesen Erkenntnissen würde ich übrigens fast das oben von mir beschriebene Messverfahren als DAS Verfahren zum Feststellen der Uploadbandbreite festlegen, da es alles vereint, was man braucht:
a) Upload möglichst gut auslasten, dabei mit wenig Verbindungen, um den Router aus der Schuld zu nehmen: FTP Upload auf eigenen Space anschmeissen, wo man weiß, das theoretisch gut Daten durchgehen.
b) Ping auf bekannten Server (NICHT den gleichen wie auf den der FTP Upload geht) starten
c) Sicherstellen, dass ICMP im QoS bevorzugt behandelt wird (FritzBoxen tun das); Upstreambandbreite auf gebuchte Kapazität einstellen (z.B. 2 Mbit/s)
d) max. Uploadbandbreite in der Fritzbox schrittweise herunterstellen, bis man sieht, dass der Ping aus den unnormalen Bereichen >> 100 ms langsam normal wird
e) abwarten, bis der Ping normal ist
f) Uploadbandbreite langsam wieder hochstellen; Dabei sollte der Durchschnittsping normal sein und einzelne Ausreißer sollten immer noch unter 200 ms bleiben.

Dies ist nun die Uploadgeschwindigkeit, welche zusätzlich noch normales Surfen ermöglicht.
ein 2. zu ermittelnder Wert:
QoS Upstreambandbreite so weit runterregeln, dass der Durchschnittsping nahezu dem ohne Upload entspricht (~ 30-40 ms), einzelne Ausreißer sollten dabei unter 100 ms bleiben. Die Differenz zwischen dem hier emittelten und in f) ermittelten Wert ist ein Anzeichen für die Spike-Auslastung eures Upstreamchannels. Ich komme hier gerade jetzt auf ein Verhältnis von 820 kBit/s (f) zu 600 kBit/s (spikes), was ich nicht nur als traurig sondern gar als erbärmlich (auch in Betracht auf die Gesamtwerte) einstufen würde.

Der Downstream ist übrigens in gerade noch akzeptablen Bereichen von 12-20 Mbit/s (jenachdem obs auf KD Server geht oder ins reale Internet). Mir würde jedoch auch ein 10 Mbit/s Downstream reichen, solange ich wenigstens einen stabilen Upload von nahezu 2 Mbit/s dazu hätte. Würde es bei DSL 2 Mbit/s Upstream geben, wäre meine fristlose Kündigung an KDG schon längst raus. So wie es jetzt gerade ist, habe ich bei DSL allerdings nur Vorteile: Der Upstream ist da zwar (minimal) geringer, dafür aber KONSTANT. Dies ermöglicht dann auch vernünftiges Bandbreitenmanagent. Zur Zeit bin ich eigentlich jede Stunde das QoS in der Fritte nachregeln, wenn der Upstream mal wieder unter 500 kbit/s einsackt.

[Thyrael]

Matze, wenn die Ursache für dein Problem wirklich in einem Puffer des Modems liegt wird man daran nichts ändern können, da man das Modem nicht "mal eben" durch leistungsfähigere Hardware ersetzen kann. Kabel D wird das Modem auch nicht tauschen oder eine Störung aufnehmen da die Leitung ja funktioniert. Wenn du jetzt außerordentlich kündigen willst solltest du sofort zum Anwalt gehen und ihn das machen lassen. Ich gehe davon aus das Kabel D die Kündigung zwar akzeptieren, dir aber auch die gesamten Grundgebühren bis zum Ende der Laufzeit auf ein mal in Rechnung stellen wird.

[Matze88]

Naja, man kann wohl mit einer gegen 1 strebenden Wahrscheinlichkeit die Puffergrößen einstellen Mehr Puffer = mehr Datenrate (da "Löcher", in denen gerade keine Daten anfallen so auch genutzt werden können), aber ebenfalls größere Latenzen. Das ist genau das Prinzip, an dem normalerweise QoS greift: Datenrate konstant unter dem Limit halten, damit man selbst bestimmen kann, wann welches Paket gesendet wird und eben kein FIFO Prinzip sondern eine Policy bzw. spezifische Reihenfolge angeben kann. Jegliche Puffer hinter dem QoS hebeln dies komplett aus.

Die außerordentliche Kündigung werde ich mir nach einem (vorhin geführten) klärenden Gespräch mit dem Technischen Support sparen - sofern die Datenraten weiter in dem jetzigen Bereich bleiben, den man gerade noch so mit DSL gleichsetzen kann. Im Mai ist meine MVLZ um, ob ich verlängere wird sich bis dahin entscheiden. Zur Zeit ist erstmal "Frequency Hopping" angesagt, so kam ich heute Mittag wenigstens wieder auf 1300 kBit/s Upstream.

Matthias

[serg_ja]

QoS ist übrigens so eingestlelt, dass ICMP bevorzugt behandelt wird.

Hast Du es eingestellt? Weil by default FB hat folgende Reihenfolge in Upload QoS:
"Die Original-AVM Konfiguration teilt den Upload in 4 Klassen:
3 (100%) - VoIP
2 ( 95%) - TCP ACK
1 ( 95%) - DNS, ICMP, HTTP/PROXY Requests
0 (100%) - Rest...
VoIP wird priorisiert, nicht nach TOS sondern nach Port / Packets."

Würde vorsichtig Dir empfehlen den gleichen Versuch _OHNE_ FB dazwischen zu wiederholen. Also PC direkt am Modem anschließen und testen. Das Problem könnte auch in FB config liegen.