Den Moment erlebt, als "Microsoft" meine Leitung gedrosselt hat. :)

[thomaz]

"Aufgrund einer Netzwerkbedingung wurde festgelegt, dass das Überlastungsfenster für mehrere Verbindungen beschränkt wird. Dies kann auf ein Problem in der globalen oder zusätzlichen TCP-Konfiguration zurückzuführen sein und hat die Verschlechterung des Durchsatzes zur Folge."

Das war der Moment.

Nach mehreren Tagen Nutzung einer frischen Windows Installation stand plötzlich diese Meldung in der Ergeinisanzeige.
Von da an nur noch 50-100 Mbit/s Durchsatz pro Verbindung.

Einmal TCP Optimizer (Optimal, Regler volle Pulle) und alles wieder Tutti.

 

[abulafia]

Naja, wenn die Eistellungen eh verbogen sind ist das okay, aber ansonsten würde ich das nicht machen.

Allein die Umstellung des Congestion Control Providers ist schon nicht sinnvoll unter Windows ≥ 10

Die ganzen TCP/IP Tweaks haben alle Fallstricke, ich würde unter normalen Umständen nicht daran herum optimieren.

 

[loser]

Einmal TCP Optimizer (Optimal, Regler volle Pulle) und alles wieder Tutti.

Jetzt noch TuneUp installieren und dort auch alles volle Pulle, dann hast ne Rakete von PC...

 

[Holzkopf]

TCPOptimizer ist ein sicheres Tool da passiert nix.
Wenn bei 500mbit+ Leitungen der Speed unter Windows nicht ankommt, hilft es sehr oft und das auf einfache weise.

Der Name stammt noch aus der ~XP zeit wo das Tool hauptsächlich dazu da war das TCP-Window auf seine Leitung anzupassen.

 

[robert_s]

TCPOptimizer ist ein sicheres Tool da passiert nix.
Wenn bei 500mbit+ Leitungen der Speed unter Windows nicht ankommt, hilft es sehr oft und das auf einfache weise.

Aber weiß das Tool auch die Adaptereinstellung "IPvX receive coalescing" auszuschalten? Die erweist sich oft als Leistungsbremse bei Single-Stream Downloads.

 

[thomaz]

3 FTP Uploads auf verschiedenen Sites mit ~13 Mbits (175/40) haben zu der Zeit des Eintrags stattgefunden.
Und ich war am Essen kochen.
Das hat Windows dazu veranlasst die Leitung zu drosseln.

 

[rg88]

Das hat Windows dazu veranlasst die Leitung zu drosseln.

ja, und du umgehst jetzt mit einem Tool das Problem anstatt die Ursache zu suchen.
Du tötest also eigentlich nur den Boten, der dir sagt, dass bei deinem System was nicht passt.

Irgend ein Virenscanner/Firewall installiert?

 

[Holzkopf]

Aber weiß das Tool auch die Adaptereinstellung "IPvX receive coalescing" auszuschalten? Die erweist sich oft als Leistungsbremse bei Single-Stream Downloads.

RSC stellt es aus ja aber wenn das im Treiber auch nochmal vorhanden ist, dann dieses nicht.

 

[h00bi]

TCPOptimizer ist ein sicheres Tool da passiert nix.
Wenn bei 500mbit+ Leitungen der Speed unter Windows nicht ankommt, hilft es sehr oft und das auf einfache weise.

Üblicherweise hilft es aber genau andersrum, nicht durch Optimierung sondern durch das Entfernen einer (von anderen Tools durchgeführten) Optimierung, also dem Rücksetzen auf Windows defaults.

 

[Holzkopf]

Üblicherweise hilft es aber genau andersrum, nicht durch Optimierung sondern durch das Entfernen einer (von anderen Tools durchgeführten) Optimierung, also dem Rücksetzen auf Windows defaults.

Man kann mit dem Tool auch die Windows Default laden, wenn es den Nutzer besser schlafen lässt.

 

[robert_s]

Mit Linux wär das nicht passiert!

Doch, leider auch. Das standardmäßige maximale TCP-RWIN des Linux-Kernels von 6MB reicht nicht mehr aus, um meinen Gigabit-Anschluss mit einem TCP-Download von Belwue auszureizen. Da würden 8MB vielleicht knapp reichen, aber ich habe es dann gleich mal auf 32MB aufgebohrt.

