Upstream-Auslastung bei Download mit voller Geschwindigkeit

[robert_s]

In die Debatte über die signifikante Asymmetrie zwischen den Downstream- und Upstream-Bitraten bei Kabel wurde (u.a. auch von mir) immer wieder eingebracht, dass ein Download mit voller Geschwindigkeit so viele TCP-ACKs benötigt, dass der Upstream bei Kabel damit schon ziemlich ausgelastet sein würde.

Nun habe ich mir das mal in der Realität angesehen und siehe da: Bei einem Download mit den vollen 204Mbps (TCP-Nutzdatenrate) fliessen gerade mal um die 0,8Mbps (Ethernet-Datenrate) zurück ins Internet - also stehen noch über 90% des Upstreams zur Verfügung.

Ein Blick in Wireshark zeigt, dass Pakete mit bis zu 29200 Bytes TCP-Payload beim Prozessor ankommen - hier ist offenbar "TCP Segmentation Offload" am Werk, bei welchem der Netzwerk(karten)prozessor mehrere empfangene TCP-Pakete zu einem zusammensetzt, um den Prozessor bei der Verarbeitung zu entlasten, in diesem Fall bis zu 20.

Entsprechend kann die Frequenz der TCP-ACK Pakete auch nur deutlich niedriger ausfallen als angenommen: Statt jedem zweiten wird nur jedes bis-zu-zwanzigste Paket mit einem TCP-ACK quittiert.

Fazit: Alles viel besser als befürchtet. Allerdings habe ich noch keinen Test mit gleichzeitigem Down- und Upload durchgeführt, um zu sehen, wie viel Leistung man dabei erhält...

[pufferueberlauf]

Zitat von robert_s

In die Debatte über die signifikante Asymmetrie zwischen den Downstream- und Upstream-Bitraten bei Kabel wurde (u.a. auch von mir) immer wieder eingebracht, dass ein Download mit voller Geschwindigkeit so viele TCP-ACKs benötigt, dass der Upstream bei Kabel damit schon ziemlich ausgelastet sein würde.

Nun habe ich mir das mal in der Realität angesehen und siehe da: Bei einem Download mit den vollen 204Mbps (TCP-Nutzdatenrate) fliessen gerade mal um die 0,8Mbps (Ethernet-Datenrate) zurück ins Internet - also stehen noch über 90% des Upstreams zur Verfügung.

Ein Blick in Wireshark zeigt, dass Pakete mit bis zu 29200 Bytes TCP-Payload beim Prozessor ankommen - hier ist offenbar "TCP Segmentation Offload" am Werk, bei welchem der Netzwerk(karten)prozessor mehrere empfangene TCP-Pakete zu einem zusammensetzt, um den Prozessor bei der Verarbeitung zu entlasten, in diesem Fall bis zu 20.

Entsprechend kann die Frequenz der TCP-ACK Pakete auch nur deutlich niedriger ausfallen als angenommen: Statt jedem zweiten wird nur jedes bis-zu-zwanzigste Paket mit einem TCP-ACK quittiert.

Fazit: Alles viel besser als befürchtet. Allerdings habe ich noch keinen Test mit gleichzeitigem Down- und Upload durchgeführt, um zu sehen, wie viel Leistung man dabei erhält...

Hallo Robert,

interessanter Test, Offloads sind irgendwie garstig... Durch den ausgedünnten ACK-Strom wird jedes ACK-Paket auf einmal viel wertvoller, bzw. scherzhafter bei Verlust, was bei guter Verbindung gar nicht schlecht sein muss, aber in Anbetracht der relevanten RFCs zumindest unerwartet ist. Wie sieht das denn mit ausgeschalteten Offloads aus (also bei Linux TSO, GSO und GRO per ethtool deaktiviert)?

Gruss
P.

[robert_s]

Zitat von pufferueberlauf

Wie sieht das denn mit ausgeschalteten Offloads aus (also bei Linux TSO, GSO und GRO per ethtool deaktiviert)?

Gute Idee: Dann bietet sich das bekannte/ursprünglich erwartete Bild: Alle 2 empfangenen Pakete wird 1 Ack-Paket geschickt - und es werden beim Download mit vollen 212Mbps (Ethernet-Ebene inkl. FCS) knapp über 4Mbps im Upstream gesendet.

Also ist es TCP Segmentation Offload zu verdanken, dass die für die Acks benötigte Upstream-Datenrate um 80% reduziert wird. Dass das solche Auswirkungen hat, hätte ich nicht gedacht - ich dachte, das dient nur zur Entlastung des Hauptprozessors (was zumindest aktuelle Clients gar nicht nötig hätten).

Zitat von pufferueberlauf

interessanter Test, Offloads sind irgendwie garstig... Durch den ausgedünnten ACK-Strom wird jedes ACK-Paket auf einmal viel wertvoller, bzw. scherzhafter bei Verlust, was bei guter Verbindung gar nicht schlecht sein muss, aber in Anbetracht der relevanten RFCs zumindest unerwartet ist.

Der Verlust ist gar nicht schmerzhaft, weil ja gleich der nächste ACK hinterherkommt, der im Normalfall alle vorhergehenden ACKs impliziert. Also ein verlorener ACK hin und wieder sollte überhaupt nicht schaden.

Vielleicht die Sequenz: ACK für 20 Pakete geht verloren, folgende Downstream-Pakete fehlen, Empfänger schickt gar kein ACK mehr oder ein Selective-ACK zurück - aber dann kriegt der Durchsatz eh eine "Delle", und selbst wenn dann ~30KBytes unnötig noch mal auf den Weg geschickt werden, tut das eigentlich auch nicht weh.

[pufferueberlauf]

Zitat von robert_s

Gute Idee: Dann bietet sich das bekannte/ursprünglich erwartete Bild: Alle 2 empfangenen Pakete wird 1 Ack-Paket geschickt - und es werden beim Download mit vollen 212Mbps (Ethernet-Ebene inkl. FCS) knapp über 4Mbps im Upstream gesendet.

Also ist es TCP Segmentation Offload zu verdanken, dass die für die Acks benötigte Upstream-Datenrate um 80% reduziert wird. Dass das solche Auswirkungen hat, hätte ich nicht gedacht - ich dachte, das dient nur zur Entlastung des Hauptprozessors (was zumindest aktuelle Clients gar nicht nötig hätten).


Der Verlust ist gar nicht schmerzhaft, weil ja gleich der nächste ACK hinterherkommt, der im Normalfall alle vorhergehenden ACKs impliziert. Also ein verlorener ACK hin und wieder sollte überhaupt nicht schaden.

Vielleicht die Sequenz: ACK für 20 Pakete geht verloren, folgende Downstream-Pakete fehlen, Empfänger schickt gar kein ACK mehr oder ein Selective-ACK zurück - aber dann kriegt der Durchsatz eh eine "Delle", und selbst wenn dann ~30KBytes unnötig noch mal auf den Weg geschickt werden, tut das eigentlich auch nicht weh.

Ich dachte eher der Sender hat sein volles SendWindow an Bytes los geschickt und darf nur weiter senden wenn ein ACK kommt, wenn das jetzt verloren geht, haenger der Sender, und timed irgendwann aus und faengt nach moeglichkeit mit dem Ramping beim Initial Window an. Aber ich glaube Du hast recht, dass das eher kein echt relevantes Problem sein wird...



Gruss
P.