FritzBox oder KD Problem? -> Zu große DS-Queue, hohe Pings

[Matze88]

Hallo zusammen!

Ich habe ein Problem: Bei Up&Downloads ist surfen sehr langsam. Das findet ihr normal? Ich eigentlich auch, aber das hier ist was anderes:

Meine Leitungswerte bei KD sind normalerweise 30/1.5 Mbps. Auf wieistmeineip erreiche ich abends weniger im Downstream (so 5-15, jenachdem). Auch Downloads (eigene schnelle Server) bestätigen eher das wimip.de Ergebnis, vermutlich ist der Knoten raus ausm KD Netz da der Flaschenhals. (Störungsmeldung dazu habe ich schonmal abgeschickt, vielleicht hilfts ja).

So: Nun lade ich viele kleine Dateien runter (also auch leicht erhöhter Upload) und nutze dabei etwa 15 Mbps/300 kbps. Gleichzeitig steigt die Ping-Zeit auf 200-800 ms auf andere Server. Hat jemand ähnliches zu berichten? Könnte das auch an der Fritzbox liegen? Ich werde dazu bei Gelegenheit nochmal Tests mit richtigen Routern fahren.

Das ganze kann ich übrigens mit QoS einigermaßen regulieren: (Vorweg: Der Download wird von der Fritzbox nie begrenzt, keine Ahnung wofür die die Downstreamkapazität braucht). Stelle ich den Upstream in der FB auf 200 kbps (dann wird der Download automatisch langsamer, da nicht so viele Pakete angefordert werden können), so ist der Ping wieder super ~30 ms (Die Traffickategorie des Upstreams vom Download habe ich in der FB als Bulk eingestuft - lässt also meinen Ping schnell passieren).

Außerdem habe ich den Fritzbox Paketmitschnitt genutzt:
Dort sehe ich eindeutig, dass die Pingrequestpakete rausgehen und die Responsepakete wirklich erst die schlechte Pingzeit später reinkommen, auf dem "DSL Interface" (heißt so, er meint aber das Wan Interface, d.h. Absender ist schon die öffentliche IP der FB).

Bedeutet für mich: KD hat nen zu großen Empfangspuffer, sodass die Responsepakete erst später bei mir eintrudeln. Aber warum ist das bereits bei nicht ausgelasteter Leitung der Fall? Ist das KDs Packet Inspection, die da schlapp macht? Generell merke ich auch, dass meine Leitung parallel zu diesem Down/Upload recht langsam ist. Wenn ich EINE große Datei runterlade erreiche ich locker die fast volle Geschwindigkeit (zu solchen Uhrzeiten wie jetzt), parallel zu diesem Down/Upload allerdings nur einige 100 kbps. Das kanns doch irgendwie nicht sein? QoS hilft mir hier ja auch nicht weiter, denn die FB denkt ja, sie hätte noch genug Platz im Upload (hat sie ja auch theoretisch, also verlangsamt sie da nichts).

Mit diesem Problem werde ich mich auch nicht an Kabel Deutschland wenden können, die verstehen vermutlich nichtmal was ich meine. Habe ich mich hier denn einigermaßen verständlich ausgedrückt? Mich würde interessieren, ob ihr ähnliche Erfahrungen gemacht habt.

Noch was generelles hinterher:

Ich habe dauerhaft nen Upstream <= 1500 kbps (maximal, also mehr geht nicht durch die Leitung), das ist ja auch schon komisch. Jetzt entsteht aber hier auch wieder ein ganz großes QoS Problem: Damit das gut funktioniert, müsste ich der FB meine wirklichen Werte mitteilen und nicht die theoretischen. Gerade im Downstream variiert das ja aber (wenn sie den auch begrenzen würde - also hier nur Theorie). Von daher ist QoS am Kabelanschluss sowieso nahezu unbrauchbar...

Matthias


Edit: Messwerte

Down/Upload: 15.400/300 kbps
Dazu wieistmeineip.de speedtest: Ergebnisse 8MBit/35kBit. Fritzauslastung dabei: 23.000/400. Fritz QoS steht auf 32M/2M. Hat den Down/Upload (bulk klasse) dazu nicht gedämpft. (wieistmeineip.de Traffic normale Klasse).

