Vraag Windows TCP Window Scaling Plateau te vroeg raken


Scenario: We hebben een aantal Windows-clients die regelmatig grote bestanden uploaden (FTP / SVN / HTTP PUT / SCP) naar Linux-servers die ~ 100-160 ms verwijderd zijn. We hebben 1Gbit / s synchrone bandbreedte op kantoor en de servers zijn AWS-instanties of worden fysiek gehost in Amerikaanse DC's.

Het eerste rapport was dat het uploaden naar een nieuw serverexemplaar veel langzamer ging dan mogelijk was. Dit droeg bij aan testen en vanuit meerdere locaties; clients zagen stabiele 2-5Mbit / s naar de host vanuit hun Windows-systemen.

Ik brak uit iperf -s op een AWS-instantie en vervolgens van een ramen klant op kantoor:

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

Het laatste cijfer kan aanzienlijk variëren bij volgende tests (Vagaries of AWS), maar ligt meestal tussen 70 en 130 Mbit / s, wat meer dan voldoende is voor onze behoeften. Terwijl ik de sessie afwacht, zie ik:

  • iperf -c Windows SYN - Window 64kb, Scale 1 - Linux SYN, ACK: Window 14kb, Scale: 9 (* 512) iperf window scaling with default 64kb Window
  • iperf -c -w1M Windows SYN - Windows 64kb, schaal 1 - Linux SYN, ACK: venster 14kb, schaal: 9 iperf window scaling with default 1MB Window

Het is duidelijk dat de link deze hoge doorvoer kan ondersteunen, maar ik moet expliciet de venstergrootte instellen om er enig gebruik van te maken, wat de meeste toepassingen in de echte wereld me niet zullen laten doen. De TCP-handshakes gebruiken in elk geval dezelfde startpunten, maar de gedwongen hand schalen

Omgekeerd, van een Linux-client op hetzelfde netwerk een straight, iperf -c (met behulp van de standaardinstelling 85kb) geeft me:

