Tele2 zu hoher Downlink Puffer

[painty]

Hallo,

ich habe seit ein paar Tagen Probleme mit SSH und RDP Sitzungen wenn nur ein HTTP Download läuft.
Es hakt alles extrem die Eingaben nimmt er teilweise erst 5 Sekunden später entgegen.

Wie sieht das bei euch so aus? Wie hoch ist bei euch der Downlink Puffer?
Gemessen habe ich ihn über den Netalyzr Debug Test von
http://netalyzr.icsi.berkeley.edu/index.html

Die Warnung: Network packet buffering may be excessive!
http://n3.netalyzr.icsi.berkeley.edu/summary/id=36ea240d-27411-dde5b5e0-89fb-42e4-b978#BufferResult

Wie siehts bei den anderen Anbietern so aus? A1, Inode etc?

Lg
painty

[painty]

Könntet ihr mal den Test ausführen und eventuell die Ergebnisse hier online stellen?

lg
painty

[Aluminchen]

Könntet ihr mal den Test ausführen und eventuell die Ergebnisse hier online stellen?

Damit wieder wen auf die Nerven gehen kannst mit diesen komischen Test?
Dir ist schon klar, das der Server in Californien steht? Wozu willst dahin eine schnelle Verbindung -
Suche nach extraterrestrialen Signalen

[painty]

Hallo Aluminchen,

nein ganz im Gegenteil, ich wollte einfach nur wissen welche Internetanbieter was konfigurieren.
Und der Downlink Puffer wird bei meinem Anschluss auch bei einem Server in Wien nicht anders aussehen.

Es geht mir bei diesen Test nicht um die Pingzeiten sondern über die Puffergrößen der verschiedenen Internetprovider in Österreich.

Für das Internet ist ein Puffer von ca. 100ms vorgesehen. Der Downlinkpuffer zb. wird nur gefüllt wenn man zb etwas downloaded. Umso kleiner der Puffer umso besser reagieren andere interaktive Anwendungen wie SSH, TELNET, RDP oder zb. ICA.

Wie gesagt mir geht es nicht nur um die Downloadgeschwindigkeiten sondern auch um die Qualität des Internetanschlusses desshalb auch dieser Thread.

Es wäre also nett wenn andere User über Ihren DSL Anschluss berichten könnten. Insbesonders DSL User sind für mich interessant.

edit: Dieser komische Test ist von der Universität Berkeley zur Verfügung gestellt worden.

Lg
luky

[lordpeng]

downlink puffer gschichten kenn ich von kabelmodems/cmts'sen aber DSL? ...
sicher, dass das programm keinen mist erzählt? (ich zweifle ja nedamal das messergebnis an, aber vielleicht ist die ursache doch was anderes ...)

[wicked_one]

Zwischen hier und berkeley kann ja so viel passieren....

[lordpeng]

>Zwischen hier und berkeley kann ja so viel passieren....
genau so isses, früher als ich noch kabelmodems und cmts'sen zu tun hatte gabs den grundsatz 'das modem und das cmts misst immer richtig' alles andere war eher uninteressant

[lordpeng]

>Die Warnung: Network packet buffering may be excessive!
>http://n3.netalyzr.icsi.berkeley.edu/summary/id=36ea240d-27411-dde5b5e0-89fb-42e4-b978#BufferResult
da steht auch, dass während des tests eine zeitabweichung von 17 sekunden stattgefunden hat ... wenn das stimmt wage ich zu bezweifeln, dass das an der leitung oder irgendwelchen providerspezifischen einstellungen liegt

btw. warum setzt man google dns server ein?

[painty]

Hallo lordpeng,

das mit dem Netzwerkbuffer kann ich auch bei anderen Österreichischen Servern nachvollziehen wenn 1 HTTP Download läuft. Die Latenz steigt während des Downloads auf 570ms an und bei einem Upload um 10ms konstant.

Somit kann ich davon ausgehen, dass der Test relativ genau ist. Außerdem habe ich den Test mehrmals an verschiedenen Tagen wiederholt.

lg
luky

[wicked_one]

Wie sagte mein Lehrherr immer "Wer misst, misst Mist"...

Messen ist das eine, Verstehen das andere...

Das bei nem Stau auf der Autobahn alles etwas langsamer geht, ist nichts neues, und weil dir jetzt ein lustiger Test irgend ein neues Zauberwort zum Support seggieren zugespielt hat, heisst das noch lange ned, das irgendwas ned in Ordnung ist...

Speedtests werden nur im eigenen Netz anerkannt, weil darüber hinaus das 10-fache an Devices das Ergebnis verfälschen, ... warum sollte nun ein Java-Applet in Übersee auf nem Uni-server, zuverlässig sein...