Ping nebenbei:
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=858 ttl=55 time=39.9 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=859 ttl=55 time=131 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=860 ttl=55 time=1004 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=861 ttl=55 time=46.6 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=862 ttl=55 time=143 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=863 ttl=55 time=983 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=864 ttl=55 time=26.0 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=865 ttl=55 time=39.4 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=866 ttl=55 time=29.4 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=867 ttl=55 time=124 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=868 ttl=55 time=158 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=869 ttl=55 time=905 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=870 ttl=55 time=26.0 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=871 ttl=55 time=54.3 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=872 ttl=55 time=29.8 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=873 ttl=55 time=69.0 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=874 ttl=55 time=401 ms
64 bytes from eow.ath.cx (85.10.196.187): icmp_seq=875 ttl=55 time=1205 ms


Wenn ich den Down/Upload stoppe, kriege ich auf wieistmeineip.de in etwa 25-30/1500. Dabei bleiben die Pings niedrig.

[RcRaCk2k]

Vorweg: Der Download wird von der Fritzbox nie begrenzt, keine Ahnung wofür die die Downstreamkapazität braucht

Das fragt auch mich heute noch, warum AVM die Angabe der Download-Kapazität wünscht... unverständlich.

Außerdem habe ich den Fritzbox Paketmitschnitt genutzt:
Dort sehe ich eindeutig, dass die Pingrequestpakete rausgehen und die Responsepakete wirklich erst die schlechte Pingzeit später reinkommen...

Das ist interessant. Da du aber einen guten Download erhältst, denke ich eher dass der Buffer im Modem zum Senden der Daten hinterherhinkt.

Eventuell ist der US dicht und du bekommst vom CMTS nur wenige Timeslots zur Übertragung der Upstream-Daten zugewiesen.

Aber warum ist das bereits bei nicht ausgelasteter Leitung der Fall? Ist das KDs Packet Inspection, die da schlapp macht?

Die Frage ist ja, auf welcher Seite kommt es zu der extremen Verzögerung?

• Modem -> CMTS
• CMTS -> Backbone
• Backbone -> Austauschknoten .... usw.

Ich habe dauerhaft nen Upstream <= 1500 kbps (maximal, also mehr geht nicht durch die Leitung), das ist ja auch schon komisch. Jetzt entsteht aber hier auch wieder ein ganz großes QoS Problem: Damit das gut funktioniert, müsste ich der FB meine wirklichen Werte mitteilen und nicht die theoretischen.

Das ist korrekt. Ohne genaue Werte kann die FritzBox den Traffic nicht korrekt shapen. Jedoch ist in der FritzBox eine Priority eingebaut, die besagt, dass VoIP-Traffic z.B. immer mit Priority 1 und alle anderen Daten grundsätzlich mit Priority 2 versendet werden. Von daher ist restliche QoS nurnoch für das Surfen interessant, um z.B. ACKs und SYNs priorisierter versenden zu können.

Gerade im Downstream variiert das ja aber (wenn sie den auch begrenzen würde - also hier nur Theorie). Von daher ist QoS am Kabelanschluss sowieso nahezu unbrauchbar...

Naja, wie du schon selber gesagt hast.... der FritzBox ist der Downstream total egal. Von daher muss man dort nichts einstellen.

Deinem Problem nach zu urteilen, würde ich das Problem im Upstream von deinem Modem zum CMTS suchen. Ich denke dass die US-Queue dort ein Problem mit dem Timing hat.

Grüße,
Michael.

[Matze88]

Vielen Dank für deine Antwort, scheinbar habe ich ja trotz des langen Posts alles verständlich ausgedrückt

Ich hab grad die Linuxinstallation auf meinem MedienPC vorgezogen und werde in etwa ner Stunde somit mal testweise nen "echten" Router mit 2x 100 MBit Interfaces haben, den ich statt der FritzBox anschließe, um diese als Fehlerquelle auszuschließen (Die DD-WRTs die hier noch rumstehen packen alle nur ~20 MBit WAN-Durchsatz, das ist etwas murks fürn Test).

Leider ist mein HTTP Traffic gerade extrem lahm (Alles andere noch viel mehr - Danke für die Drosselung, KD!), also hier muss absolut alles überlastet sein. Ein KD Speedtest erreicht rund 8 MBit, von meinem Server (Hetzner, Nürnberg) Zieh ich mit 160 kByte/s und auf nem Traceroute antworten die ersten 3 Hops garnicht/Kaum. Wie ist meine ip.de bringt 1,8/0,7 Mbit; Mein Mitbewohner zieht grad noch ne Linux Distri per Torrent und hat etwa 400 kbit/s down und 50 kbit/s up... (parallel zu meinen seriellen Speedtests).