[  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

Zonder enige dwang schaalt het zoals verwacht. Dit kan niet iets zijn in de tussenliggende hops of onze lokale switches / routers en lijkt zowel Windows 7 als 8 clients te beïnvloeden. Ik heb veel handleidingen over auto-tuning gelezen, maar deze gaan meestal over het volledig uitschakelen van scaling om rond een slechte pc-kit voor thuisnetwerken te werken.

Kan iemand me vertellen wat hier gebeurt en me een manier geven om het te repareren? (Bij voorkeur kan ik via GPO bij de registry blijven.)

Notes

Het betreffende AWS Linux-subsysteem heeft de volgende kernelinstellingen toegepast in 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

Ik heb gebruikt dd if=/dev/zero | nc omleiden naar /dev/null aan het servereinde om uit te sluiten iperf en verwijder eventuele andere knelpunten, maar de resultaten zijn vrijwel hetzelfde. Proeven met ncftp (Cygwin, Native Windows, Linux) schaal op vrijwel dezelfde manier als de bovenstaande iperf-tests op hun respectieve platforms.

Bewerk

Ik heb hier nog een ander consistent ding gezien dat relevant zou kunnen zijn: enter image description here

Dit is de eerste seconde van de opname van 1 MB, ingezoomd. U kunt zien Langzame start in actie als het venster opschaalt en de buffer groter wordt. Er is dan een heel klein plateau van ~ 0.2s precies op het punt dat de standaard venster-iperf-test voor altijd afvlakt. Deze schalen worden natuurlijk veel duizeliger, maar het is merkwaardig dat er een pauze is in de schaal (Waarden zijn 1022bytes * 512 = 523264) voordat het dit doet.

Update - 30 juni.

Volgen van de verschillende antwoorden:

  • CTCP inschakelen - Dit maakt geen verschil; het schalen van vensters is identiek. (Als ik dit goed begrijp, verhoogt deze instelling de snelheid waarmee het congestievenster wordt vergroot in plaats van de maximale grootte die het kan bereiken)
  • TCP-tijdstempels inschakelen. - Ook hier geen verandering.
  • Het algoritme van Nagle - dat is logisch en het betekent tenminste dat ik die specifieke blips in de grafiek waarschijnlijk kan negeren als een indicatie van het probleem.
  • pcap-bestanden: zip-bestand hier beschikbaar: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (Anonymised with bittwiste, extracts to ~ 150MB aangezien er voor elke OS-client een vergelijking mogelijk is)

Update 2 - 30 juni

O, dus op voorstel van Kyle volgde ik ctcp en uitgeschakeld ontladen van schoorstenen: TCP globale parameters

----------------------------------------------
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

Maar helaas, geen verandering in de doorvoer.

Ik heb hier wel een oorzaak / gevolg-vraag: de grafieken zijn van de RWIN-waarde die is ingesteld in de ACK's van de server voor de client. Denk ik er bij Windows-clients aan dat Linux deze waarde niet verder schaalt dan dat dieptepunt, omdat de beperkte CWIN van de klant zelfs voorkomt dat die buffer wordt gevuld? Kan er een andere reden zijn dat Linux de RWIN kunstmatig beperkt?

Opmerking: ik heb geprobeerd ECN voor de gek te houden; maar geen verandering, daar.

Update 3 - 31 juni.

Geen verandering na uitschakelen van heuristieken en RWIN autotuning. Heb de Intel netwerkdrivers bijgewerkt naar de nieuwste (12.10.28.0) met software die functioanlity tweaks viadevice manager tabbladen blootstelt. De kaart is een 82579V Chipset on-board NIC - (ik ga nog meer testen van klanten met realtek of andere leveranciers)

Ik concentreerde me even op de NIC en heb het volgende geprobeerd (meestal uitsluiten ze onwaarschijnlijke boosdoeners):

  • Verhoog ontvangstbuffers naar 2k vanaf 256 en verzend buffers naar 2k vanaf 512 (beide nu maximaal) - Geen verandering
  • Uitgeschakeld alle IP / TCP / UDP controlesom offloading. - Geen verandering.
  • Uitgeschakeld Large Send Offload - Nada.
  • IPv6, QoS-planning uitgeschakeld - Nowt.

Update 3 - 3 juli

Ik probeerde de Linux-server te elimineren, ik startte een Server 2012R2-instantie en herhaalde de tests met iperf (cygwin binary) en NTttcp.

Met iperf, Ik moest expliciet aangeven -w1m op beide kanten voordat de verbinding groter zou worden dan ~ 5Mbit / s. (Overigens, ik zou kunnen worden gecontroleerd en de BDP van ~ 5Mbit met een latentie van 91ms is bijna precies 64kb. Zoek de limiet ...)

De ntttcp binaries toonden nu een dergelijke beperking. Gebruik makend van ntttcpr -m 1,0,1.2.3.5 op de server en ntttcp -s -m 1,0,1.2.3.5 -t 10 op de client kan ik een veel betere doorvoer zien:

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 zet het op de niveaus die ik kreeg met expliciet grote vensters erin iperf. Vreemd genoeg echter 80 MB in 1273 buffers = een buffer van 64 kB. Een verdere draadschors toont een goede, variabele RWIN die terugkomt van de server (schaalfactor 256) die de cliënt lijkt te vervullen; dus misschien is ntttc het verzendvenster verkeerd aan het rapporteren.

Update 4 - 3 juli

Op verzoek van @karyhead heb ik wat meer tests gedaan en nog een aantal extra foto's gemaakt, hier: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip

  • Nog twee iperfs, beide van Windows naar dezelfde Linux-server als hiervoor (1.2.3.4): een met een 128k Socket-grootte en een standaard 64k-venster (beperkt tot ~ 5Mbit / s opnieuw) en een met een 1MB verzendvenster en standaard 8 kb-socketgrootte. (schalen hoger)
  • een ntttcp traceren van dezelfde Windows-client naar een Server 2012 R2 EC2-instantie (1.2.3.5). hier schaalt de doorvoer goed. Opmerking: NTttcp doet iets vreemds op poort 6001 voordat het de testverbinding opent. Ik weet niet zeker wat daar gebeurt.
  • Eén FTP-gegevenstracering, uploadt 20 MB van /dev/urandom naar een vrijwel identieke linux-host (1.2.3.6) met behulp van Cygwin ncftp. Nogmaals, de limiet is er. Het patroon is grotendeels hetzelfde met Windows Filezilla.

De. Wijzigen iperf bufferlengte maakt wel het verwachte verschil met de tijdreeksgrafiek (veel meer verticale secties), maar de daadwerkelijke doorvoer is ongewijzigd.


50
2018-06-26 09:31


oorsprong


Een zeldzaam voorbeeld van een goed onderzocht probleem dat niet duidelijk in de documentatie staat. Leuk - laten we hopen dat iemand een oplossing vindt (omdat ik op de een of andere manier denk dat ik dat ook kan gebruiken). - TomTom
Probeer RFC 1323-tijdstempels in te schakelen, omdat deze standaard zijn uitgeschakeld in Windows, terwijl Linux deze standaard heeft ingeschakeld). netsh int tcp set global timestamps=enabled - Brian
De vertraging van 200 ms is waarschijnlijk het Nagle-algoritme in actie. Omdat TCP gegevens ontvangt over een bepaalde verbinding, verzendt deze alleen een bevestiging als een van de volgende voorwaarden waar is: Er is geen bevestiging verzonden voor het vorige ontvangen segment; Een segment wordt ontvangen, maar geen ander segment arriveert binnen 200 milliseconden voor die verbinding. - Greg Askew
Is er een kans om ergens packet-opnamen van een van de langzamere afzenders op te slaan? - Kyle Brandt♦
Ik heb mijn OP bijgewerkt met de resultaten van deze tests en koppelingen naar representatieve capture-bestanden. - SmallClanger


