Frage Windows TCP Window Scaling Plateau zu früh treffen


Szenario: Wir haben eine Reihe von Windows-Clients, die regelmäßig große Dateien (FTP / SVN / HTTP PUT / SCP) auf Linux-Server hochladen, die ~ 100-160 ms entfernt sind. Wir haben 1 GBit / s synchrone Bandbreite im Büro und die Server sind entweder AWS-Instanzen oder physisch in US-DCs gehostet.

Der erste Bericht besagt, dass das Hochladen auf eine neue Serverinstanz wesentlich langsamer vonstatten geht. Dies führte zu Tests und von mehreren Standorten aus; Die Clients sahen von ihren Windows-Systemen stabile 2-5 Mbit / s zum Host.

Ich bin ausgebrochen iperf -s auf einer AWS-Instanz und dann von einem Windows Kunde im Büro:

iperf -c 1.2.3.4

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[  5]  0.0-10.0 sec  6.55 MBytes  5.48 Mbits/sec

iperf -w1M -c 1.2.3.4

[  4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[  4]  0.0-18.3 sec   196 MBytes  89.6 Mbits/sec

Die letztgenannte Zahl kann bei nachfolgenden Tests (Vagare von AWS) erheblich variieren, liegt aber normalerweise zwischen 70 und 130 Mbit / s, was mehr als genug für unsere Bedürfnisse ist. Wiresharking die Sitzung, kann ich sehen:

  • iperf -c Windows SYN - Fenster 64kb, Maßstab 1 - Linux SYN, ACK: Fenster 14kb, Maßstab: 9 (* 512) iperf window scaling with default 64kb Window
  • iperf -c -w1M Windows SYN - Windows 64kb, Maßstab 1 - Linux SYN, ACK: Fenster 14kb, Maßstab: 9 iperf window scaling with default 1MB Window

Natürlich kann die Verbindung diesen hohen Durchsatz aufrechterhalten, aber ich muss die Fenstergröße explizit festlegen, um sie zu nutzen, was die meisten realen Anwendungen nicht zulassen. Die TCP-Handshakes verwenden jeweils die gleichen Startpunkte, aber der erzwungene skaliert

Umgekehrt, von einem Linux-Client im selben Netzwerk eine gerade, iperf -c (mit dem Systemstandard 85kb) gibt mir:

[  5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[  5]  0.0-10.8 sec   142 MBytes   110 Mbits/sec

Ohne Zwang skaliert es wie erwartet. Dies kann in den dazwischenliegenden Hops oder unseren lokalen Switches / Routern nicht vorkommen und scheint Windows 7 und 8 Clients gleichermaßen zu betreffen. Ich habe viele Anleitungen zur automatischen Optimierung gelesen, aber in der Regel geht es darum, die Skalierung zu deaktivieren, um schlechtes Heimnetzwerk-Kit zu umgehen.

Kann mir jemand sagen, was hier vor sich geht, und mir einen Weg geben, es zu reparieren? (Vorzugsweise kann ich etwas über GPO in der Registrierung speichern.)

Anmerkungen

Für die betreffende AWS Linux-Instanz gelten die folgenden Kerneleinstellungen sysctl.conf:

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

Ich habe gebraucht dd if=/dev/zero | nc Weiterleiten an /dev/null am Serverende auszuschließen iperf und entfernen Sie alle anderen möglichen Engpässe, aber die Ergebnisse sind die gleichen. Tests mit ncftp (Cygwin, Native Windows, Linux) skalieren auf die gleiche Weise wie die obigen iperf-Tests auf ihren jeweiligen Plattformen.

Bearbeiten

Ich habe hier eine andere konsistente Sache entdeckt, die relevant sein könnte: enter image description here

Dies ist die erste Sekunde der 1MB Aufnahme, gezoomt. Sie können sehen Langsamer Start in Aktion, wenn das Fenster größer wird und der Puffer größer wird. Da ist dann dieses winzige Plateau von ~ 0.2s genau An dem Punkt, an dem der Standard-iperf-Test für das Fenster immer flacher wird. Dieser ist natürlich zu viel schwindelerregenderen Höhen skaliert, aber es ist merkwürdig, dass es eine Pause in der Skalierung gibt (Werte sind 1022 Bytes * 512 = 523264), bevor dies geschieht.

Update - 30. Juni.

Im Anschluss an die verschiedenen Antworten:

  • CTCP aktivieren - Das macht keinen Unterschied; Die Fensterskalierung ist identisch. (Wenn ich das richtig verstehe, erhöht diese Einstellung die Rate, mit der das Staufenster vergrößert wird, anstatt die maximale Größe, die es erreichen kann)
  • Aktivieren von TCP-Zeitstempeln - Auch hier keine Änderung.
  • Nagles Algorithmus - Das ergibt Sinn und zumindest bedeutet das, dass ich diese bestimmten Punkte in der Grafik wahrscheinlich als Hinweis auf das Problem ignorieren kann.
  • PCAP-Dateien: Zip-Datei verfügbar hier: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (Anonymisiert mit Bittwiste, Extrakte bis ~ 150MB, da es jeweils einen von jedem OS-Client zum Vergleich gibt)

Update 2 - 30. Juni

O, also auf Kyle Vorschlag folgend, habe ich ctcp aktiviert und Schornsteinabladen deaktiviert: Globale TCP-Parameter

----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : disabled
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : enabled
Initial RTO                         : 3000
Non Sack Rtt Resiliency             : disabled

Aber leider keine Änderung des Durchsatzes.

Ich habe hier jedoch eine Ursache / Wirkung-Frage: Die Graphen sind der RWIN-Wert, der in den ACKs des Servers für den Client festgelegt ist. Bin ich bei Windows-Clients der Meinung, dass Linux diesen Wert nicht über diesen Tiefpunkt hinaus skaliert, weil der begrenzte CWIN des Clients verhindert, dass sogar dieser Puffer gefüllt wird? Könnte es einen anderen Grund geben, dass Linux die RWIN künstlich einschränkt?

Hinweis: Ich habe versucht, ECN für die Hölle davon zu aktivieren; aber keine Veränderung, dort.

Update 3 - 31. Juni.

Keine Änderung nach dem Deaktivieren von Heuristiken und RWIN-Autotuning. Habe die Intel-Netzwerktreiber auf die neueste Version (12.10.28.0) mit Software aktualisiert, die über die Geräte-Manager-Registerkarten Funktionen zur Optimierung aufzeigt. Die Karte ist ein 82579V Chipsatz on-board NIC - (Ich werde noch mehr Tests von Kunden mit realtek oder anderen Anbietern machen)

Ich habe mich für einen Moment auf die NIC konzentriert und folgendes versucht (Meistens nur unwahrscheinliche Täter ausgeschlossen):

  • Erhöhen Sie die Empfangspuffer von 256 auf 2k und übertragen Sie die Puffer von 512 auf 2k (beide jetzt auf Maximum) - Keine Änderung
  • Deaktiviert alle IP / TCP / UDP-Prüfsummen-Offloading. - Keine Änderung.
  • Deaktiviert Groß Senden Offload - Nada.
  • Deaktivierte IPv6, QoS-Planung - Nowt.

Update 3 - 3. Juli

Beim Versuch, die Linux-Server-Seite zu eliminieren, startete ich eine Server 2012R2-Instanz und wiederholte die Tests mit iperf (cygwin binär) und NTttcp.

Mit iperf, Musste ich explizit angeben -w1m auf beide Seiten vor der Verbindung würde über ~ 5Mbit / s skalieren. (Übrigens konnte ich überprüft werden und der BDP von ~ 5Mbits bei 91ms Latenz ist fast genau 64kb. Finde das Limit ...)

Die ntttcp-Binärdateien zeigten nun solche Beschränkungen. Verwenden ntttcpr -m 1,0,1.2.3.5 auf dem Server und ntttcp -s -m 1,0,1.2.3.5 -t 10 auf dem Client kann ich viel besseren Durchsatz sehen:

Copyright Version 5.28
Network activity progressing...


Thread  Time(s) Throughput(KB/s) Avg B / Compl
======  ======= ================ =============
     0    9.990         8155.355     65536.000

#####  Totals:  #####

   Bytes(MEG)    realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
       79.562500      10.001       1442.556            7.955

Throughput(Buffers/s) Cycles/Byte       Buffers
===================== =========== =============
              127.287     308.256      1273.000

DPCs(count/s) Pkts(num/DPC)   Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
     1868.713         0.785        9336.366          0.157

Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
       57833            14664           0      0      9.476

8MB / s bringt es auf die Ebenen, die ich mit explizit großen Fenstern erhalten habe iperf. Seltsamerweise jedoch 80MB in 1273 Puffern = ein 64kB Puffer wieder. Ein weiterer Wireshark zeigt ein gutes, variables RWIN, das vom Server zurückkommt (Skalierungsfaktor 256), das der Client zu erfüllen scheint; vielleicht gibt ntttcp das Sendefenster falsch an.

Update 4 - 3. Juli

Auf Anfrage von @Karyhead habe ich noch ein paar Tests durchgeführt und ein paar weitere Captures generiert: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip

  • Zwei mehr iperfs, sowohl von Windows auf den gleichen Linux-Server wie vorher (1.2.3.4): Eins mit 128k Socket-Größe und Standard-64k-Fenster (beschränkt auf ~ 5Mbit / s) und eins mit einem 1MB-Sendefenster und Standard-8kb-Socket-Größe. (Waage höher)
  • Ein ntttcp Trace vom selben Windows-Client zu einer Server 2012R2 EC2-Instanz (1.2.3.5). hier lässt sich der Durchsatz gut skalieren. Hinweis: NTttcp tut etwas an Port 6001 seltsam, bevor es die Testverbindung öffnet. Ich bin mir nicht sicher, was dort passiert.
  • Ein FTP-Daten-Trace, Upload von 20 MB /dev/urandom zu einem nahezu identischen Linux-Host (1.2.3.6) mit Cygwin ncftp. Wieder ist das Limit da. Das Muster ist mit Windows Filezilla sehr ähnlich.

Wechseln iperf Pufferlänge macht den erwarteten Unterschied zum Zeitsequenzdiagramm (viel mehr vertikale Abschnitte), aber der tatsächliche Durchsatz ist unverändert.


50
2018-06-26 09:31


Ursprung


Ein seltener Fall eines gut erforschten Problems, das offensichtlich nicht in der Dokumentation enthalten ist. Nett - lass uns hoffen, dass jemand eine Lösung findet (weil ich irgendwie denke, dass ich das auch benutzen kann). - TomTom
Versuchen Sie, RFC 1323-Zeitstempel zu aktivieren, da diese standardmäßig in Windows deaktiviert sind, während Linux diese standardmäßig aktiviert hat. netsh int tcp set global timestamps=enabled - Brian
Die Verzögerung von 200 ms ist wahrscheinlich der Nagle-Algorithmus in Aktion. Da Daten von TCP auf einer bestimmten Verbindung empfangen werden, sendet es eine Bestätigung nur zurück, wenn eine der folgenden Bedingungen erfüllt ist: Für das vorherige empfangene Segment wurde keine Bestätigung gesendet; Ein Segment wird empfangen, aber kein anderes Segment kommt innerhalb von 200 Millisekunden für diese Verbindung an. - Greg Askew
Irgendeine Chance, irgendwo von einem der langsameren Sender irgendwelche Paketerfassungen zu machen? - Kyle Brandt♦
Ich habe mein OP mit den Ergebnissen dieser Tests und Links zu repräsentativen Capture-Dateien aktualisiert. - SmallClanger


Antworten:


Haben Sie versucht, zu aktivieren? Zusammengesetzte TCP (CTCP) in Ihren Windows 7/8 Clients.

Lesen Sie bitte:

Steigern der Absender-Side-Leistung für High-BDP-Übertragung

http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx

...

Diese Algorithmen funktionieren gut für kleine BDPs und kleineres Empfangsfenster   Größen. Wenn Sie jedoch eine TCP-Verbindung mit einem großen Empfang haben   Fenstergröße und a großer BDPB. das Replizieren von Daten zwischen zwei   Server mit hoher Geschwindigkeit WAN-Verbindung mit einer 100-minütigen Rundreise   Zeit, diese Algorithmen Vergrößern Sie das Sendefenster nicht schnell genug   Nutzen Sie die Bandbreite der Verbindung voll aus.

Um die Bandbreite von TCP-Verbindungen in diesen besser zu nutzen   In Situationen enthält der TCP / IP-Stack der nächsten Generation Compound TCP   (CTCP). CTCP erhöht aggressiver das Sendefenster für Verbindungen mit großen Empfangsfenstergrößen und BDPs. CTCP versucht es   Maximieren Sie den Durchsatz bei diesen Verbindungstypen durch Überwachen der Verzögerung   Variationen und Verluste. Darüber hinaus stellt CTCP dieses Verhalten sicher   wirkt sich nicht negativ auf andere TCP-Verbindungen aus.

...

CTCP ist standardmäßig auf Computern mit Windows Server 2008 aktiviert und von deaktiviert   Standard auf Computern mit Windows Vista. Sie können CTCP mit dem aktivieren netsh interface tcp set global congestionprovider=ctcp Befehl. Sie können CTCP mit deaktivieren   das netsh interface tcp set global congestionprovider=none Befehl.

Bearbeiten 30.06.2014

um zu sehen, ob CTCP wirklich "on" ist

> netsh int tcp show global

d.h.

enter image description here

PO sagte:

Wenn ich das richtig verstehe, erhöht diese Einstellung die Rate um welches das Staufenster eher vergrößert als die maximale Größe es kann erreichen

CTCP erhöht aggressiv das Sendefenster

http://technet.microsoft.com/en-us/library/bb878127.aspx

Zusammengesetzte TCP

Die vorhandenen Algorithmen, die das Senden eines TCP-Peers verhindern   Überwältigendes Netzwerk sind als langsamer Start und Stau bekannt   Vermeidung. Diese Algorithmen erhöhen die Anzahl der Segmente, die die   Der Absender kann senden, bekannt als das Sendefenster, wenn er anfänglich Daten sendet   auf der Verbindung und bei der Wiederherstellung von einem verlorenen Segment. Langsamer Start   erhöht das Sendefenster um jeweils ein vollständiges TCP-Segment   Bestätigungssegment empfangen (für TCP in Windows XP und Windows   Server 2003) oder für jedes bestätigte Segment (für TCP in Windows   Vista und Windows Server 2008). Stauvermeidung erhöht die   Sendefenster um ein vollständiges TCP-Segment für jedes vollständige Datenfenster   ist anerkannt.

Diese Algorithmen funktionieren gut für LAN-Mediengeschwindigkeiten und kleinere TCP-Fenster   Größen. Wenn Sie jedoch eine TCP-Verbindung mit einem großen Empfang haben   Fenstergröße und ein großes Bandbreite-Verzögerung Produkt (hohe Bandbreite und   hohe Verzögerung), z. B. die Replikation von Daten zwischen zwei Servern   über eine Hochgeschwindigkeits-WAN-Verbindung mit einer Umlaufzeit von 100 ms   Algorithmen erhöhen das Sendefenster nicht schnell genug, um vollständig zu sein   Nutze die Bandbreite der Verbindung. Zum Beispiel auf einem 1 Gigabit   pro Sekunde (Gbps) WAN-Verbindung mit einer Umlaufzeit von 100 ms (RTT), es kann Nehmen Sie bis zu einer Stunde für das Sendefenster zu erhöhen, um zunächst zu erhöhen große Fenstergröße, die vom Empfänger angekündigt und wiederhergestellt wird, wenn es gibt verlorene Segmente.

Um die Bandbreite besser zu nutzen von TCP-Verbindungen in diesen   Situationen, die der TCP / IP-Stack der nächsten Generation beinhaltet Zusammengesetzte TCP   (CTCP). CTCP erhöht aggressiver das Sendefenster für   Verbindungen mit großen Empfangsfenstergrößen und großer Bandbreitenverzögerung   Produkte. CTCP versucht, den Durchsatz für diese Typen zu maximieren   Verbindungen nach Überwachung von Verzögerungsschwankungen und Verlusten. CTCP auch   stellt sicher, dass sich sein Verhalten nicht negativ auf andere TCP auswirkt   Verbindungen.

Bei Tests, die intern bei Microsoft durchgeführt wurden, große Sicherungszeiten   bei einer 1-Gbit / s-Verbindung mit einer 50-Minuten-RTT um fast die Hälfte reduziert.   Verbindungen mit einem Verzögerungsprodukt mit größerer Bandbreite können sogar noch besser sein   Performance. CTCP und Empfangsfenster-Auto-Tuning arbeiten zusammen für   erhöhte Link-Auslastung und kann zu einer erheblichen Performance führen   Verstärkungen für Produktverbindungen mit großer Bandbreite.


15
2018-06-29 10:03



Nur als Ergänzung zu dieser Antwort ist das Powershell-Äquivalent in Server 2012 / Win8.1 Set-NetTCPSetting mit dem -CongestionProvider Parameter ..., der CCTP, DCTCP und Default akzeptiert. Windows-Client und -Server verwenden unterschiedliche Standardkongestionsprovider. technet.microsoft.com/en-us/library/hh826132.aspx - Ryan Ries
Ich verstehe, worauf Sie hinauswollen, aber es scheint nicht zu gelten. Um der Sache willen lief ich 30 Minuten iperf und das Fenster skalierte immer noch nicht über ~ 520kb hinaus. Etwas anderes begrenzt den CWND, bevor dieser aggressive Algorithmus irgendwelche Vorteile zeigen kann. - SmallClanger
Es gibt einen alten (bereits behobenen) Vista-Bug, der diese Art von Problemen bei der Übertragung von Nicht-HTML-Protokollen aufzeigte. Sieht Ihr Problem genau gleich aus, wenn Sie die gleiche Datei per HTML oder per FTP übertragen? - Pat
@Pat - Es tut. SVN-Commits (über HTTP und HTTPS) und FTP-Übertragungen an ein anderes System auf AWS weisen ebenfalls dieselben Beschränkungen auf. - SmallClanger
Wie sieht es mit der Firewall des Windows-Clients aus? Kannst du mit Firewall komplett austesten? siehe hier: ask.wireshark.org/questions/2365/tcp-window-size-and-scaling - Pat


Klärung des Problems:

TCP hat zwei Fenster:

  • Das Empfangsfenster: Wie viele Bytes verbleiben im Puffer? Dies ist eine Flusssteuerung, die durch den Empfänger auferlegt wird. Sie können die Größe des Empfangsfensters im Wireshark sehen, da es aus der Fenstergröße und dem Skalierungsfaktor für die Fensterung im TCP-Header besteht. Beide Seiten der TCP-Verbindung werden ihr Empfangsfenster ankündigen, aber im Allgemeinen ist derjenige, den Sie interessieren, derjenige, der den Großteil der Daten empfängt. In Ihrem Fall ist es der "Server", da der Client auf den Server hochlädt
  • Das Staufenster. Dies ist eine Flusssteuerung, die vom Absender auferlegt wird. Dies wird vom Betriebssystem beibehalten und erscheint nicht im TCP-Header. Es steuert die Rate, wie schnell Daten gesendet werden.

In der von Ihnen bereitgestellten Datei. Wir können sehen, dass der Empfangspuffer niemals überläuft:

enter image description here

Meine Analyse ist, dass der Sender nicht schnell genug sendet, weil das Sendefenster (aka das Überlastungssteuerungsfenster) sich nicht genug öffnet, um die RWIN des Empfängers zu erfüllen. Kurz gesagt, der Empfänger sagt "Gib mir mehr", und wenn Windows der Absender ist, sendet er nicht schnell genug.

Dies wird durch die Tatsache belegt, dass in dem obigen Graphen der RWIN offen bleibt und mit der Umlaufzeit von 0,09 Sekunden und einem RWIN von ~ 500.000 Bytes ein maximaler Durchsatz gemäß dem Bandbreitenverzögerungsprodukt (500000) erwartet werden kann /0,09) * 8 = ~ 42 Mbit / s (und Sie erhalten nur etwa 5 in Ihrem Gewinn für Linux-Capture).

Wie man es repariert?

Ich weiß es nicht. interface tcp set global congestionprovider=ctcp klingt wie das Richtige für mich, weil es das Sendefenster vergrößern würde (was eine andere Bezeichnung für das Staufenster ist). Du hast gesagt, dass es nicht funktioniert. Also nur um sicher zu gehen:

  1. Haben Sie nach dem Aktivieren neu gestartet?
  2. Ist Chimney Offload? Wenn es vielleicht ist, versuche es als Experiment abzuschalten. Ich weiß nicht, was genau ausgelagert wird, wenn das aktiviert ist, aber wenn die Steuerung des Sendefensters einer von ihnen ist, hat Conspainprovider möglicherweise keinen Effekt, wenn dies aktiviert ist ... Ich rate nur ...
  3. Außerdem denke ich, dass dies vor Windows 7 sein könnte, aber Sie könnten versuchen, die beiden Registrierungsschlüssel DefaultSendWindow und DefaultReceiveWindow in HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD-Parameters hinzuzufügen und zu spielen. Wenn diese sogar funktionieren, hast du wahrscheinlich ctcp ausgeschaltet.
  4. Noch eine Vermutung, probier es aus netsh interface tcp show heuristics. Ich denke, das könnte RWIN sein, aber es heißt nicht, also spiele vielleicht mit dem Deaktivieren / Aktivieren, falls es das Sendefenster beeinflusst.
  5. Stellen Sie außerdem sicher, dass Ihre Treiber auf Ihrem Test-Client auf dem neuesten Stand sind. Vielleicht ist etwas kaputt.

Ich würde all diese Experimente mit all den Offloading-Funktionen ausprobieren, um die Möglichkeit zu eliminieren, dass die Netzwerktreiber etwas umschreiben / modifizieren (behalte die CPU im Auge, während das Offloading deaktiviert ist). Das TCP_OFFLOAD_STATE_DELEGATED Struktur scheint zumindest zu bedeuten, dass CWnd-Offloading zumindest möglich ist.


12
2018-06-30 15:11



Ich habe deine "Antwort" gemeldet, weil deine Antwort keine Antwort ist; Ich wurde sofort abgelehnt; jetzt sehe ich, wie "Leute" deine "Nein-Antwort" hochstimmen ... wirklich lustig - Pat
@Pat: Sie können auf die Abstimmungsnummer klicken, um die Aufschlüsselung von Upvotes / Downvotes zu sehen. Derzeit haben Sie keine Antwort auf Ihre Antwort. Meine Antwort löst sein Problem nicht (aber noch keine Antwort), es erklärt und lokalisiert das Problem (hoffentlich richtig!), Was ein wichtiger Schritt bei der Fehlersuche ist. - Kyle Brandt♦
@ Kyle Brandt, wenn Sie Ihre akzeptieren, ist keine Antwort Ich frage mich, warum es nicht "automatisch" ohne weitere Rücksicht entfernt wird ?? und du liegst falsch; Ich habe eine "down-vote" (unupvote) "so bald" wie ich Ihre "Antwort" gemeldet habe; das eine wurde noch nicht entfernt. Es scheint, dass Sie hier nach "speziellen" Regeln spielen. - Pat
@Pat Wenn es hilft, war Kyles Nicht-Antwort unglaublich hilfreich. Ich habe jetzt eine klarere Vorstellung davon, welche Puffer begrenzt sind, und ich fühle, dass ich dadurch einer richtigen Lösung näher gekommen bin. Manchmal können Fragen wie diese eine gemeinschaftliche Anstrengung sein, die mit ein wenig vernünftiger Bearbeitung zu einer richtigen werden kann Q und ein richtiger EIN. - SmallClanger
@SmallClanger mit allem Respekt, SF hat eine Reihe von Regeln, die von allen Benutzern einschließlich Kyle Brandt gefolgt werden sollten; wenn es sich nicht um eine Antwort handelt, muss sie gelöscht oder als Kommentar verschoben werden, egal wie viele Freunde er unter den "Moderatoren" hat. - Pat


Es gab einige tolle Infos hier bei @Pat und @Kyle. Achten Sie unbedingt auf @ Kyle Erläuterung von den TCP-Empfangs- und Sendefenstern, glaube ich, gab es einige Verwirrung darum. Um die Dinge weiter zu verwirren, verwendet Iperf den Begriff "TCP - Fenster" mit dem -w Einstellung, die eine Art von mehrdeutigen Begriff in Bezug auf das Empfangen, Senden oder insgesamt Schiebefenster ist. Was es tatsächlich tut, ist den Socket Sendepuffer für die -c (Client) -Instanz und der Socket-Empfangspuffer auf dem -s (Server) -Instanz. Im src/tcp_window_size.c:

if ( !inSend ) {
    /* receive buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_RCVBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
} else {
    /* send buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_SNDBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
}

Wie Kyle erwähnt, ist das Problem nicht mit dem Empfangsfenster auf der Linux-Box, aber der Absender öffnet das Sendefenster nicht genug. Es ist nicht so, dass es sich nicht schnell genug öffnet, sondern nur bei 64k.

Die Standard-Socket-Puffergröße unter Windows 7 ist 64 KB. Hier ist, was die Dokumentation über die Socket-Puffergröße in Bezug auf den Durchsatz bei MSDN

Beim Senden von Daten über eine TCP-Verbindung mit Windows Sockets ist es   wichtig, um eine ausreichende Menge von Daten ausstehen (gesendet aber   noch nicht bestätigt) in TCP, um das Höchste zu erreichen   Durchsatz. Der ideale Wert für die ausstehende Datenmenge   Den besten Durchsatz für die TCP-Verbindung zu erreichen nennt man das Ideal   Send Backlog (ISB) Größe. Der ISB-Wert ist eine Funktion des   Bandbreite-Verzögerung Produkt der TCP-Verbindung und des Empfängers   beworbenes Empfangsfenster (und teilweise die Menge an Staus in der   Netzwerk).

Ok, bla bla bla, Jetzt gehts los:

Anwendungen, die eine blockierende oder nicht blockierende Sendeanforderung an   eine Zeit, die normalerweise auf die interne Sendepufferung durch Winsock angewiesen ist   anständiger Durchsatz. Das Sendepufferlimit für eine gegebene Verbindung ist   gesteuert durch die Socket-Option SO_SNDBUF. Für die Blockierung und   nicht blockierende Sendemethode, Das Sendepufferlimit bestimmt, wie viel   Daten werden in TCP ausstehend gehalten. Wenn der ISB-Wert für die Verbindung   ist größer als das Sendepufferlimit, dann wird der Durchsatz erreicht   Die Verbindung wird nicht optimal sein.

Der durchschnittliche Durchsatz Ihres letzten iperf-Tests mit dem 64k-Fenster beträgt 5,8 Mbps. Das ist von Statistiken> Zusammenfassung in Wireshark, der alle Bits zählt. Wahrscheinlich zählt iperf den TCP-Datendurchsatz von 5,7 Mbps. Die gleiche Leistung sehen wir auch beim FTP-Test, ~ 5.6Mbps.

Der theoretische Durchsatz mit einem 64k Sendepuffer und 91ms RTT beträgt .... 5.5Mbps. Nah genug für mich.

Wenn wir uns Ihren 1-MB-Fenster-Iperf-Test ansehen, beträgt der Tput 88,2 Mbit / s (86,2 Mbit / s nur für TCP-Daten). Der theoretische Wert bei einem 1 MB-Fenster beträgt 87,9 Mbit / s. Wiederum nah genug für die Regierungsarbeit.

Dies zeigt, dass der Sende-Socket-Puffer das Sendefenster direkt steuert und dass, gekoppelt mit dem Empfangsfenster von der anderen Seite, der Durchsatz gesteuert wird. Das angekündigte Empfangsfenster hat Platz, daher sind wir nicht auf den Empfänger beschränkt.

Halten Sie, was ist mit diesem Autotuning-Geschäft? Behandelt Windows 7 das Zeug nicht automatisch? Wie bereits erwähnt, behandelt Windows die automatische Skalierung des Empfangsfensters, kann aber auch dynamisch den Sendepuffer verarbeiten. Gehen wir zurück zur MSDN-Seite:

Dynamische Sendepufferung für TCP wurde unter Windows 7 und Windows hinzugefügt   Server 2008 R2. Standardmäßig ist die dynamische Sendepufferung für TCP aktiviert   es sei denn, eine Anwendung legt die SO_SNDBUF-Socket-Option für den Stream fest   Steckdose.

iperf verwendet SO_SNDBUF bei der Verwendung der -w Option, so dass dynamische Sendepufferung deaktiviert wäre. Wenn Sie jedoch nicht verwenden -w dann benutzt es nicht SO_SNDBUF. Die dynamische Sendepufferung sollte standardmäßig aktiviert sein. Sie können jedoch Folgendes überprüfen:

netsh winsock show autotuning

Die Dokumentation besagt, dass Sie sie deaktivieren können mit:

netsh winsock set autotuning off

Aber das hat nicht für mich funktioniert. Ich musste eine Registrierungsänderung vornehmen und diese auf 0 setzen:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DynamicSendBufferDisable

Ich glaube nicht, dass das zu verhindern, hilft; es ist nur ein FYI.

Warum skaliert der Sendepuffer beim Senden von Daten an eine Linux-Box mit viel Platz im Empfangsfenster nicht über die Standardwerte von 64 KB? Große Frage. Linux-Kernel haben auch einen Autotuning-TCP-Stack. Wenn T-Pain und Kanye ein Autotun-Duett zusammen machen, klingt es vielleicht nicht gut. Vielleicht gibt es ein Problem mit diesen beiden Autotuning-TCP-Stacks, die miteinander sprechen.

Eine andere Person hatte ein Problem genau wie Ihres und war in der Lage, es mit einer Registry-Bearbeitung zu beheben, um die Standard-Sendepuffergröße zu erhöhen. Leider scheint das nicht mehr zu funktionieren, zumindest hat es nicht für mich geklappt, als ich es ausprobiert habe.

An dieser Stelle denke ich, es ist klar, dass der begrenzende Faktor die Sendepuffergröße auf dem Windows-Host ist. Angesichts der Tatsache, dass es nicht dynamisch zu wachsen scheint, was soll ein Mädchen tun?

Sie können:

  • Verwenden Sie Anwendungen, mit denen Sie die Sendepuffer, d. H. Fensteroption festlegen können
  • Verwenden Sie einen lokalen Linux-Proxy
  • Verwenden Sie einen Remote-Windows-Proxy?
  • Öffne einen Fall mit Microsofhahahahahahaha
  • Bier

Disclaimer: Ich habe viele Stunden damit verbracht, dies zu recherchieren und es ist nach meinem besten Wissen und nach google-fu korrekt. Aber ich würde nicht auf das Grab meiner Mutter schwören (sie lebt noch).


5
2017-07-03 08:24



Fantasische Eingabe; Danke dir. Ich benutze iperf 2.0.4, ich experimentiere mit den Einstellungen und aktualisiere mein OP mit einigen neuen Caps. - SmallClanger
Ok, ich habe meine "Antwort" basierend auf mehr Forschung und Ihren letzten Tests aktualisiert - karyhead
Vielen Dank. Zumindest ist es schön zu wissen, dass ich nicht nur verrückt werde. Ich habe ein paar Blogs / Threads aus den XP / 2003 Tagen gelesen, die diese Registrierungseinstellungen empfehlen, aber sie wurden vor Vista / 2008 geschrieben und ich bin mir ziemlich sicher, dass sie ab Vista ignoriert werden. Ich denke, ich werde tatsächlich eine Fahrkarte mit MS darüber erheben (wünsche mir Glück) - SmallClanger
Ein nützliches Tool, auf das ich bei meinen Recherchen gestoßen bin, war tcpanalyzer.exe im SDK (microsoft.com/en-us/download/details.aspx?id=8279). Es ist ein grafischer Netstat, dass Sie eine einzelne Verbindung auswählen und die TCP-Stats wie RTT, Cwnd, Retransmissions usw. erhalten können. Ich könnte die CWND weit über die Sendepuffergröße hinaus öffnen, aber der Tput stieg nicht und wireshark verifiziert dass es immer noch send buffer limited ist. - karyhead
Ich habe in mehreren Foren Kommentare zu "netsh" -Befehlen gefunden, die nicht so funktionieren, wie in 7/8 angekündigt, und Leute, die gezwungen sind, die entsprechenden Registrierungseinträge manuell einzugeben; Ich frage mich, ob so etwas mit der CTCP-Option passieren könnte. - Pat


Sobald Sie den TCP-Stack optimiert haben, haben Sie möglicherweise noch einen Engpass in der Winsock-Ebene. Ich habe festgestellt, dass die Konfiguration von Winsock (Zusatzfunktions-Treiber in der Registrierung) einen großen Unterschied macht für Upload-Geschwindigkeiten (Push-Daten auf den Server) in Windows 7. Microsoft hat einen Fehler in der TCP-Autotuning für nicht blockierende Sockets anerkannt Art der Steckdose, die Browser benutzen ;-)

Fügen Sie DWORD-Schlüssel für DefaultSendWindow hinzu, und legen Sie es auf dem BDP oder höher fest. Ich benutze 256000.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters\DefaultSendWindow

Möglicherweise hilft das Ändern der Winsock-Einstellung für Downloads - fügen Sie einen Schlüssel für DefaultReceiveWindow hinzu.

Sie können mit verschiedenen Einstellungen für die Socket-Ebene experimentieren, indem Sie die Taste drücken Geiger Proxy und Befehle zum Anpassen der Client- und Server-Socket-Puffergrößen:

prefs set fiddler.network.sockets.Server_SO_SNDBUF 65536 

fiddler.network.sockets.Client_SO_SNDBUF
fiddler.network.sockets.Client_SO_RCVBUF
fiddler.network.sockets.Server_SO_SNDBUF
fiddler.network.sockets.Server_SO_RCVBUF

4
2018-04-23 21:02



Tolles zusätzliches bisschen Information. Haben Sie zufällig eine Referenzverbindung für den MS-Fehler? - SmallClanger


Nachdem ich alle Analysen in den Antworten gelesen habe, klingt dieses Problem sehr nach Windows7 / 2008R2 alias Windows 6.1

Der Netzwerk-Stack (TCP / IP & Winsock) in Windows 6.1 war entsetzlich fehlerhaft und wies eine ganze Reihe von Bugs und Performance-Problemen auf, die Microsoft schließlich über viele Jahre Hotfixing seit der ersten Veröffentlichung von 6.1 behoben hatte.

Der beste Weg, diese Hotfixes anzuwenden, besteht darin, manuell alle relevanten Seiten auf support.microsoft.com zu durchsuchen und die LDR-Versionen der Netzwerkstapel-Hotfixes manuell anzufordern und herunterzuladen (es gibt viele Dutzende davon).

Um die relevanten Hotfixes zu finden, müssen Sie www.bing.com mit der folgenden Suchanfrage verwenden site:support.microsoft.com 6.1.7601 tcpip.sys

Sie müssen auch verstehen, wie LDR / DDR-Hotfix-Züge in Windows 6.1 funktionieren

Im Allgemeinen pflegte ich meine eigene Liste von LDR-Fixes (nicht nur Netzwerkstack-Fixes) für Windows 6.1 und führte diese Fixes dann proaktiv auf jedem Windows 6.1-Server / Client durch, auf den ich stieß. Es war eine sehr zeitaufwendige Aufgabe, regelmäßig nach neuen LDR-Hotfixes zu suchen.

Glücklicherweise hat Microsoft die Verwendung von LDR-Hotfixes mit neueren Betriebssystemversionen gestoppt und Bugfixes sind nun über automatische Update-Dienste von Microsoft verfügbar.

AKTUALISIEREN: Nur ein Beispiel für viele Netzwerkfehler in Windows7SP1 - https://support.microsoft.com/en-us/kb/2675785

UPDATE 2: Hier ist ein weiterer Hotfix, der einen netsh-Schalter hinzufügt, um die Window-Skalierung nach der zweiten Neuübertragung eines SYN-Pakets zu erzwingen (standardmäßig wird die Fensterskalierung deaktiviert, nachdem 2 SYN-Pakete erneut übertragen wurden) https://support.microsoft.com/en-us/kb/2780879


3
2018-06-06 12:34



Danke Christoph; einige sehr interessante neue Eingabe dazu und dass SYN-Retransmission "Feature" ist sehr seltsam; Ich kann das Designziel dahinter nicht sehen. (Irgendeine Art von grober Verstopfungserkennung, vielleicht?). Alle ursprünglichen Tests wurden auf Win7SP1 durchgeführt; Wir werden bald Win10 testen, und es liegt an mir, viel davon neu zu testen, um zu sehen, wie es läuft. - SmallClanger
In welchem ​​Zweig von Windows 10 werden Sie testen? Ich habe noch keine Erfahrung mit dem Netzwerkstack in Windows 10. - Christoph Wegener
Auf Enterprise 1511 zielen wir ab. - SmallClanger
Aha. Es ist ziemlich schwierig, sich für einen Zweig mit Windows 10 zu entscheiden, da es so viele gibt. Ich bin bereits auf ein Problem mit Windows 10 gestoßen, wo ich eine bestimmte Funktion nicht nutzen konnte, weil ich in einem LTSB-Zweig war. Ich wünschte, Microsoft hätte die Anzahl der verfügbaren Zweige insgesamt reduziert und stattdessen ihre Dokumentation darüber verbessert, welche Fixes und Funktionen in jedem Build enthalten sind .... - Christoph Wegener


Ich sehe, das ist ein bisschen älter, aber es könnte anderen helfen.

Kurz gesagt, Sie müssen "Auto-Tuning für Fenster empfangen" aktivieren:

netsh int tcp set global autotuninglevel=normal

CTCP bedeutet nichts ohne oben aktiviert.

Wenn Sie "Auto-Tuning für Fenster empfangen" deaktivieren, werden Sie bei einer Paketgröße von 64 KB feststecken, was sich bei langen Breitbandverbindungen negativ auf lange RTTs auswirkt. Sie können auch mit der Option "eingeschränkt" und "sehr eingeschränkt" experimentieren.

Sehr gute Referenz: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html


1
2018-02-23 15:51





Ich hatte ein ähnliches Problem mit Windows-Clients (Windows 7). Ich ging durch das meiste Debugging, das Sie durchgemacht haben, den Nagle-Algorithmus, TCP Chimney Offloading und Tonnen von anderen TCP-bezogenen Einstellungsänderungen deaktiviert. Keine von ihnen hatte irgendeine Wirkung.

Was es schließlich für mich behob, war das Ändern des Standard-Sendefensters in der Registrierung des AFD-Dienstes. Das Problem scheint mit der Datei afd.sys in Zusammenhang zu stehen. Ich testete mehrere Clients, einige zeigten den langsamen Upload, andere nicht, aber alle waren Windows 7-Rechner. Maschinen, die das langsame Verhalten zeigten, hatten die gleiche Version AFD.sys. Die Problemumgehung für die Registrierung ist für Computer mit bestimmten Versionen von AFD.sys erforderlich (die Version # wird nicht zurückgerufen).

HKLM \ CurrentControlSet \ Services \ AFD \ Parameter

Hinzufügen - DWORD - DefaultSendWindow

Wert - Dezimal - 1640960

Dieser Wert ist etwas, was ich hier gefunden habe: https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-

Ich denke, um den richtigen Wert zu verwenden, sollten Sie es selbst berechnen mit:

z.B. Angekündigter Upload: 15 Mbps = 15.000 Kbps

(15000/8) * 1024 = 1920000

Soweit ich weiß, sollte Client-Software diese Einstellung in der Registrierung im Allgemeinen überschreiben, aber wenn dies nicht der Fall ist, wird der Standardwert verwendet, und anscheinend ist der Standardwert in einigen Versionen der Datei AFD.sys sehr niedrig.

Ich bemerkte, dass MS-Produkte hauptsächlich das langsame Upload-Problem hatten (IE, Mini-Redirector (WebDAV), FTP über Windows Explorer, etc ...) Bei Verwendung von Software von Drittanbietern (z. B. Filezilla) hatte ich nicht die gleichen Verzögerungen .

Die AFD.sys wirkt sich auf alle Winsock-Verbindungen aus, daher sollte dieser Fix für FTP, HTTP, HTTPS usw. gelten.

Dieser Fix wurde oben auch irgendwo aufgelistet, also möchte ich das nicht gut genug machen, wenn es für irgendjemanden funktioniert, aber es gab so viele Informationen in diesem Thread, dass ich befürchtete, dass es beschönigt worden wäre.


1
2017-07-16 20:11





Nun, ich bin selbst in eine ähnliche Situation geraten (meine Frage Hier), und am Ende musste ich TCP-Skalierungsheuristiken deaktivieren, manuell das Autotuning-Profil einstellen und CTCP aktivieren:

# disable heuristics
C:\Windows\system32>netsh interface tcp set heuristics wsh=disabled
Ok.

# enable receive-side scaling
C:\Windows\system32>netsh int tcp set global rss=enabled
Ok.

# manually set autotuning profile
C:\Windows\system32>netsh interface tcp set global autotuning=experimental
Ok. 

# set congestion provider
C:\Windows\system32>netsh interface tcp set global congestionprovider=ctcp
Ok. 

0
2018-02-02 23:28





Ich habe nicht genug Punkte, um etwas zu kommentieren, also poste ich stattdessen eine "Antwort". Ich habe anscheinend ein ähnliches / identisches Problem (siehe Serverdefault-Frage) Hier). Mein (und wahrscheinlich Ihr) Problem ist der Sendepuffer des iperf-Clients unter Windows. Es wird nicht größer als 64 KB. Windows soll den Puffer dynamisch vergrößern, wenn er vom Prozess nicht explizit skaliert wird. Aber dieses dynamische Wachstum findet nicht statt.

Ich bin mir nicht sicher über Ihr Fenster Skalierungsdiagramm, das das Fenster öffnet bis zu 500.000 Bytes für Ihren "langsamen" Windows-Fall zeigt. Ich habe erwartet, dass dieser Graph nur für ~ 64.000 Bytes geöffnet ist, da Sie auf 5 Mbps beschränkt sind.


0
2017-08-24 23:22





Dies ist ein faszinierender Thread und entspricht genau den Problemen, die ich mit Win7 / iperf hatte, um den Durchsatz auf langen fetten Pfeifen zu testen.

Die Lösung für Windows 7 besteht darin, den folgenden Befehl sowohl auf dem iperf-Server als auch auf dem Client auszuführen.

netsh interface tcp set global autotuninglevel = experimentell

Hinweis: Bevor Sie dies tun, notieren Sie sich den aktuellen Status des Autotunings:

Netsh-Schnittstelle tcp zeigen global

Fenster-Auto-Tuning Level empfangen: deaktiviert

Führen Sie dann den iperf-Server / -Client an jedem Ende der Pipe aus.

Setzen Sie den Autotuning-Wert nach Ihren Tests zurück:

netsh interface tcp set global autotuninglevel =

   autotuninglevel - One of the following values:
                     disabled: Fix the receive window at its default
                         value.
                     highlyrestricted: Allow the receive window to
                         grow beyond its default value, but do so
                         very conservatively.
                     restricted: Allow the receive window to grow
                         beyond its default value, but limit such
                         growth in some scenarios.
                     normal: Allow the receive window to grow to
                         accomodate almost all scenarios.
                     experimental: Allow the receive window to grow
                         to accomodate extreme scenarios.

0
2017-12-23 10:44