Wenn das so bleibt, kriegt KD sowieso eine Kündigung wegen Nichterfüllung der Leistungen, ne Störungsmeldung ist bereits raus und ab dem 1.9. werde ich das wohl auch mal telefonisch mit denen bereden können (0800 Hotline).

Matthias

[RcRaCk2k]

Ich hab grad die Linuxinstallation auf meinem MedienPC vorgezogen und werde in etwa ner Stunde somit mal testweise nen "echten" Router mit 2x 100 MBit Interfaces haben...

Vergiss nicht, dass du beim Pingen dennoch erhöhte Paketlaufzeiten haben wirst, solltest du kein QoS wie HFC oder SFQ verwenden. Ich habe bei meinem Linuxrouter so ein Script verwendet, was man im Internet findet, wenn man nach "QoS" und "Traffic Shaping Linux" sucht.

Leider ist mein HTTP Traffic gerade extrem lahm (Alles andere noch viel mehr - Danke für die Drosselung, KD!), also hier muss absolut alles überlastet sein. Ein KD Speedtest erreicht rund 8 MBit...

Na dann ist doch alles klar... Totale Überlastung deines Segments.

...von meinem Server (Hetzner, Nürnberg) Zieh ich mit 160 kByte/s und auf nem Traceroute antworten die ersten 3 Hops garnicht/Kaum.

Habe hauch einen Server bei Hetzner und einen bei Core-Backbone (Gleicher Gebäudekomplex / Deutschherrenallee in Nürnberg). Ich habe immer um die 1,6 MB also 12,8 MBit. Scheint bei dir wohl auch eine Überlastung in den Zuführungsstrecken zu geben. KD peert sicherlich auch bei deiner Anbindung direkt mit DECIX.

Wenn das so bleibt, kriegt KD sowieso eine Kündigung wegen Nichterfüllung der Leistungen...

Da hast du aber ein Problem, denn mit der "bis zu" Klausel sichern sie sich gegen solche fristlosen Kündigungen ab. Du könntest nur auf Schlechtleistung klagen. Bzw. wenn du komplette Ausfälle hast, auf die 95% Verfügbarkeit. In jedem Fall musst du K.D. aber 14 Tage Frist zur Besserung einräumen.

Grüße,
Michael.

[Matze88]

Ich habe den heutigen Tag mit umfangreichen Messungen verbracht.

Zuersteinmal:

Jap, nach Hetzner gehts auch direkt über DECIX. Ist eigentlich nicht schlecht, aber scheint häufig recht voll zu sein (Auch vormittags keine 4 MB/sec gekriegt).

Und zum Thema voller Leitung: Es ist egal, zu welcher Uhrzeit ich teste. Auch morgens um 7 steigt mein Ping, wenn ich parallel dazu Up & Download belaste. Natürlich verschärft sich das Problem in den Abendstunden.

Eigentlich habe ich dazu noch Grafiken von den tcpdumps erstellt, die sind aber grad noch nicht fertig. Es sieht in etwa so aus: Der Upload liegt bei ~400-600 kBit/s. Der Download macht dabei etwa 10-15 MBit/s. Ein Ping parallel dazu ist deutlich erkennbar stark beeinflusst (Egal ob mit QoS oder ohne - sogar HFSC mit icmp auf 200 ms Full speed realtime und den Rest auf ls m1 0 kbit/s 1s m2 500 kbit bringt absolut garkeine Änderung).

Dabei habe ich etwa 1500 Pakete / Sekunde im Downstream und ~500 Pakete pro Sekunde im Upstream. Ist die Paketrate vielleicht zu hoch? Es wird jedes zweite eintreffende Paket bestätigt, die eintreffenden Pakete sind mit Layer 2 Header 1516 Bytes groß. Bedeutet etwa alle 3032 Bytes wird ein 64 Byte Ack gesendet.

Dabei habe ich daran gedacht, dass eventuell das Kabelmodem Probleme macht? Das hat ja nur 250 Docsis Pakete pro Sekunde zur Verfügung soweit ich weiß und fasst automatisch mehrere zu übertragende Pakete zusammen. Dort könnte natürlich ein Fehler passieren; Entweder in der Zuteilung der Upstream Slots, dass da eventuell völlig hirnrissige Verteilungen eingestellt sind (z.B. sinngemäß alle 30 Modems am CMTS bekommen nacheinander viele kleine Timeslots, jeder immer 10 ms am Stück -> alle 300ms kann man nur senden) oder aber irgendwelche falschen Buffereinstellungen im Modem. Zuguterletzt kann man auch nen Defekt nicht ausschließen.