antwoorden:


Heb je geprobeerd te activeren Verbinding TCP (CTCP) in uw Windows 7/8 clients.

Gelieve te lezen:

Prestaties van zenderzijde verhogen voor verzending met hoge BDP

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

...

Deze algoritmen werken goed voor kleine BDP's en kleiner ontvangvenster   maten. Wanneer u echter een TCP-verbinding hebt met een grote ontvangst   venstergrootte en a grote BDP, zoals het repliceren van gegevens tussen twee   servers die zich op hoge snelheid bevinden WAN-koppeling met een rondreis van 100ms   tijd, deze algoritmen verhoog het verzendvenster niet snel genoeg om   maak volledig gebruik van de bandbreedte van de verbinding.

Om de bandbreedte van TCP-verbindingen hierin beter te gebruiken   situaties, bevat de TCP / IP-stapel van de volgende generatie Compound TCP   (CTCP). CTCP verhoogt agressiever het verzendvenster voor verbindingen met grote ontvangstvensterformaten en BDP's. CTCP probeert dit te doen   maximale doorvoer van dit soort verbindingen door het bewaken van de vertraging   variaties en verliezen. Bovendien zorgt CTCP voor zijn gedrag   heeft geen negatieve invloed op andere TCP-verbindingen.

...

CTCP is standaard ingeschakeld op computers met Windows Server 2008 die zijn uitgeschakeld door   standaard op computers met Windows Vista. U kunt CTCP inschakelen met de netsh interface tcp set global congestionprovider=ctcp commando. U kunt CTCP uitschakelen met   de netsh interface tcp set global congestionprovider=none commando.

Bewerk 30-06-2014

om te zien of CTCP echt "aan" is

> netsh int tcp show global

d.w.z.

enter image description here

PO zei:

Als ik dit goed begrijp, verhoogt deze instelling de snelheid om waarin het congestievenster vergroot wordt in plaats van de maximale grootte het kan bereiken

CTCP verhoogt agressief het verzendvenster

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

Verbinding TCP

De bestaande algoritmen die voorkomen dat een TCP-peer wordt verzonden   overweldigend het netwerk staan ​​bekend als trage start en congestie   vermijden. Deze algoritmen verhogen het aantal segmenten dat de   afzender kan verzenden, ook wel het verzendvenster genoemd, bij het in eerste instantie verzenden van gegevens   op de verbinding en bij het herstellen van een verloren segment. Langzame start   verhoogt het verzendvenster met één volledig TCP-segment voor elk van beide   bevestigingssegment ontvangen (voor TCP in Windows XP en Windows   Server 2003) of voor elk erkend segment (voor TCP in Windows   Vista en Windows Server 2008). Congestion avoidance verhoogt de   verzend venster per volledig TCP-segment voor elk volledig gegevensvenster dat   is erkend.

Deze algoritmen werken goed voor LAN-mediasnelheden en een kleiner TCP-venster   maten. Wanneer u echter een TCP-verbinding hebt met een grote ontvangst   venstergrootte en een groot bandbreedte-vertragingsproduct (hoge bandbreedte en   hoge vertraging), zoals het repliceren van gegevens tussen twee servers   via een snelle WAN-link met een retourtijd van 100 ms, deze   algoritmen vergroten het verzendvenster niet snel genoeg tot volledig   gebruik de bandbreedte van de verbinding. Bijvoorbeeld op een 1 Gigabit   per seconde (Gbps) WAN-koppeling met een round-time van 100 ms (RTT), het kan het duurt maximaal een uur voordat het verzendvenster in eerste instantie is gestegen naar de grote venstergrootte geadverteerd door de ontvanger en om te herstellen wanneer er zijn verloren segmenten.

Om de bandbreedte beter te benutten van TCP-verbindingen hierin   situaties bevat de TCP / IP-stack van de volgende generatie Verbinding TCP   (CTCP). CTCP verhoogt agressiever het verzendvenster voor   verbindingen met grote ontvangstvensterformaten en grote bandbreedtevertraging   producten. CTCP probeert de doorvoer op dit soort apparaten te maximaliseren   verbindingen door bewaking vertragingsvariaties en verliezen. CTCP ook   zorgt ervoor dat zijn gedrag geen negatieve invloed heeft op andere TCP   verbindingen.

