Zitat:
Zitat von QWERTZ3
Was könnte denn die Ursache dafür sein?
[...]
|
Das ist leider nicht so leicht heraus zu finden. Aber wenn es die Uebergaben des eigenen ISPs sein sollten, dann kann man das mit etwas Glueck in bi-direktionalen Traceroute/MTR Ergebnissen sehen.
Wenn deren Uebergaben die Ursache sind, dann sollten in MTRs unter Last (d.h. Du musst waehrend der MTR Messung versuchen Deinen Link zu saettigen) in jeder Richtung die RTTs deutlich an den Uebergaben zwischen Hekinet und em Rest ansteigen.
Also
Richtung ins Internet
DeineIP -> HeliNet -> ... -> HeliNet Uebergabe
-> Transit/Peering Partner Uebergabe -> Transit/Peering Partner -> ... -> Endhost
Aus dem Internet (sollte am besten ein Lookingglas im selben Netz wie der Endhost sein, wenn Du nicht vom Endhost selber auf DeineIP tracen kannst)
Endhost -> ... -> Transit/Peering Partner Uebergabe
-> Helinet Uebergabe -> HekiNet -> ... -> DeineIP
Wenn in beiden Faellen der fett-formatierte Bereich unter Last massiv hoehere RTTs zeigt als ohne Last, dann spraeche das gegen die Uebergaben Deines ISPs.
Aber selbst wenn, viel nutzen wird Dir das nicht, zum Ausbsau kannst Du die nicht zwingen, und das einzige was die BNetzA vorsieht, ist ein ausserordentliches Kuendigungsrecht wenn die Downloadraten von breitbandmessung.de nicht mit den versprochenen Raten im Produktinformationsblatt uebereinstimmen...
ABER es besteht durchaus die Chance, dass HeliNet nicht gegen Dich arbeitet sondern dass ein technisches Problem vor liegt, dass sich loesen laesst (dann allerdings besser mit als gegen den ISP).
Z.B. kann ein zu kleiner Puffer in einem Uebergabe Port in einem IX Probleme bekommen, mit TCP Verbindungen mit groesserem BDP (Switchports sind i.d.R. fuer Verbindungen mit kurzen RTTs vorgesehen und gepuffert). Ich habe keine Ahnung ob dieser Fall hier zutrifft und exakt Null Indizien dafuer, aber das ist ein realistischer Fall mit aehnlichem Fehlerbild wie bei Dir (gerade single Stream TCP Verbindungen "leiden")...
Gruss
P.