Was in dem Fall herausgefunden werden müsste: Ist der Downstream oder der Upstream das Problem?
-> Gibt es dazu ne Testsuite, die ich auf meinem Server ausführe und hier auf meinem Rechner, der zuerst die Zeit exakt synchronisiert und dann die Latency für beide Richtungen EINZELN messen kann? Ich hab leider im Moment keine Zeit, soetwas zu programmieren.

Was ich morgen noch unbedingt testen muss ist ob das hier nur dieser eine spezielle Fall ist, der die Probleme macht (massiv aufgefallen ist mir das bei nem nntps Transfer); dazu werd ich mal nen Paketgenerator benutzen und den Upstream divers zumüllen und dazu pingen.

Selbstverständlich ist QoS für alle Tests verpflichtend, nicht dass ich mir den Ping bereits auf meinem System zerschieße. Es kann nur halt meiner Meinung nach nicht angehen, dass ich nen Datenstrom von meinetwegen auch 500 kbit/s ans Modem schicke und dort dann 30-50 % der Pings zwischen 300 und 800 ms liegen.

-> Morgen gibts wieder nen Update von mir


Edit:
Grade nochmal den Upload "voll" ausgelastet (FTP Upload mit 140 Kbyte/s obendrauf); Die Pings liegen zwischen 1500 und 2000 ms, obwohl sie nachwievor absolut prioritisiert werden. QoS HFSC begrenzt bei mir auf 1400 KBit/s (etwa 1550-1650 kBit/s kriege ich tagsüber; was jetzt grade geht weiß ich nicht)

[RcRaCk2k]

Gibt es dazu ne Testsuite, die ich auf meinem Server ausführe und hier auf meinem Rechner, der zuerst die Zeit exakt synchronisiert und dann die Latency für beide Richtungen EINZELN messen kann?

Soetwas hab ich auch schon mal gesucht, aber leider nichts gefunden.

Programmieren wollt ich so ein Testprogramm auch einmal, aber das Hauptproblem, woran ich scheiterte, war die Zeitsynchronisation. Dafür hab ich bis heute keine Lösung gefunden.

Es kann nur halt meiner Meinung nach nicht angehen, dass ich nen Datenstrom von meinetwegen auch 500 kbit/s ans Modem schicke und dort dann 30-50 % der Pings zwischen 300 und 800 ms liegen.

Das ist wirklich unter aller Sau, dass sowas passiert. Bisher sind mir solche Probleme nur bekannt gewesen, wenn der eigene Anschluss im Upload überlastet war. Mit QoS hatte sich das Problem aber behoben.

So sieht meine QoS Einstellung aus:

Code: Alles auswählen

#
# MARKIERUNGEN
#  0x1   REAL TIME TRAFFIC
#  0x2   HIGH PRIORITY TRAFFIC
#  0x3   NORMAL TRAFFIC
#  0x4   BULK TRAFFIC
#

######### PRIORITÄT 1 ######
# SYN- und ACK-Pakete
iptables -t mangle -A ${target} -m tcp -p tcp --syn -m mark --mark 0 -j MARK --set-mark 0x1
iptables -t mangle -A ${target} -m tcp -p tcp --tcp-flags ACK ACK -m length --length 0:100 -m mark --mark 0 -j MARK --set-mark 0x1

######### PRIORITÄT 2 ##########
# DHCP, DNS uns SSH
iptables -t mangle -A ${target} -m udp -p udp --dport 698 -m mark --mark 0 -j MARK --set-mark 0x2
iptables -t mangle -A ${target} -m tcp -p tcp --dport 22 -m mark --mark 0 -j MARK --set-mark 0x2
iptables -t mangle -A ${target} -m tcp -p tcp --sport 22 -m mark --mark 0 -j MARK --set-mark 0x2
iptables -t mangle -A ${target} -m udp -p udp --dport 53 -m mark --mark 0 -j MARK --set-mark 0x2
iptables -t mangle -A ${target} -p icmp -m mark --mark 0 -j MARK --set-mark 0x2