Bij intern uitgevoerde tests bij Microsoft, grote back-uptijden voor bestanden   werden bijna gehalveerd voor een 1 Gbps-verbinding met een 50 ms RTT.   Verbindingen met een groter bandbreedtevertragingsproduct kunnen nog beter zijn   prestatie. CTCP en Receive Window Auto-Tuning werken samen voor   verhoogd linkgebruik en kan resulteren in aanzienlijke prestaties   winst voor grote bandbreedtevertragingsproductverbindingen.


15
2018-06-29 10:03



Net als een aanvulling op dit antwoord is het Powershell-equivalent in Server 2012 / Win8.1 dat ook Set-NetTCPSetting met de -CongestionProvider parameter ... die CCTP, DCTCP en standaard accepteert. Windows-client en -servers gebruiken verschillende standaard congestion providers. technet.microsoft.com/en-us/library/hh826132.aspx - Ryan Ries
Ik zie waar je aan begint, maar het lijkt niet van toepassing. Voor het doel heb ik 30 minuten gelopen iperf en het venster is nog nooit verder geschaald dan ~ 520kb. Iets anders beperkt de CWND voordat dit agressieve algoritme voordelen kan opleveren. - SmallClanger
er is een oude (reeds vaste) Vista-bug die dit soort problemen presenteerde bij het verzenden van niet-HTML-protocollen. Ziet uw probleem er exact hetzelfde uit bij het overbrengen van hetzelfde bestand op HTML of laten we zeggen via FTP? - Pat
@Pat - het doet. SVN Commits (via HTTP en HTTPS) en FTP-overdrachten naar een ander systeem op AWS vertonen ook dezelfde limieten. - SmallClanger
hoe zit het met de firewall van Win-client? kan je volledig testen met de firewall? kijk hier: ask.wireshark.org/questions/2365/tcp-window-size-and-scaling - Pat


Het probleem verduidelijken:

TCP heeft twee vensters:

  • Het ontvangstvenster: Hoeveel bytes er nog in de buffer zitten. Dit is de stroomregeling die wordt opgelegd door de ontvanger. U kunt de grootte van het ontvangstvenster in de wireshark zien, aangezien deze bestaat uit de venstergrootte en de schaalfactor voor vensters binnen de TCP-header. Beide zijden van de TCP-verbinding maken reclame voor hun ontvangstvenster, maar over het algemeen geeft degene die u interesseert het grootste deel van de gegevens. In uw geval is dit de "server" sinds de client uploadt naar de server
  • Het congestievenster. Dit is flow control opgelegd door de verzender. Dit wordt onderhouden door het besturingssysteem en wordt niet weergegeven in de TCP-header. Het bepaalt de snelheid waarmee snelle gegevens worden verzonden.

In het capture-bestand dat je hebt opgegeven. We kunnen zien dat de ontvangstbuffer nooit overloopt:

enter image description here

Mijn analyse is dat de afzender niet snel genoeg verzendt omdat het verzendvenster (ook bekend als het congestiebesturingsvenster) niet voldoende openstaat om te voldoen aan de RWIN van de ontvanger. Dus in het kort zegt de ontvanger "Give me More", en wanneer Windows de afzender is, wordt het niet snel genoeg verzonden.

Dit blijkt uit het feit dat in de bovenstaande grafiek de RWIN open blijft en met de round trip-tijd van .09 seconden en een RWIN van ~ 500.000 bytes kunnen we een max. Doorvoer verwachten volgens het bandbreedte-vertragingsproduct (500000) /0.09) * 8 = ~ 42 Mbit / s (en je krijgt maar ongeveer ~ 5 in je winst naar Linux capture).

Hoe repareer je het?

Ik weet het niet. interface tcp set global congestionprovider=ctcp klinkt als het juiste ding om me te doen omdat het het verzendvenster zou vergroten (wat een andere term is voor het congestie venster). U zei dat het niet werkt. Dus gewoon om zeker te zijn:

  1. Ben je opnieuw opgestart nadat je dit hebt ingeschakeld?
  2. Wordt schoorsteen opgeladen? Als het misschien is, probeer het dan als experiment uit te schakelen. Ik weet niet wat er precies wordt afgeladen wanneer dit wordt ingeschakeld, maar als het besturen van het verzendvenster een van deze is, heeft congestionprovider mogelijk geen effect wanneer dit is ingeschakeld ... Ik gok alleen maar ...
  3. Ik denk ook dat dit pre-windows 7 zou kunnen zijn, maar je zou kunnen proberen om toe te voegen en te spelen met de twee registersleutels DefaultSendWindow en DefaultReceiveWindow in HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD-Parameters. Als deze zelfs werken, is het waarschijnlijk dat er ctcp is uitgeschakeld.
  4. Nog een gok, probeer eens uit te checken netsh interface tcp show heuristics. Ik denk dat dat misschien RWIN is, maar dat staat er niet in, dus speel het misschien met uitschakelen of inschakelen als het invloed heeft op het verzendvenster.
  5. Zorg er ook voor dat uw stuurprogramma's up-to-date zijn op uw testclient. Misschien is er gewoon iets gebroken.

