Scenariusz: Mamy wielu klientów Windows regularnie przesyłających duże pliki (FTP / SVN / HTTP PUT / SCP) na serwery Linux, które są w odległości ~ 100-160 ms. W biurze mamy synchroniczną przepustowość 1 Gb / s, a serwery są instancjami AWS lub fizycznie hostowane w DC w USA.
Początkowy raport był taki, że przesyłanie do nowej instancji serwera było znacznie wolniejsze niż mogłoby być. Znosiło to w testach i z wielu lokalizacji; klienci widzieli stabilne 2-5 Mb / s na hoście z systemów Windows.
Zerwałem się iperf -s
na wystąpieniu AWS, a następnie z klienta Windows w biurze:
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
Ta ostatnia liczba może się znacznie różnić w kolejnych testach (Vagaries of AWS), ale zwykle wynosi od 70 do 130 Mb / s, co jest więcej niż wystarczające dla naszych potrzeb. Wiresharking sesji, widzę:
iperf -c
Windows SYN - Windows 64kb, Skala 1 - Linux SYN, ACK: Windows 14kb, Skala: 9 (* 512)iperf -c -w1M
Windows SYN - Windows 64kb, Skala 1 - Linux SYN, ACK: Windows 14kb, Skala: 9
Oczywiście łącze może wytrzymać tak wysoką przepustowość, ale muszę dokładnie ustawić rozmiar okna, aby z niego skorzystać, czego większość aplikacji na świecie nie pozwala mi na to. Uściski dłoni TCP używają tych samych punktów początkowych w każdym przypadku, ale wymuszony skaluje się
I odwrotnie, z klienta Linux w tej samej sieci prosta iperf -c
(używając domyślnego systemu 85kb) daje mi:
[ 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
Bez użycia siły skaluje się zgodnie z oczekiwaniami. Nie może to być coś w pośrednich przeskokach ani w naszych lokalnych przełącznikach / routerach i wydaje się mieć wpływ na klientów Windows 7 i 8. Przeczytałem wiele przewodników na temat automatycznego dostrajania, ale zazwyczaj dotyczą one całkowitego wyłączenia skalowania, aby obejść zły zestaw sieci domowej.
Czy ktoś może mi powiedzieć, co się tutaj dzieje i dać mi sposób, aby to naprawić? (Najlepiej coś, co mogę trzymać w rejestrze przez GPO.)
Notatki
Instancja AWS Linux, o której mowa, ma następujące ustawienia jądra 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
Użyłem dd if=/dev/zero | nc
przekierowania /dev/null
na końcu serwera, aby wykluczyć iperf
i usunąć wszelkie inne możliwe wąskie gardła, ale wyniki są prawie takie same. Testy z ncftp
(Cygwin, Native Windows, Linux) są skalowane w podobny sposób, jak powyższe testy Iperf na ich platformach.
Edytować
Zauważyłem tutaj kolejną spójną rzecz, która może być istotna:
Jest to pierwsza sekunda powiększenia 1 MB, powiększenie. Możesz zobaczyć Slow Start w akcji, gdy okno skaluje się i bufor staje się większy. Jest wtedy ten niewielki plateau ~ 0.2s dokładnie w punkcie, w którym domyślny test iperf okna spłaszcza się na zawsze. Ten oczywiście skaluje się do znacznie bardziej zawrotnych wysokości, ale ciekawe, że jest taka przerwa w skalowaniu (wartości to 1022 bajtów * 512 = 523264), zanim to zrobi.
Aktualizacja - 30 czerwca.
W odpowiedzi na różne odpowiedzi:
- Włączanie CTCP - to nie robi różnicy; skalowanie okien jest identyczne. (Jeśli dobrze to rozumiem, to ustawienie zwiększa szybkość powiększania okna przeciążenia, a nie maksymalny rozmiar, jaki może osiągnąć)
- Włączanie znaczników czasu TCP. - Tu też nie ma zmian.
- Algorytm Nagle'a - to ma sens i przynajmniej oznacza, że prawdopodobnie mogę zignorować te konkretne blipy na wykresie jako jakiekolwiek oznaki problemu.
- Pliki pcap: Plik zip dostępny tutaj: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (zanonimizowane za pomocą bittwiste, wyodrębnia do ~ 150 MB, ponieważ istnieje jeden z każdego klienta systemu operacyjnego do porównania)
Aktualizacja 2 - 30 czerwca
O, więc zgodnie z sugestią Kyle'a, włączyłem ctcp i wyłączyłem odciążanie komina: TCP Global 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
Niestety, nie ma zmiany w przepustowości.
Mam tu jednak pytanie o przyczynę / skutek: wykresy dotyczą wartości RWIN ustawionej w zestawach ACK serwera dla klienta. Czy w przypadku klientów Windows mam rację, myśląc, że Linux nie skaluje tej wartości poza ten najniższy punkt, ponieważ ograniczony CWIN klienta uniemożliwia zapełnienie nawet tego bufora? Czy może istnieć inny powód, dla którego Linux sztucznie ogranicza RWIN?
Uwaga: próbowałem włączyć ECN do cholery; ale bez zmian.
Aktualizacja 3 - 31 czerwca.
Brak zmian po wyłączeniu heurystyki i autotuningu RWIN. Zaktualizowałem sterowniki sieciowe Intel do najnowszej wersji (12.10.28.0) o oprogramowanie, które ujawnia zakładki poprawiania funkcjonalności menedżerów viadevice. Karta to wbudowana karta sieciowa z chipsetem 82579 V - (zamierzam wykonać więcej testów od klientów z Realtek lub innymi dostawcami)
Koncentrując się na chwilę na karcie sieciowej, próbowałem następujących rzeczy (głównie po prostu wykluczając nieoczekiwanych winowajców):
- Zwiększyć bufory odbioru do 2k z 256 i przesłać bufory do 2k z 512 (oba teraz maksymalnie) - Bez zmian
- Wyłączono wszystkie odciążanie sumy kontrolnej IP / TCP / UDP. - Brak zmiany.
- Wyłączone duże wysyłanie odciążenia - Nada.
- Wyłączono planowanie IPv6, QoS - Nowt.
Aktualizacja 3 - 3 lipca
Próbując wyeliminować stronę serwera Linux, uruchomiłem instancję Server 2012R2 i powtórzyłem testy przy użyciu iperf
(cygwin binary) i NTttcp .
Z iperf
musiałem wyraźnie określić -w1m
po obu stronach, zanim połączenie będzie skalowane powyżej ~ 5 Mb / s. (Nawiasem mówiąc, mogłem zostać sprawdzony, a BDP ~ 5 Mb przy opóźnieniu 91 ms to prawie dokładnie 64 kb. Znajdź limit ...)
Pliki binarne ntttcp wykazały teraz takie ograniczenie. Używając ntttcpr -m 1,0,1.2.3.5
na serwerze i ntttcp -s -m 1,0,1.2.3.5 -t 10
kliencie, widzę znacznie lepszą przepustowość:
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
8 MB / s podnosi to na poziomach, które otrzymywałem z wyraźnie dużymi oknami iperf
. Dziwne jednak, że 80 MB w 1273 buforach = bufor 64kB ponownie. Kolejny wireshark pokazuje dobrą, zmienną RWIN wracającą z serwera (współczynnik skali 256), który wydaje się spełniać klient; więc być może ntttcp źle zgłasza okno wysyłania.
Aktualizacja 4 - 3 lipca
Na prośbę @ karyhead wykonałem jeszcze kilka testów i wygenerowałem kilka dodatkowych zdjęć, tutaj: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip
- Dwa kolejne
iperf
s, oba z systemu Windows na ten sam serwer Linux jak poprzednio (1.2.3.4): Jeden z gniazdem o wielkości 128 kb i domyślnym oknem 64 k (ponownie ogranicza się do ~ 5 Mb / s), a drugi z oknem wysyłania 1 MB i domyślnym gniazdem 8 kb rozmiar. (skaluje się wyżej) - Jeden
ntttcp
ślad z tego samego klienta Windows do wystąpienia Server 2012R2 EC2 (1.2.3.5). tutaj przepustowość dobrze się skaluje. Uwaga: NTttcp robi coś dziwnego na porcie 6001, zanim otworzy połączenie testowe. Nie jestem pewien, co się tam dzieje. - Jeden ślad danych FTP, przesyłanie 20 MB
/dev/urandom
do prawie identycznego hosta Linux (1.2.3.6) przy użyciu Cygwinncftp
. Znowu jest limit. Wzór jest taki sam w przypadku Windows Filezilla.
Zmiana iperf
długości bufora robi oczekiwaną różnicę w wykresie sekwencji czasowej (znacznie więcej pionowych odcinków), ale faktyczna przepustowość pozostaje niezmieniona.
źródło
netsh int tcp set global timestamps=enabled
Odpowiedzi:
Czy próbowałeś włączyć Compound TCP (CTCP) w swoich klientach Windows 7/8.
Proszę przeczytaj:
Zwiększenie wydajności po stronie nadawcy dla transmisji o wysokim BDP
http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx
Edytuj 30.06.2014
aby sprawdzić, czy CTCP jest naprawdę „włączony”
to znaczy
CTCP agresywnie zwiększa okno wysyłania
http://technet.microsoft.com/en-us/library/bb878127.aspx
źródło
Set-NetTCPSetting
z-CongestionProvider
parametrem ... który akceptuje CCTP, DCTCP i domyślną. Klient i serwery Windows używają różnych domyślnych dostawców ograniczeń. technet.microsoft.com/en-us/library/hh826132.aspxiperf
a okno nadal nie skalowało się dalej niż ~ 520kb. Coś innego ogranicza CWND, zanim ten agresywny algorytm nie przyniesie żadnych korzyści.Wyjaśnienie problemu:
TCP ma dwa okna:
W podanym pliku przechwytywania. Widzimy, że bufor odbiorczy nigdy się nie przepełnia:
Moja analiza polega na tym, że nadawca nie wysyła wystarczająco szybko, ponieważ okno wysyłania (inaczej okno kontroli przeciążenia) nie otwiera się wystarczająco, aby zaspokoić RWIN odbiornika. Krótko mówiąc, odbiorca mówi „Daj mi więcej”, a gdy Windows jest nadawcą, nie wysyła wystarczająco szybko.
Dowodzi tego fakt, że na powyższym wykresie RWIN pozostaje otwarty, a przy czasie podróży w obie strony 0,09 sekundy i RWIN wynoszącym ~ 500 000 bajtów możemy spodziewać się maksymalnej przepustowości zgodnie z iloczynem opóźnienia przepustowości (500000 /0.09) * 8 = ~ 42 Mbit / s (i dostajesz tylko około ~ 5 w swojej wygranej do przechwytywania w systemie Linux).
Jak to naprawić?
Nie wiem
interface tcp set global congestionprovider=ctcp
brzmi jak właściwa rzecz do zrobienia, ponieważ zwiększyłoby to okno wysyłania (co jest innym terminem dla okna przeciążenia). Powiedziałeś, że to nie działa. Aby się upewnić:netsh interface tcp show heuristics
. Myślę, że może to być RWIN, ale nie mówi, więc może graj z wyłączaniem / włączaniem, jeśli wpłynie to na okno wysyłania.Na początek spróbowałbym wszystkich tych eksperymentów ze wszystkimi funkcjami odciążania, aby wyeliminować możliwość, że sterowniki sieciowe dokonują pewnych przeróbek / modyfikacji rzeczy (miej oko na procesor, gdy odciążanie jest wyłączone). Struktura TCP_OFFLOAD_STATE_DELEGATED wydaje się co najmniej sugerować, że odciążenie CWnd jest co najmniej możliwe.
źródło
@Pat i @Kyle mają tutaj świetne informacje. Zdecydowanie zwróć uwagę na wyjaśnienia @ Kyle'a dotyczące odbierania i wysyłania okien przez TCP, myślę, że było w tym trochę zamieszania. Aby jeszcze bardziej pomylić sprawy, iperf używa terminu „okno TCP” z
-w
ustawieniem, które jest rodzajem dwuznacznym w odniesieniu do okna odbierania, wysyłania lub ogólnego przesuwanego okna. W rzeczywistości ustawia bufor wysyłania gniazda dla-c
instancji (klienta), a bufor odbierania gniazda dla-s
instancji (serwera). Wsrc/tcp_window_size.c
:Jak wspomina Kyle, problem nie dotyczy okna odbierania w Linux-ie, ale nadawca nie otwiera wystarczająco okna wysyłania. Nie chodzi o to, że nie otwiera się wystarczająco szybko, po prostu ogranicza się do 64k.
Domyślny rozmiar bufora gniazda w systemie Windows 7 to 64k. Oto, co dokumentacja mówi o rozmiarze bufora gniazda w stosunku do przepustowości w MSDN
Ok, bla bla bla, teraz zaczynamy:
Średnia przepustowość ostatniego testu iperf przy użyciu okna 64k wynosi 5,8 Mb / s. To z Statystyki> Podsumowanie w Wireshark, który liczy wszystkie bity. Prawdopodobnie iperf liczy przepustowość danych TCP, która wynosi 5,7 Mb / s. Tę samą wydajność widzimy również w teście FTP, ~ 5,6 Mb / s.
Teoretyczna przepustowość przy buforze wysyłania 64 tys. I RTT 91 ms wynosi .... 5,5 Mb / s. Wystarczająco blisko dla mnie.
Jeśli spojrzymy na twój test Iperf dla okna 1 MB, prędkość wynosi 88,2 Mb / s (86,2 Mb / s tylko dla danych TCP). Teoretyczna przepustowość z oknem 1 MB wynosi 87,9 Mb / s. Znowu wystarczająco blisko do pracy rządu.
Pokazuje to, że bufor gniazda wysyłania bezpośrednio kontroluje okno wysyłania, a w połączeniu z oknem odbioru z drugiej strony kontroluje przepustowość. Reklamowane okno odbioru ma miejsce, więc odbiorca nie ogranicza nas.
Poczekaj, a co z tym biznesem dostrajania? Czy system Windows 7 nie obsługuje tych rzeczy automatycznie? Jak już wspomniano, system Windows obsługuje automatyczne skalowanie okna odbierania, ale może także dynamicznie obsługiwać bufor wysyłania. Wróćmy do strony MSDN:
iperf używa
SO_SNDBUF
tej-w
opcji, więc dynamiczne buforowanie wysyłania byłoby wyłączone. Jednak jeśli nie używasz,-w
to nie używaSO_SNDBUF
. Dynamiczne buforowanie wysyłania powinno być domyślnie włączone, ale możesz sprawdzić:Dokumentacja mówi, że możesz to wyłączyć za pomocą:
Ale to nie działało dla mnie. Musiałem dokonać zmiany rejestru i ustawić to na 0:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DynamicSendBufferDisable
Nie sądzę, że wyłączenie tego pomoże; to tylko informacja dla ciebie.
Dlaczego skalowanie bufora wysyłania nie przekracza domyślnego 64k podczas wysyłania danych do Linux-a z dużą ilością miejsca w oknie odbioru? Świetne pytanie. Jądra systemu Linux mają również stos TCP do autotuningu. Podobnie jak T-Pain i Kanye wspólnie grający duet autotune, może to nie brzmieć dobrze. Być może jest jakiś problem z tymi dwoma automatycznymi tuningami stosów TCP rozmawiającymi ze sobą.
Inna osoba miała problem podobny do twojego i była w stanie go naprawić za pomocą edycji rejestru, aby zwiększyć domyślny rozmiar bufora wysyłania. Niestety, wydaje się, że to już nie działa, a przynajmniej nie działało dla mnie, kiedy próbowałem.
W tym momencie myślę, że jasne jest, że czynnikiem ograniczającym jest rozmiar bufora wysyłania na hoście Windows. Biorąc pod uwagę, że nie wydaje się dynamicznie prawidłowo rosnąć, co robi dziewczyna?
Możesz:
Oświadczenie: Spędziłem wiele godzin badając to i jest to zgodne z moją najlepszą wiedzą i Google-Fu. Ale nie przysięgałbym na grób mojej matki (ona wciąż żyje).
źródło
Po dostrojeniu stosu TCP może nadal występować wąskie gardło w warstwie Winsock. Przekonałem się, że konfiguracja Winsock (pomocniczego sterownika funkcji w rejestrze) ma ogromne znaczenie dla prędkości wysyłania (wypychania danych do serwera) w systemie Windows 7. Microsoft potwierdził błąd w autotuningu TCP dla gniazd nieblokujących - tylko rodzaj gniazda używanego przez przeglądarki ;-)
Dodaj klucz DWORD dla DefaultSendWindow i ustaw go na BDP lub wyższy. Używam 256000.
Zmiana ustawienia Winsock do pobierania może pomóc - dodaj klucz dla DefaultReceiveWindow.
Możesz eksperymentować z różnymi ustawieniami poziomu gniazda, używając Fiddler Proxy i poleceń, aby dostosować rozmiary bufora gniazda klienta i serwera:
źródło
Po przeczytaniu wszystkich analiz zawartych w odpowiedziach problem ten brzmi bardzo podobnie do systemu Windows 7 / 2008R2 lub Windows 6.1
Stos sieci (TCP / IP i Winsock) w systemie Windows 6.1 był strasznie wadliwy i zawierał wiele błędów i problemów z wydajnością, które Microsoft ostatecznie rozwiązał przez wiele lat poprawek od pierwszej wersji 6.1.
Najlepszym sposobem na zastosowanie tych poprawek jest ręczne przeglądanie wszystkich odpowiednich stron w witrynie support.microsoft.com oraz ręczne żądanie i pobieranie wersji LDR poprawek stosu sieciowego (jest ich wiele.
Aby znaleźć odpowiednie poprawki, musisz użyć www.bing.com z następującym zapytaniem
site:support.microsoft.com 6.1.7601 tcpip.sys
Musisz także zrozumieć, jak działają zestawy poprawek LDR / GDR w systemie Windows 6.1
Zwykle utrzymywałem własną listę poprawek LDR (nie tylko poprawki stosu sieciowego) dla Windows 6.1, a następnie proaktywnie stosowałem te poprawki na dowolnym serwerze / kliencie Windows 6.1, z którym się spotkałem. Sprawdzanie dostępności nowych poprawek LDR było bardzo czasochłonne.
Na szczęście Microsoft zaprzestał stosowania poprawek LDR w nowszych wersjach systemu operacyjnego, a poprawki są teraz dostępne za pośrednictwem usług automatycznych aktualizacji firmy Microsoft.
AKTUALIZACJA : Tylko jeden przykład wielu błędów sieciowych w Windows7SP1 - https://support.microsoft.com/en-us/kb/2675785
AKTUALIZACJA 2 : Oto kolejna poprawka, która dodaje przełącznik netsh, aby wymusić skalowanie okna po drugiej retransmisji pakietu SYN (domyślnie skalowanie okna jest wyłączone po ponownym przesłaniu 2 pakietów SYN) https://support.microsoft.com/en- us / kb / 2780879
źródło
Widzę, że jest to nieco starszy post, ale może pomóc innym.
Krótko mówiąc, musisz włączyć „Automatyczne dostrajanie okna odbioru”:
CTCP nic nie znaczy bez powyższej opcji.
Jeśli wyłączysz „Automatyczne dostrajanie okna odbioru”, utkniesz w rozmiarze pakietu 64 KB, co ma negatywny wpływ na długie RTT w połączeniach szerokopasmowych. Możesz także eksperymentować z opcją „ograniczona” i „wysoce ograniczona”.
Bardzo dobra referencja: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html
źródło
Wystąpił podobny problem z klientami Windows (Windows 7). Przeszedłem przez większość debugowania, przez które przeszliście, wyłączając algorytm Nagle, odciążanie komina TCP i mnóstwo innych zmian ustawień związanych z TCP. Żadne z nich nie miało żadnego efektu.
To, co w końcu to naprawiło, to modyfikacja domyślnego okna wysyłania w rejestrze usługi AFD. Problem wydaje się być związany z plikiem afd.sys. Przetestowałem kilka klientów, niektóre wykazywały powolne ładowanie, a niektóre nie, ale wszystkie były komputerami z systemem Windows 7. Maszyny wykazujące wolne działanie miały tę samą wersję AFD.sys. Obejście rejestru jest wymagane w przypadku komputerów z niektórymi wersjami pliku AFD.sys (przepraszam, nie pamiętaj wersji #).
HKLM \ CurrentControlSet \ Services \ AFD \ Parameters
Dodaj - DWORD - DefaultSendWindow
Wartość - dziesiętna - 1640960
Znalazłem tutaj tę wartość: https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-
Myślę, że aby użyć właściwej wartości, powinieneś ją obliczyć, używając:
na przykład. Przesyłanie reklamowane: 15 Mb / s = 15 000 Kb / s
(15000/8) * 1024 = 1920000
Z tego, co rozumiem, oprogramowanie klienckie powinno zasadniczo zastępować to ustawienie w rejestrze, ale jeśli nie, używana jest wartość domyślna i najwyraźniej wartość domyślna jest bardzo niska w niektórych wersjach pliku AFD.sys.
Zauważyłem, że głównie produkty MS miały problem z powolnym przesyłaniem (IE, Mini-redirector (WebDAV), FTP za pośrednictwem Eksploratora Windows itp.). Podczas korzystania z oprogramowania innych firm (np. Filezilla) nie miałem takich samych spowolnień .
AFD.sys wpływa na wszystkie połączenia Winsock, więc ta poprawka powinna mieć zastosowanie do FTP, HTTP, HTTPS itp.
Ponadto, ta poprawka została gdzieś wymieniona powyżej, więc nie chcę jej przypisywać, jeśli zadziała ona dla kogokolwiek, jednak w tym wątku było tyle informacji, że obawiałem się, że mogła zostać poprawiona.
źródło
Cóż, sam spotkałem się z podobną sytuacją (moje pytanie tutaj ) i ostatecznie musiałem wyłączyć heurystykę skalowania TCP, ręcznie ustawić profil autotuningu i włączyć CTCP:
źródło
Nie mam wystarczającej liczby punktów do skomentowania, więc zamiast tego opublikuję „odpowiedź”. Mam coś, co wydaje się być podobnym / identycznym problemem (patrz pytanie o awarię serwera tutaj ). Moim (i prawdopodobnie twoim) problemem jest bufor wysyłania klienta iperf w systemie Windows. Nie przekracza 64 KB. System Windows ma dynamicznie powiększać bufor, gdy proces nie określa go wyraźnie. Ale ten dynamiczny wzrost nie ma miejsca.
Nie jestem pewien, czy twój wykres skalowania okna pokazuje okno otwierające się do 500 000 bajtów dla twojego „powolnego” przypadku Windows. Spodziewałem się, że ten wykres będzie otwarty tylko na ~ 64 000 bajtów, biorąc pod uwagę, że jesteś ograniczony do 5 Mb / s.
źródło
To fascynujący wątek i dokładnie pasuje do problemów, które miałem przy użyciu Win7 / iperf do testowania przepustowości na długich grubych rurach.
Rozwiązaniem dla Windows 7 jest wykonanie następującego polecenia zarówno na serwerze iperf ORAZ na kliencie.
netsh interface tcp set global autotuninglevel = eksperymentalny
Uwaga: zanim to zrobisz, pamiętaj o zapisaniu aktualnego stanu autostrojenia:
netsh interface tcp show global
Poziom automatycznego dostrajania okna odbioru: wyłączony
Następnie uruchom serwer / klient iperf na każdym końcu potoku.
Zresetuj wartość autostrojenia po testach:
netsh interface tcp set global autotuninglevel =
źródło