######### PRIORITÄT 3 ##########
# Normaler Traffic
iptables -t mangle -A ${target} -m tcp -p tcp --dport 21 -m mark --mark 0 -j MARK --set-mark 0x3
iptables -t mangle -A ${target} -m tcp -p tcp --dport 25 -m mark --mark 0 -j MARK --set-mark 0x3
iptables -t mangle -A ${target} -m tcp -p tcp --dport 80 -m mark --mark 0 -j MARK --set-mark 0x3
iptables -t mangle -A ${target} -m tcp -p tcp --dport 110 -m mark --mark 0 -j MARK --set-mark 0x3
iptables -t mangle -A ${target} -m tcp -p tcp --dport 443 -m mark --mark 0 -j MARK --set-mark 0x3

######### PRIORITÄT 4 ##########
# Hier wandert der komplette BULK Traffig rein
# Definiert als Default

#
# AKTIVIERUNG DER SHEDULING-KLASSEN
#
tc qdisc add dev ${device} root handle 1: htb default 104

# Geschwindigkeit des Interfaces festlegen
tc class add dev ${device} parent 1: classid 1:1 htb rate 1980kbit ceil 1980kbit burst 6k cburst 6k

# Geschwindigkeitsklassen definieren
tc class add dev ${device} parent 1:1 classid 1:101 htb rate 36kbit ceil 1980kbit prio 1 burst 6k cburst 6k
tc class add dev ${device} parent 1:1 classid 1:102 htb rate 180kbit ceil 1980kbit prio 2 burst 4k cburst 4k
tc class add dev ${device} parent 1:1 classid 1:103 htb rate 800kbit ceil 1980kbit prio 4 burst 2k cburst 2k
tc class add dev ${device} parent 1:1 classid 1:104 htb rate 964kbit ceil 1600kbit prio 8 burst 1k cburst 1k

# Bandbreite von TCP/UDP Verbindungen fair aufteilen
tc qdisc add dev ${device} parent 1:101 sfq perturb 10 quantum 1460
tc qdisc add dev ${device} parent 1:102 sfq perturb 10 quantum 1460
tc qdisc add dev ${device} parent 1:103 sfq perturb 10 quantum 1460
tc qdisc add dev ${device} parent 1:104 sfq perturb 10 quantum 1460

# IP-Tables Markierungen aussortieren
tc filter add dev ${device} parent 1: protocol ip handle 1 fw classid 1:101
tc filter add dev ${device} parent 1: protocol ip handle 2 fw classid 1:102
tc filter add dev ${device} parent 1: protocol ip handle 3 fw classid 1:103
tc filter add dev ${device} parent 1: protocol ip handle 4 fw classid 1:104

Ich habe meine Leitung auf 1980kBit eingemessen. Was natürlich nicht immer richtig ist, wenn der Upstream in unserer Region nurnoch weniger hergibt. Aber durch die Priorisierung der einzelnen Klassen 1,2,3 und 4 ist mir relativ egal, ob für den BULK-Traffic genügend übrig bleibt, oder nicht. Wichtig ist mir ACK und SYN, damit die Leute hinter dem Router auch bei hohen Upstream gut surfen können.

Ich setze dabei auf HTB, weil ich dort angegeben kann, wieviel BURST-Traffic (Einmaliger Ausrutscher) ich pro Klasse zulasse. So kann man kleinere Files deutlich schneller herunterladen. Sobald mehr Traffic übertragen wird, wird die Uploadgeschwindigkeit eingegrenzt.

Deine Syntome mit den ansteigenen Pings kenne ich also von meinem Linux-Router nur insoweit kein QoS aktiviert war. Nach der Aktivierung des QoS waren die Pings geschmeidig. Sind vielleicht im 1ms angestiegen.

Die Frage bei dir ist nun, wie findet man heraus, ob der Upstream, oder der Downstream das Problem veruracht? Muss mich mal umhören, ob meine Kollegen ein Programm kennen, das ein Ping zu einem Endgerät absetzten kann und nur den Hinweg analysieren kann.

Grüße,
Michael.

[Matze88]

Sooo... Die frühe Morgenstunde ausgenutzt. Vorweg erstmal wieistmeineip.de Speedtest von jetzt und von vor meinen Tests (30 MInuten):
30.955 kBit/s down, 1.750 kbit/s up (waren beide so in dem Rahmen, der erste hatte etwas weniger Up). Dieser Test wurde komplett OHNE QoS bei freier Leitung gemacht -> Leitungskapazität.