Ik zou al deze experimenten willen proberen met alles wat je offloading-functies uitzet om te beginnen met het elimineren van de mogelijkheid dat de netwerkdrivers sommige dingen herschrijven / wijzigen (houd de CPU in de gaten terwijl offloading is uitgeschakeld). De TCP_OFFLOAD_STATE_DELEGATED struct lijkt op zijn minst te impliceren dat CWnd-verlading op zijn minst mogelijk is.


12
2018-06-30 15:11



Ik heb je "antwoord" gerapporteerd omdat het jouwe geen antwoord is; Ik werd meteen verslagen; nu zie ik hoe "mensen" op jouw "nee-antwoord" stemmen ... echt grappig - Pat
@Pat: u kunt op het aantal stemmen klikken om het overzicht van Upvotes / Downvotes te zien. Momenteel heb je geen downvotes op je antwoord. Mijn antwoord lost zijn probleem niet op (maar nog geen antwoord), het verklaart en lokaliseert het probleem (hopelijk correct!) Wat een belangrijke stap is in het oplossen van problemen. - Kyle Brandt♦
@ Kyle Brandt als je de jouwe accepteert is geen antwoord Ik vraag me af waarom het niet "automatisch" wordt verwijderd zonder verdere overweging ?? en je hebt ongelijk; Ik heb een lagere stem gekregen (unupvote) "zo snel" als ik je "antwoord" heb gemeld; die is nog niet verwijderd. Het lijkt erop dat je hier volgens "speciale" regels speelt. - Pat
@Pat Als het helpt, is Kyle's niet-antwoord ongelooflijk behulpzaam geweest. Ik heb nu een duidelijker idee van welke buffers worden beperkt en ik voel dat ik daardoor een beetje dichter bij een juiste oplossing ben. Soms kunnen vragen zoals deze een gezamenlijke inspanning zijn die met een beetje verstandige bewerking een goede kan worden Q en een goede EEN. - SmallClanger
@SmallClanger met alle respect, SF heeft een aantal regels die moeten worden opgevolgd door alle gebruikers, waaronder Kyle Brandt; als het geen antwoord is, moet het worden gewist of verplaatst als een opmerking, ongeacht hoeveel vrienden hij heeft in de "moderators" -club. - Pat


Er is hier geweldige informatie te vinden door @Pat en @Kyle. Let zeker op @ Kyle's uitleg van de TCP-vensters voor ontvangen en verzenden, denk ik dat daar enige verwarring over bestaat. Om de zaken verder te verwarren, gebruikt iperf de term "TCP-venster" met de -w instelling die een soort van ambigue term is met betrekking tot het ontvangen, verzenden of algehele schuifvenster. Wat het eigenlijk doet, is de socket send buffer voor de -c (client) instantie en de socket ontvangen buffer op de -s (server) instantie. In 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 ));
}

Zoals Kyle vermeldt, ligt het probleem niet bij het ontvangvenster op de Linux-box, maar de afzender opent het verzendvenster niet voldoende. Het gaat er niet om dat het niet snel genoeg open gaat, het pakt gewoon op 64.000.

De standaard grootte van de socketbuffer op Windows 7 is 64.000. Dit is wat de documentatie zegt over de grootte van de socketbuffer in relatie tot de doorvoer op MSDN

Bij het verzenden van gegevens via een TCP-verbinding met behulp van Windows-sockets, is het   belangrijk om een ​​voldoende hoeveelheid gegevens open te houden (verzonden maar   nog niet bevestigd) in TCP om het hoogste te bereiken   doorvoer. De ideale waarde voor de hoeveelheid gegevens die uitstaat   het bereiken van de beste doorvoer voor de TCP-verbinding wordt het ideaal genoemd   stuur achterstand (ISB) formaat. De ISB-waarde is een functie van de   bandbreedte-vertragingsproduct van de TCP-verbinding en die van de ontvanger   geadverteerde ontvangstvenster (en gedeeltelijk de hoeveelheid congestie in de   netwerk).

Ok, bla blabla, nu gaan we hier:

