Höheres ping bei hohem parallelen Durchsatz

[Bonita Montero]

Ich habe zu meinem Freund rüber eine WLAN-Verbindung mit einem TP-Link
CPE510 Accesspoint (https://bit.ly/3JtTJ9N). Normalerweise ist der ping
zu ihm ca. 2ms. Ich habe aber gerade mal ein paar GB an Dateien auf sei-
seinen Rechner übertragen und der ping wuchs auf 620ms an. Dann machte
ich mal ein netstat und sah, dass auf die IP seines Rechners nur ein
IPv6/TCP-Socket auf ist. Aber eigentlich kann es ja nicht sein, dass
ein TCP-Socket die Sende-Queue des Accesspoints so vollschießt, dass
solch ein Delay entsteht. Ganz einfach weil TCP seine Sende-Frequenz
ja von der Geschwindigkeit der zurücklaufenden ACKs abhängig macht;
und wenn das so ist sollte den Sendefrequenz der TCP-Pakete so liegen,
dass sich im Accesspoint eben nicht die Pakete zum Senden sammeln, son-
dern dort eigentlich pro Zeitpunkt nur im Schnitt ein Paket pro TCP
-Verbindung existiert.
Daher nehme ich mal an, dass SMB hier kein TCP, sondern UDP verwendet
und, dass das eine weniger intelligente Staukontrolle hat als TCP. So,
gibt es denn einen Weg, dass ich SMB dazu bringen kann, sich besser an
die Verhältnisse anzupassen ?

[Friedemann Stoyan]

So pauschal stimmt das meiner Meinung nach nicht.

Erstens gibt es einen ganzen Sack voll Congestion Algorithmen:
https://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm

Zweitens im Linux Default Congestion Algorithmus Cubic, spielt genau die RTT
gar keine Rolle, nur Packet Loss.

Ich würde an zwei Stellschrauben drehen: Wahl eines anderen Congestion
Algorithmus. Hier habe ich mit BBR gute Erfahrungen gemacht.

Zweitens: Die default Linux QDISC "pfifo_fast" garantiert auch gar keine
Fairness zwischen verschiedenen Flows. Ein fetter Flow kann alles ruinieren.
An deiner Stelle würde ich mal mit "fq_codel" experimentieren. Das soll bei
neueren Installationen inzwischen wohl auch der Standard sein.

Ich habe natürlich keine Ahnung, ob das alles so auf dem TP-Link Teil so
umsetzbar ist.

mfg Friedemann

[Bonita Montero]

Am 14.02.2022 um 16:28 schrieb Friedemann Stoyan:

> Bonita Montero wrote:

>> Ich habe zu meinem Freund rüber eine WLAN-Verbindung mit einem TP-Link
>> CPE510 Accesspoint (https://bit.ly/3JtTJ9N). Normalerweise ist der ping
>> zu ihm ca. 2ms. Ich habe aber gerade mal ein paar GB an Dateien auf sei-
>> seinen Rechner übertragen und der ping wuchs auf 620ms an. Dann machte
>> ich mal ein netstat und sah, dass auf die IP seines Rechners nur ein
>> IPv6/TCP-Socket auf ist. Aber eigentlich kann es ja nicht sein, dass
>> ein TCP-Socket die Sende-Queue des Accesspoints so vollschießt, dass
>> solch ein Delay entsteht. Ganz einfach weil TCP seine Sende-Frequenz
>> ja von der Geschwindigkeit der zurücklaufenden ACKs abhängig macht;
>> und wenn das so ist sollte den Sendefrequenz der TCP-Pakete so liegen,
>> dass sich im Accesspoint eben nicht die Pakete zum Senden sammeln, son-
>> dern dort eigentlich pro Zeitpunkt nur im Schnitt ein Paket pro TCP
>> -Verbindung existiert.
>> Daher nehme ich mal an, dass SMB hier kein TCP, sondern UDP verwendet
>> und, dass das eine weniger intelligente Staukontrolle hat als TCP. So,
>> gibt es denn einen Weg, dass ich SMB dazu bringen kann, sich besser an
>> die Verhältnisse anzupassen ?

> So pauschal stimmt das meiner Meinung nach nicht.
> Erstens gibt es einen ganzen Sack voll Congestion Algorithmen:
> https://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm
> Zweitens im Linux Default Congestion Algorithmus Cubic, spielt
> genau die RTT gar keine Rolle, nur Packet Loss.

Ich nutze Windows 11, meine Freundin Windows 10. Wenn ich iperf3
verwende, dann zeigt sich das Problem übrigens nicht, d.h. das SMB
stützt sich nicht auf TCP für die rohen Daten-Transfers; ist auch
eigentlich der einzig sinnvolle Weg, denn wenn man sonst eine asyn-
chrone Datei-Operation macht und die cancelt (CancelIo(Ex)), dann
will der Kernel dann nicht völlig autonom ggf. noch ausstehende
Pakete ge-ACK-t haben.

[Bonita Montero]

Äh, mein Freund.

[Juergen Ilse]

Hallo,

Bonita Montero <Bonita....@gmail.com> wrote:
> Ich habe zu meinem Freund rüber eine WLAN-Verbindung mit einem TP-Link
> CPE510 Accesspoint (https://bit.ly/3JtTJ9N). Normalerweise ist der ping
> zu ihm ca. 2ms. Ich habe aber gerade mal ein paar GB an Dateien auf sei-
> seinen Rechner übertragen und der ping wuchs auf 620ms an.

Wenn du das Netz gleichzeitig mit Datentransfers zuschiesst, ist ein
erheblich Anstieg der ping-Antwortzeiten voellig normal. Insbesondere
bei einem shared Medium, bei dem die maximale Uebertragugsrate im
Vergleich zum LAN doch vermutlich eher eingeschraenkt ist ...

> Dann machte
> ich mal ein netstat und sah, dass auf die IP seines Rechners nur ein
> IPv6/TCP-Socket auf ist. Aber eigentlich kann es ja nicht sein, dass
> ein TCP-Socket die Sende-Queue des Accesspoints so vollschießt, dass
> solch ein Delay entsteht. Ganz einfach weil TCP seine Sende-Frequenz
> ja von der Geschwindigkeit der zurücklaufenden ACKs abhängig macht;
> und wenn das so ist sollte den Sendefrequenz der TCP-Pakete so liegen,
> dass sich im Accesspoint eben nicht die Pakete zum Senden sammeln, son-
> dern dort eigentlich pro Zeitpunkt nur im Schnitt ein Paket pro TCP
> -Verbindung existiert.

Dass die "Mindest-MTU" bei IPv6 hoeher ist als bei IPv4 weisst du?
Aber daran kann es eigentlich auch nicht liegen.

Erwzinge doch einfach mal IPv4 (z.B. indem du auf diener Seite IPv6
abschaltest). Hast du dann noch den selben Effekt?

> Daher nehme ich mal an, dass SMB hier kein TCP, sondern UDP verwendet
> und, dass das eine weniger intelligente Staukontrolle hat als TCP. So,
> gibt es denn einen Weg, dass ich SMB dazu bringen kann, sich besser an
> die Verhältnisse anzupassen ?

Nutze Cifs statt smbfs. Wenn ich mich jetzt nicht falsch erinnere,
erzwingt Cifs "direct SMB", sprich TCP ueber TCP/445 und nicht die
aelteren UDP basierten Protokolle.

Ich gehe aber davon aus, dass du mit der Datenuebertragung einfach die
WLAN-Kapazitaet ziemlich voll geschossen hast, und deshalb deine Ping
Antwortzeiten nach oben gehen.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)