Nun stelle ich QoS auf ne Upstreambegrenzung von 800 kbit/s und erstelle mir folgende Klassen:
Klasse 1:2 für HTTP, DNS, TCP ACK <=64 Byte : hfsc sc m1 800kbit d 50 ms m2 500 kbit ul rate 800kbit
Klasse 1:3 als standardklasse: hfsc rt m1 800 kbit d 100ms m2 100 kbit ls m1 800kbit d 100ms m2 500 kbit ul rate 800kbit
Klasse 1:5 für Destination port FTP Data sowie NNTPS: hfsc sc m1 0 d 500ms m2 100kbit ul rate 800kbit

Die Standardklasse ist deswegen so stark prioritisiert, damit der OneWayPing da rein fällt (den krieg ich sonst nicht so leicht) - da die Leitung aber ansonsten nahezu leer ist, fällt fast garnichts weiter mit in die Klasse (nur sehr wenige kByte, also vernachlässigbar). owamp benutze ich als OneWayPing.

Nun sieht das so aus: Ich starte einen schnellen NNTPS Download und mein Ping sagt folgendes: (100 Pings in 13 Sekunden)
ich -> hetzner min/med/max 0,275 592 1680 ms
hetzner -> ich min/med/max 19,1 20,1 26 ms
(dabei lade ich mit etwa 2,5 MByte/s runter und mit 300 kBit/s hoch durch die ACKs)

Ohne Last der Leitung: 8.9 12.7 27 ms bzw. 10.3 10.6 12.5 ms

Beim FTP treten diese Probleme allerdings nicht bzw. sehr viel schwächer auf -> Ergebnisse folgen muss erstmal was anderes machen

Edit:

Nun auch die letzten Ergebnisse. Da ich total verwirrt von den Messungen bin und hier ziemlich viel misst rauskommt, habe ich auch mal ne Abwandlung deines HTB QoS probiert - 3 Klassen Std, Ack, Bulk. FTP/NNTPS auf bulk, ping auf std und ack ist selbsterklärend
-> NNTPS Download: schlechte pings (~2,5 Mbyte/s Download) -> Situation eher etwas schlechter als mit HFSC, aber eigentlich kein Unterschied.
-> FTP Upload mit 120 kbyte/s und Download mit 1MB/s (speedtest ist immernoch auf 30 Mbit) führt zu völligem Versagen von owamp (-> udp... obwohl ichs extra mit aufgenommen hab ins script), normale pings (ebenfalls in der std klasse) steigen in der Latenz auf 300-800...

Stoppe ich entweder den Upload ODER den Download ist alles normal.

Mit HFSC hab ich beim FTP Up/Download total verrückte Werte gehabt bzw. aufgrund meiner "schlechten" Bulkklasse wurde der Upload in unregelmäßigen Abständen sogar komplett gestoppt. Trotzdem waren die Pings dabei miserabel. Auch hier habe ich den Upload recht stark (< 1 MBit/s) und den Download stark (1-2 MByte/s, mehreres durchprobiert) gedrosselt.


Ein Fall für den KD Service würde ich sagen... Da werde ich dann mal anrufen, sobald die kostenlose Rufnummer geschaltet ist, denn ich habe keine Lust, denen ne Stunde mein Problem für 14ct/Minute zu erklären. Auf Emails wird ja scheinbar nicht wirklich geantwortet (hab noch ne Anfrage von letzter Woche offen).

Vielen Dank jedenfalls für deine rege Unterstützung hier in dem Thread

[RcRaCk2k]

ich -> hetzner min/med/max 0,275 592 1680 ms
hetzner -> ich min/med/max 19,1 20,1 26 ms
(dabei lade ich mit etwa 2,5 MByte/s runter und mit 300 kBit/s hoch durch die ACKs)

Ohne Last der Leitung: 8.9 12.7 27 ms bzw. 10.3 10.6 12.5 ms

Du bist also 500kBit unterhalb der maximal zur Verfügung gestellten Leistung und hast dennoch Probleme mit dem Ping .... Na dann ist es auf jeden Fall ein Problem von Kabel-Deutschland. Und auf jedem Fall ein Problem im Upstream, wenn der DS bei guten maximalen 26ms bleibt.

Hoffe, dass du was erreichen wirst.

Grüße,
Michael.