iperf3 Retransmissions (Retr) nur in eine Richtung

  • Hier ist ja das Thema Retransmissions und Bandbreitenverlust durch einen Tunnel angesprochen worden:

    https://forum.netcup.de/admini…em-was-ist-hier-passiert/

    Ich will den Thread von mainziman nicht kapern, denn mir geht es nur um die Retransmissions, die iperf3 ausgibt.


    Ich habe das mit drei meiner Server getestet und festgestellt, dass sich das nur in eine Richtung und zu einem Server zeigt (egal ob iperf3 als Server oder Client agiert)

    Nur zum Rootserver hin werden mir sehr viele Retransmissions angezeigt:

    pasted-from-clipboard.png

    Code
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.00   sec   120 MBytes  1.01 Gbits/sec  6087   25.5 KBytes
    [  5]   1.00-2.00   sec   115 MBytes   966 Mbits/sec  5446   15.6 KBytes
    [  5]   2.00-3.00   sec   117 MBytes   981 Mbits/sec  5209   15.6 KBytes
    [  5]   3.00-4.00   sec   117 MBytes   981 Mbits/sec  6838   28.3 KBytes
    ...

    Vom Rootserver weg und zwischen den beiden anderen Servern ist es OK

    Bandbreitenverluste habe ich dabei allerdings keine, wie man sieht. Und die Netzwerkanbindung des RS läuft ansonsten auch völlig problemlos


    Nun stellen sich mir die Fragen:

    • Was könnte die Ursache sein? (Wie könnte man das rausfinden?)
    • Sollte ich mir darüber überhaupt Gedanken machen, oder es komplett ignorieren? (Weil kein Verlust)
    • Wie lautet die Antwort auf die Frage aller Fragen, nach dem Leben, dem Universum und dem ganzen Rest?

    (Verbindung zu Servern anderer Provider habe ich noch nicht getestet)

  • Aha.

    Wenn ich die Bitrate auf knapp unter das Maximum dessen setze, was die VPS können, verschwinden die Retransmissions:


    Ohne Beschränkung:


    Code
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.00   sec   122 MBytes  1.02 Gbits/sec  6353   19.8 KBytes
    [  5]   1.00-2.00   sec   117 MBytes   985 Mbits/sec  5771   19.8 KBytes
    [  5]   2.00-3.00   sec   117 MBytes   984 Mbits/sec  6724   21.2 KBytes
    [  5]   3.00-4.00   sec   116 MBytes   977 Mbits/sec  5305   28.3 KBytes
    ...


    Mit -b 950MB:


    Code
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.00   sec   113 MBytes   950 Mbits/sec    1    130 KBytes
    [  5]   1.00-2.00   sec   113 MBytes   950 Mbits/sec    1    144 KBytes
    [  5]   2.00-3.00   sec   113 MBytes   950 Mbits/sec    0    144 KBytes
    [  5]   3.00-4.00   sec   113 MBytes   950 Mbits/sec    0    144 KBytes
    ...


    Zwischen den beiden VPS gab es keine Probleme, weil beide eh nur maximal 1 Gbit/s schaffen.

    Der RS könnte aber 2,5 Gbit/s.


    Ohne Beschränkung testet iperf3 halt aus, was geht.

    Allerdings hätte ich den Stau eher in die umgekehrte Richtung erwartet. (Vom RS zum VPS) :/

  • Glaube nicht. Nur wenn man noch die Option -u hinzufügt.

    Es nur so, dass iperf3 die Bitrate für UDP schon per Default auf 1 MBit/s beschränkt, für TCP ist sie unbeschränkt


    Code
      ...
      -u, --udp             use UDP rather than TCP
      ...
      -b, --bitrate         target bitrate in bits/sec (0 for unlimited)
                            (default 1 Mbit/sec for UDP, unlimited for TCP)
  • Ich kann das Phänomen in gewissen Grenzen bestätigen.


    Ich hab einen RS 2000 G8 (1 GBit/s) und einen RS 2000 G9 (2.5 GBit/s). Sende ich vom G8 zum G9, gibt es diese Retransmissions. Sende ich vom G9 zum G8, gibt es sie nicht. Erster Verdacht: Es betrifft den Upload des G8 Servers, da der am Limit ist.

  • Erster Verdacht: Es betrifft den Upload des G8 Servers, da der am Limit ist.

    Ja, sowas in der Art vermute ich auch.

    iperf3 läuft ja an beiden Enden und kann somit leicht feststellen, wie schnell der Empfänger die Daten annehmen kann.

    Dann wird halt versucht soviel wie möglich rauszuhauen und das Limit auszureizen.


    ...oder so ähnlich ;)

  • Hab das Ganze jetzt mal ausprobiert zwischen Netcup G9 root zu einem Server, den ich bei einem anderen Provider habe und der mehr als die 2.5 GBit/s kann. (Nennen wir ihn mal "HC" ;))


    Da zeigt sich der gleiche Effekt.

    HC -> RS G9 - Keine Retr.

    RS G9 -> HC - Viele Retr.


    Wenn ich die Transferrate dann aber mit -b runterschraube, sind die Retransmissions bei ca. 2.25 Mbit/s weg :)

  • Ist wie beim Versandhandel, wenn ein Paket wegen Überlastung des Zustellers oder aufgrund Unzustellbarkeit zurück zum Absender geht oder ganz verloren. ^^


    In diesem Fall (Performancetest mit iperf3) ist es aber wohl eher kein Problem, sondern zeigt nur an, dass die Grenze ausgereizt wurde. (So meine Vermutung)

    Erst wenn hier die Retransmissions auch bei geringeren Übertragungsraten auftreten würden, müsste man sich wohl Sorgen machen.


    Mich hatte hier im Wesentlichen interessiert, wie ich diese Ausgaben von iperf3 zu interpretieren habe.

  • HC -> RS G9 - Keine Retr.

    RS G9 -> HC - Viele Retr.

    Interessant. Ich hab von meinem G8 und G9 Server einen Test gegen den iperf3 Server von WilhelmTel gemacht. Der kann beide Server auslasten. Es gibt zwar ein paar Retransmissions, aber die sind locker um Faktor 20 kleiner, als in der direkten Verbindung der beiden RS.


    iperf versucht im TCP Modus natürlich, die Leitung möglichst auszureizen. Das heißt eben, die Leitung wird geflutet, bis es zu Paketverlusten kommt und die TCP Congestion Control Algorithmen zuschlagen. Von daher ist eine gewisse Anzahl Retransmissions normal. Man müsste das mal mit normalen wget Downloads gegentesten.

  • Interessant. Ich hab von meinem G8 und G9 Server einen Test gegen den iperf3 Server von WilhelmTel gemacht. Der kann beide Server auslasten. Der kann beide Server auslasten. Es gibt zwar ein paar Retransmissions, aber die sind locker um Faktor 20 kleiner, als in der direkten Verbindung der beiden RS.

    Muss ich auch mal testen. :)

    EDIT: Ja, kann ich so bestätigen. In beide Richtungen keine nennenswerten Retrs (Hmm. Was ist da anders?)

    iperf versucht im TCP Modus natürlich, die Leitung möglichst auszureizen. Das heißt eben, die Leitung wird geflutet, bis es zu Paketverlusten kommt und die TCP Congestion Control Algorithmen zuschlagen.

    Ja, was man auch daran sieht, dass im gleichen Maße, wie die Retransmissions (retr) ansteigen, das Congestion Window (cwnd) kleiner wird.

    Wenn man dann die Transferrate mit -b limitiert, sind die wieder größer.


    (Aber irgendwie hätte ich trotzdem erwartet, dass es die Engpässen in Richtung vom Sever mit der besser Anbindung zu dem mit der geringeren gibt und nicht umgekehrt)

  • (Aber irgendwie hätte ich trotzdem erwartet, dass es die Engpässen in Richtung vom Sever mit der besser Anbindung zu dem mit der geringeren gibt und nicht umgekehrt)

    Ja, das sollte man erwarten. Der schnellere Server kann den langsameren ja fluten. Aber ich glaube, dass es nicht so ist, ist der beste Beweis, dass die TCP Algorithmen funktionieren.


    Ich hab spaßeshalber den Congestion Algorithmus mal von CUBIC auf BBR umgestellt. Ergebnis: Katastrophe. Die Retransmissions sind genau so hoch, aber die Bandbreite G8 -> G9 bricht auf 300 MBit/s zusammen. Das hatte ich anders erwartet.


    Aber: Die Algorithmen scheinen Einfluss zu haben. Vielleicht ein Ansatzpunkt für weitere Untersuchungen.