Leider nützt auch das bei vielen Servern nichts. Möglicherweise ist bei denen das tcp_wmem zu klein, um genug Daten auf die Reise zu schicken :-/

 

[Burnzi]

Doch, leider auch. Das standardmäßige maximale TCP-RWIN des Linux-Kernels von 6MB reicht nicht mehr aus, um meinen Gigabit-Anschluss mit einem TCP-Download von Belwue auszureizen. Da würden 8MB vielleicht knapp reichen, aber ich habe es dann gleich mal auf 32MB aufgebohrt.

du meinst das hier?

cat /proc/sys/net/ipv4/tcp_rmem
4096    131072  6291456

cat /proc/sys/net/ipv4/tcp_wmem
4096    16384   4194304

Oder guck ich an der falschen Stelle?

 

[pufferueberlauf]

Grob gesprochen wird die Menge an Bytes-in-flight durch das Minumum von aktuellem congestion-window des Senders und dem aktuellen receive-window des Empfängers limitiert. Fuer "volles Rohr" bei X Mbps muss daher gelten, dass das minimale der beiden Fenster >= RTT*X entspricht (mit passenden Einheiten), bei Gigabit Ethernet und 10ms RTT also

10ms: 0.01 * 1000 / 8 = 1.25 MB
20ms:0.02 * 1000 / 8 = 2.5 MB

wenn 6 MB nicht reichen, dann muss die RTT also:

6*8/1000 > 0.048 sec (EDIT: ms war falsch)

sein, was in GF (Daumenregel pro 100 Km Strecke 1 ms RTT) etwa 48*100 = 4800 Km waren... Ich bin jetzt nicht sicher ob ich da eher Linux oder aber dem Routing einen Vorwurf machen wuerde

 

[robert_s]

wenn 6 MB nicht reichen, dann muss die RTT also:

[COLOR=rgb(16, 16, 16)][FONT=Helvetica Neue]6*8/1000 > 0.048 ms[/FONT][/COLOR]

sein, was in GF (Daumenregel pro 100 Km Strecke 1 ms RTT) etwa 48*100 = 4800 Km waren... Ich bin jetzt nicht sicher ob ich da eher Linux oder aber dem Routing einen Vorwurf machen wuerde

48ms, nicht 0.048ms Genauer gerechnet (6*1024*1024*8/10^9) kommt man auf knapp 50ms.

Aber Theorie und Praxis:

--- speedtest.belwue.net ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99161ms
rtt min/avg/max/mdev = 19.276/26.016/57.651/8.295 ms

Trotz des "Peaks" müsste bei einer durchschnittlichen RTT von 26ms das 6MB RWIN locker reichen - tut es aber nicht. Kann aber sein, dass da noch andere Faktoren reinspielen, wie z.B. segmentation offloading oder vielleicht auch fast retransmits oder auch SACKs, welche dazu führen, dass man in der Praxis ein deutlich größeres RWIN benötigt als theoretisch errechnet...?

 

[pufferueberlauf]

48ms, nicht 0.048ms

Ja, Dank fuer die Korrektur, das hatte ich falsch beschriftet...

Trotz des "Peaks" müsste bei einer durchschnittlichen RTT von 26ms das 6MB RWIN locker reichen - tut es aber nicht. Kann aber sein, dass da noch andere Faktoren reinspielen, wie z.B. segmentation offloading oder vielleicht auch fast retransmits oder auch SACKs, welche dazu führen, dass man in der Praxis ein deutlich größeres RWIN benötigt als theoretisch errechnet...?

Das anderes reinspielt ist ja offensichtlich was genau ist schwer von aussen zu bestimmen. Fast retransmit und SACK sollten eigentlich dafuer sorgen, dass der Durchsatz auch bei (mildem) Packetloss hoch bleibt. Weisst Du welchen TCP-CC Algorithmus Belwue nutzt?

 

[Holzkopf]

Linux nutzt nur die Hälfte des Buffers für TCP.
heist ein 6MB window ist effektiv nur ein 3MB etc.

 

[pufferueberlauf]

Wuerde mich schon wundern wenn nur die Hälfte des TCP-RWIN fuer TCP genutzt würde... aber in der Tat gibt es da einige miteinander verbundene Parameter die in Kombination getunt werden sollten...

 

[robert_s]