Toepassingen die een blokkerings- of niet-blokkerende verzendopdracht uitvoeren op   een tijd die doorgaans afhankelijk is van interne stuurbuffering door Winsock om te bereiken   fatsoenlijke doorvoer. De verzendbufferlimiet voor een bepaalde verbinding is   bestuurd door de socketoptie SO_SNDBUF. Voor de blokkering en   niet-blokkerende verzendmethode, de verzendbufferlimiet bepaalt hoeveel   gegevens blijven uitstekend in TCP. Als de ISB-waarde voor de verbinding   is groter dan de verzendbufferlimiet, dan wordt de doorvoer bereikt op   de verbinding zal niet optimaal zijn.

De gemiddelde doorvoer van uw meest recente iperf-test met behulp van het 64k-venster is 5,8 Mbps. Dat komt van Statistieken> Samenvatting in Wireshark, die alle stukjes telt. Waarschijnlijk telt iperf TCP-gegevensdoorvoer van 5,7 Mbps. We zien dezelfde prestaties ook met de FTP-test, ~ 5.6Mbps.

De theoretische doorvoer met een 64k verzendbuffer en 91ms RTT is .... 5.5Mbps. .

Als we kijken naar de iperf-test van het 1 MB-venster, is de tput 88,2 Mbps (86,2 Mbps voor alleen TCP-gegevens). De theoretische tput met een venster van 1 MB is 87,9 Mbps. Nogmaals, dichtbij genoeg voor overheidswerk.

Wat dit aantoont, is dat de send socket buffer direct het verzendvenster bestuurt en dat, in combinatie met het ontvangstvenster van de andere kant, de doorvoer regelt. Het geadverteerde ontvangstvenster heeft ruimte, dus we worden niet beperkt door de ontvanger.

Wacht even, hoe zit het met deze autotuning-activiteiten? Ondersteunt Windows 7 dat spul niet automatisch? Zoals eerder is vermeld, is Windows wel geschikt voor het automatisch schalen van het ontvangstvenster, maar kan het ook de verzendbuffer dynamisch verwerken. Laten we teruggaan naar de MSDN-pagina:

Dynamische verzendbuffering voor TCP is toegevoegd in Windows 7 en Windows   Server 2008 R2. Standaard is dynamische verzendbuffering voor TCP ingeschakeld   tenzij een toepassing de SO_SNDBUF-socketoptie op de stream instelt   socket.

iperf gebruikt SO_SNDBUF bij gebruik van de -w optie, dus dynamische verzendbuffering zou worden uitgeschakeld. Als u het echter niet gebruikt -w dan gebruikt het niet SO_SNDBUF. Dynamische verzendbuffering moet standaard zijn ingeschakeld, maar u kunt het volgende controleren:

netsh winsock show autotuning

De documentatie zegt dat je het kunt uitschakelen met:

netsh winsock set autotuning off

Maar dat werkte niet voor mij. Ik moest een registerwijziging aanbrengen en dit op 0 zetten:

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

Ik denk niet dat het onmogelijk zal zijn om dit uit te schakelen; het is maar een FYI.

Waarom verschuift de verzendbuffer niet boven de standaard 64k wanneer er gegevens worden verzonden naar een Linux-box met voldoende ruimte in het ontvangstvenster? Geweldige vraag. Linux-kernels hebben ook een autotuning-TCP-stack. Zoals T-Pain en Kanye samen een autotune-duet doen, klinkt het misschien niet goed. Misschien is er een probleem met die twee autotuning-TCP-stacks die met elkaar praten.

Een ander persoon had een probleem net zoals dat van jou en kon het repareren met een registerbewerking om de standaard verzendbuffergrootte te vergroten. Helaas lijkt dat niet meer te werken, althans niet toen ik het probeerde.

Op dit moment denk ik dat het duidelijk is dat de beperkende factor de verzendbuffergrootte op de Windows-host is. Gezien het feit dat het niet op een dynamische manier lijkt te groeien, wat moet een meisje dan doen?

Jij kan:

  • Toepassingen gebruiken waarmee u de verzendbuffer kunt instellen, bijvoorbeeld een vensteroptie
  • Gebruik een lokale Linux-proxy
  • Gebruik een externe Windows-proxy?
  • Open een zaak met Microsofhahahahahahaha
  • Bier

Disclaimer: ik heb vele uren besteed aan het onderzoeken van dit en het klopt naar mijn beste weten en google-fu. Maar ik zou niet zweren op het graf van mijn moeder (ze leeft nog steeds).


5
2017-07-03 08:24