[martin]

ich versteh das problem auch nicht...

Die Latenz steigt während des Downloads auf 570ms an und bei einem Upload um 10ms konstant.

dass bei höherer leitungsauslastung die RTT steigt ist doch absolut normal? was soll das mit irgendwelchen puffern zu tun haben?

wie auch wicked_one schon geschrieben hat, zur rush hour gehts halt langsamer...

[jutta]

Für das Internet ist ein Puffer von ca. 100ms vorgesehen. Der Downlinkpuffer zb. wird nur gefüllt wenn man zb etwas downloaded. Umso kleiner der Puffer umso besser reagieren andere interaktive Anwendungen wie SSH, TELNET, RDP oder zb. ICA.

erklaer bitte einmal, was du in dem satz oben mit "Internet" meinst.

//edit, ps: traceroute von meinem desktop zu dem berkeley-server (der in einer amazon-cloud "wohnt") zeigt 21 hops. jedes einzelne dieser geraete kann dazu beitragen, dass ein "buffer", wie immer der genau definiert wird, "zu gross" ist. plus eine menge geraete, die nicht im traceroute aufscheinen, aber den transport dennoch beeinflussen (switches usw.). daher wirst du ueber die konfigurationen der einzelnen provider mit der methode recht wenig herausfinden. ausserdem kann es sich bei jedem provider stuendlich aendern, wenn dort ein geraet durch ein anderes ausgetauscht wird oder ein software-update durchgefuehrt wird.

[Aluminchen]

das mit dem Netzwerkbuffer kann ich auch bei anderen Österreichischen Servern nachvollziehen wenn 1 HTTP Download läuft. Die Latenz steigt während des Downloads auf 570ms an und bei einem Upload um 10ms konstant.

Womit wir wieder beim alten Thema sind - jeder Provider der ein Hirn sein Eigen nennt, stellt die ICMP-Packerl
hinten an - und was passiert dann, jep, die Latenz steigt....
Das Gleiche passiert wenn einen Download startest der in der Regel eine höhere Priorität hat als ICMP.
Und daher sind Speedtest und Ping einfach nur Richtwerte - wenn man sie richtig verwendet und weiss was man tut
auch wirklich eine Hilfe - aber hier........ *ohne Worte*

Wie sagte mein Lehrherr immer "Wer misst, misst Mist"...

Nicht haun - nur eine kleine Korrektur - "Wer viel misst, misst Mist!"

Speedtests werden nur im eigenen Netz anerkannt, weil darüber hinaus das 10-fache an Devices das Ergebnis verfälschen

Nicht mal da funktionierts korrekt, wenn wo was gepuffert wird am PC
Dann bekommst auf einmal auf einer 2 Mbit DSL Leitung 49 Mbit

[painty]

Hallo martin,

das Problem mit den Puffern lässt sich ziemlich einfach reproduzieren.

Wenn ich zb. auf dem Cisco 888e Telekom Router den Tx-Ring und die Tx-Queuelen gegen 1 tune, dann wird während eines Uploads die Latenzzeit nur um 100ms ansteigen.
Setze ich auf dem Cisco aber den default Wert von 64 bei beiden Optionen so steigt die Latenzzeit um ca. 250ms an.
Setze ich auf dem Cisco beide Werte auf 1 und aktiviere zusätzlich noch fair-queue, so steigt die Latenzzeit bei einem Upload maximal um 10ms an.

Die genannten Einstellungen haben alle mit Pufferung zu tun.

edit: Aluminchen, ja bei mir sinds aber nicht nur die "ICMP Packerl" bei mir wird der ganzeTraffic nachm FIFO Prinzip geregelt. Und generell das Wort Latenz für ICMP zu benutzen ist auch nicht richtig. Man kann den Verkehr auch so priorisieren dass die Pingzeit 600ms beträgt aber die Latenzzeit für rdp zb. nur zusätzliche 20ms beträgt.

lg
luky

[martin]

ja, eine kleinere queue lenght reduziert die latenz, aber die interfaces droppen dann auch früher.

bei cisco gibt's eh eine sehr schöne beschreibung zu der thematik:

In other words, the size of the transmit ring needs to be small enough to avoid introducing latency due to queuing, and it needs to be large enough to avoid drops and a resulting effect on TCP-based flows.

wenn bei jedem etwas größeren burst das interface sofort pakete verwirft weil die queue voll ist hilft die niedrige latenz auch keinem was...

IMO haben die provider hier wohl einfach einen für sie vernünftigen mittelwert gewählt. auch ich verwende ICA und SSH, wenn ich die leitung daneben nicht vollkommen zumache hatte ich eigentlich noch nie wirklich ein problem.