Das anderes reinspielt ist ja offensichtlich was genau ist schwer von aussen zu bestimmen. Fast retransmit und SACK sollten eigentlich dafuer sorgen, dass der Durchsatz auch bei (mildem) Packetloss hoch bleibt. Weisst Du welchen TCP-CC Algorithmus Belwue nutzt?

Eigentlich hätte man ja gleich drauf kommen können: BufferBloat. Wenn der Download bei 1,11Gbit/s anschlägt, schnellt auch die RTT nach oben, bis über 80ms:

64 bytes from 129.143.4.238: icmp_seq=54 ttl=53 time=19.6 ms
64 bytes from 129.143.4.238: icmp_seq=55 ttl=53 time=22.0 ms
64 bytes from 129.143.4.238: icmp_seq=56 ttl=53 time=24.9 ms
64 bytes from 129.143.4.238: icmp_seq=57 ttl=53 time=20.9 ms
64 bytes from 129.143.4.238: icmp_seq=58 ttl=53 time=71.1 ms
64 bytes from 129.143.4.238: icmp_seq=59 ttl=53 time=55.3 ms
64 bytes from 129.143.4.238: icmp_seq=60 ttl=53 time=83.6 ms
64 bytes from 129.143.4.238: icmp_seq=61 ttl=53 time=84.6 ms
64 bytes from 129.143.4.238: icmp_seq=62 ttl=53 time=71.3 ms
64 bytes from 129.143.4.238: icmp_seq=63 ttl=53 time=20.9 ms
64 bytes from 129.143.4.238: icmp_seq=64 ttl=53 time=20.8 ms
64 bytes from 129.143.4.238: icmp_seq=65 ttl=53 time=22.2 ms
64 bytes from 129.143.4.238: icmp_seq=66 ttl=53 time=21.7 ms

Und das reicht ja dann auch rechnerisch nicht mehr für 1Gbit/s bei 6MB RWIN.

Wuerde mich schon wundern wenn nur die Hälfte des TCP-RWIN fuer TCP genutzt würde... aber in der Tat gibt es da einige miteinander verbundene Parameter die in Kombination getunt werden sollten...

Ich habe einige "Voodoo-Parameter" von diversen Webseiten durchprobiert. Am Ende kam ich dabei heraus, dass für den Unterschied, ob der wget-Download bei 800-900Mbit/s herumkrebst oder stabil bis an den Anschlag geht, nur diese eine Zeile verantwortlich ist:

sudo sysctl -w net.ipv4.tcp_rmem="4096 131072 33554432"

Aber wie gesagt, das tunet nur Single-Stream Downloads mit 1Gbit/s. Bei Uploads oder noch höheren Datenraten spielen mutmaßlich auch noch andere Parameter eine Rolle.

 

[Holzkopf]

Eigentlich hätte man ja gleich drauf kommen können: BufferBloat. Wenn der Download bei 1,11Gbit/s anschlägt, schnellt auch die RTT nach oben, bis über 80ms:

Und das reicht ja dann auch rechnerisch nicht mehr für 1Gbit/s bei 6MB RWIN.

Ich habe einige "Voodoo-Parameter" von diversen Webseiten durchprobiert. Am Ende kam ich dabei heraus, dass für den Unterschied, ob der wget-Download bei 800-900Mbit/s herumkrebst oder stabil bis an den Anschlag geht, nur diese eine Zeile verantwortlich ist:

Aber wie gesagt, das tunet nur Single-Stream Downloads mit 1Gbit/s. Bei Uploads oder noch höheren Datenraten spielen mutmaßlich auch noch andere Parameter eine Rolle.

Für Upload ist es der Parameter net.ipv4.tcp_wmem
Ich zitiere mich mal selbst

Linux nutzt nur die Hälfte des Buffers für TCP.
heist ein 6MB window ist effektiv nur ein 3MB etc.

 

[pufferueberlauf]

Das mit dem Zitieren waere noch besser, wenn Du nicht nur Dich selber zitieren/wiederholen wuerdest sondern auf eine Quelle verweist die Deine Aussage erklaert... Es macht naemlich immer noch wenig Sinn, dass net.ipv4.tcp_wmem mit tcp_ im Namen nur zur Hälfte fuer TCP genutzt würde... Bist Du sicher, dass es nicht darum geht, dass net.core.rmem_max/net.core.wmem_max mindestens so gross wie net.ipv4.tcp_wmem/net.ipv4.tcp_rmem sein sollten?