Fantasieke input; dank je. Ik gebruik iperf 2.0.4, ik zal met de instellingen experimenteren en mijn OP bijwerken met een aantal nieuwe hoofdletters. - SmallClanger
Ok, ik heb mijn "antwoord" bijgewerkt op basis van meer onderzoek en uw recente tests - karyhead
Bedankt. Tenminste gedeeltelijk is het leuk om te weten dat ik niet alleen gek word. Ik heb een paar blogs / threads gelezen uit de XP / 2003-dagen die die registerinstellingen aanbeveelden, maar ze zijn geschreven voor Vista / 2008 en ik ben er vrij zeker van dat ze in Vista worden genegeerd. Ik denk dat ik hierover een kaartje ga opsturen met MS (wens me geluk) - SmallClanger
Een handig hulpmiddel dat ik tegenkwam in mijn onderzoek was tcpanalyzer.exe in de SDK (microsoft.com/en-us/download/details.aspx?id=8279). Het is een grafische netstat dat je een individuele verbinding kunt selecteren en de TCP-statistieken kunt krijgen zoals RTT, cwnd, hertransmissies, enz. Ik kon de cwnd openen tot ver buiten de verzendbuffergrootte, maar de tput nam niet toe en wireshark geverifieerd dat het nog steeds een beperkte buffer is. - karyhead
Ik heb opmerkingen gevonden op verschillende forums over "netsh" -opdrachten die niet werken zoals geadverteerd in 7/8, en mensen die gedwongen worden om handmatig de bijbehorende registervermeldingen in te voeren; Ik vraag me af of zoiets gebeurt met de CTCP-optie. - Pat


Zodra je de TCP-stack hebt afgestemd, kun je nog steeds een flessenhals in de Winsock-laag hebben. Ik heb geconstateerd dat het configureren van Winsock (Ancillary Function Driver in het register) een enorm verschil maakt voor uploadsnelheden (pushen van gegevens naar de server) in Windows 7. Microsoft heeft een bug erkend in de TCP autotuning voor niet-blokkerende sockets - alleen de soort socket dat browsers gebruiken ;-)

Voeg DWORD-sleutel toe voor DefaultSendWindow en stel deze in op BDP of hoger. Ik gebruik 256000.

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

Het wijzigen van de Winsock-instelling voor downloads kan helpen - voeg een sleutel toe voor DefaultReceiveWindow.

U kunt experimenteren met verschillende socketniveau-instellingen met behulp van de vioolspeler Proxy en opdrachten om de buffergrootte van de client en server socket aan te passen:

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



Geweldig bijkomend beetje informatie. Heb je toevallig een referentielink voor de MS-bug? - SmallClanger


Na het lezen van alle analyses in de antwoorden, lijkt dit probleem heel erg op dat je misschien Windows7 / 2008R2 alias Windows 6.1 gebruikt

De netwerkstack (TCP / IP en Winsock) in Windows 6.1 was vreselijk gebrekkig en had een hele reeks bugs en prestatieproblemen die Microsoft uiteindelijk gedurende vele jaren van hotfixing behandelde sinds de eerste release van 6.1.

De beste manier om deze hotfixes toe te passen, is handmatig door alle relevante pagina's op support.microsoft.com te bladeren en de LDR-versies van de hotfixes voor netwerkstacks handmatig aan te vragen en te downloaden (er zijn er vele tientallen).

Om de relevante hotfixes te vinden, moet u www.bing.com gebruiken met de volgende zoekopdracht site:support.microsoft.com 6.1.7601 tcpip.sys

U moet ook begrijpen hoe LDR / GDR-hotfix-treinen werken in Windows 6.1

In het algemeen gebruikte ik om mijn eigen lijst met LDR-fixes (niet alleen netwerk stack-fixes) voor Windows 6.1 te onderhouden en paste ik deze fixes vervolgens proactief toe op elke Windows 6.1-server / client die ik tegenkwam. Het was een zeer tijdrovende taak om regelmatig te controleren op nieuwe LDR-hotfixes.

Gelukkig is Microsoft gestopt met het oefenen van LDR-hotfixes met nieuwere OS-versies en zijn nu bugfixes beschikbaar via automatische updateservices van Microsoft.

BIJWERKEN: Eén voorbeeld van veel netwerkproblemen in Windows7SP1 - https://support.microsoft.com/en-us/kb/2675785

UPDATE 2: Hier is nog een hotfix die een Netsh-switch toevoegt om Window Scaling na de tweede hertransmissie van een SYN-pakket te forceren (standaard wordt windowscaling uitgeschakeld nadat 2 SYN-pakketten opnieuw zijn verzonden) https://support.microsoft.com/en-us/kb/2780879


3
2018-06-06 12:34



Bedankt Christoph; een aantal zeer interessante nieuwe invoer op deze en die SYN-hertransmissie 'feature' is heel vreemd; Ik zie het ontwerpdoel hier helemaal niet achter. (Een soort van ruwe congestion detection, misschien?). Alle originele tests zijn uitgevoerd op Win7SP1; we zullen binnenkort Win10 uitproberen, en het is aan mij om hier veel van terug te halen om te zien hoe het gaat. - SmallClanger
Met welke tak van Windows 10 ga je testen? Ik heb nog geen ervaring met de netwerkstack in Windows 10. - Christoph Wegener
Enterprise 1511 is wat we richten. - SmallClanger
Ik snap het. Het is nogal moeilijk om een ​​filiaal met Windows 10 te kiezen, omdat er zoveel zijn. Ik ben al een probleem tegengekomen met Windows 10, waar ik een bepaalde functie niet kon gebruiken omdat ik op een LTSB-filiaal zat. Ik zou willen dat Microsoft het aantal beschikbare vestigingen in het algemeen had verminderd en in plaats daarvan hun documentatie verbeterde over welke fixes en functies in elke build zijn opgenomen .... - Christoph Wegener


Ik zie dat dit een iets ouder bericht is, maar het kan anderen helpen.

Kortom, u moet "Automatisch autoramen ontvangen" inschakelen:

netsh int tcp set global autotuninglevel=normal

CTCP betekent niets zonder bovenstaande ingeschakeld.

Als u "Automatisch afstemmen van venster" uitschakelt, bevindt u zich op een 64KB-pakketgrootte die negatieve gevolgen heeft voor lange RTT's in hoge breedbandverbindingen. Je kunt ook experimenteren met "beperkte" en "zeer beperkte" optie.

Zeer goede referentie: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html


1
2018-02-23 15:51





Ik ondervond een soortgelijk probleem met Windows Clients (Windows 7). Ik heb de meeste foutopsporing doorgenomen die je hebt doorstaan, het Nagle-algoritme uitschakelen, TCP schoorsteen offloading en tal van andere TCP-gerelateerde wijzigingen in de instellingen. Geen van hen had enig effect.

Wat het uiteindelijk voor mij had opgelost, was het standaard verzendvenster in het register van de AFD-service aanpassen. Het probleem lijkt te zijn gerelateerd aan het bestand afd.sys. Ik testte verschillende clients, sommige vertoonden de langzame upload en sommige niet, maar alle waren Windows 7-machines. Machines met het trage gedrag hadden dezelfde versie AFD.sys. De tijdelijke oplossing voor het register is nodig voor computers met bepaalde versies van AFD.sys (sorry, herinner de versie # 's niet).

HKLM \ CurrentControlSet \ Services \ AFD \ Parameters

Toevoegen - DWORD - DefaultSendWindow

Waarde - Decimaal - 1640960

Die waarde was iets dat ik hier vond: https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-

Ik denk dat om de juiste waarde te gebruiken, je moet het zelf berekenen met behulp van:

bv. Geadverteerde upload: 15 Mbps = 15.000 Kbps

(15000/8) * 1024 = 1920000

Voor zover ik begrijp, moet client-software deze instelling over het algemeen negeren in het register, maar als dat niet het geval is, wordt de standaardwaarde gebruikt en blijkbaar is de standaardwaarde in sommige versies van het AFD.sys-bestand erg laag.

Ik merkte dat voornamelijk MS-producten het trage uploadprobleem hadden (IE, Mini-redirector (WebDAV), FTP via Windows Explorer, enz ...) Bij het gebruik van software van derden (bijvoorbeeld Filezilla) had ik niet dezelfde vertragingen .

De AFD.sys voert alle Winsock-verbindingen uit, dus deze oplossing zou moeten gelden voor FTP, HTTP, HTTPS, enz ...

Deze correctie is ook hierboven ergens boven vermeld, dus ik wil er geen eer aan doen als het voor iedereen werkt, maar er was zoveel informatie in deze thread dat ik bang was dat het misschien was verdoezeld.


1
2017-07-16 20:11





Welnu, ik ben zelf een soortgelijke situatie tegengekomen (mijn vraag hier), en uiteindelijk moest ik TCP-schaalverificatietheuristieken uitschakelen, handmatig het autotuning-profiel instellen en CTCP inschakelen:

# 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





Ik heb niet voldoende punten om te reageren, dus plaats ik een 'antwoord'. Ik heb wat lijkt op een soortgelijk / identiek probleem (zie serverfault vraag hier). Mijn (en waarschijnlijk uw) probleem is de verzendbuffer van de iperf-client in Windows. Het groeit niet verder dan 64 KB. Windows moet de buffer dynamisch laten groeien wanneer deze niet expliciet door het proces wordt gedimensioneerd. Maar die dynamische groei gebeurt niet.

Ik ben niet zeker van uw schaal voor het schalen van vensters die het openen van het venster tot 500.000 bytes voor uw "trage" Windows-zaak laat zien. Ik verwachtte dat die grafiek slechts voor ~ 64.000 bytes open zou zijn, gezien het feit dat je beperkt bent tot 5 Mbps.


0
2017-08-24 23:22