Aktualizacja

Ok, próbowałem odpowiedzi poniżej i nic się nie zmieniło. Zidentyfikowałem chipset w laptopie jako NVIDIA nForce 520. Pobrałem najnowsze sterowniki Vista x64 dla nForce 520 (NVIDIA nie ma jeszcze żadnych sterowników dla tego chipsetu dla Win 7). Próbowałem zainstalować dołączone oprogramowanie zapory ogniowej (myślę, że może to przeszkadzać - nie jest). Całkowicie odinstalowałem moje oprogramowanie antywirusowe (używam Avast!), Myśląc, że sterownik filtra sieciowego może powodować problem, który również nie pomógł.

Zabrałem laptopa do domu moich braci i mogłem kopiować pliki z prędkością 10-12 MB / s przez jego sieć 100Mbit, więc nie sądzę, że to sprzęt.

Uruchomiłem iperf z zaskakującymi wynikami:
iperf z laptopa wysyłającego na serwer (przesyłanie)

> iperf -c naru
------------------------------------------------------------
Client connecting to naru, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[328] local 192.168.7.100 port 8549 connected with 192.168.7.6 port 5001
[ ID] Interval       Transfer     Bandwidth
[328]  0.0-10.0 sec   162 MBytes   136 Mbits/sec

> iperf -c naru -w 64k
------------------------------------------------------------
Client connecting to naru, TCP port 5001
TCP window size: 64.0 KByte
------------------------------------------------------------
[328] local 192.168.7.100 port 8550 connected with 192.168.7.6 port 5001
[ ID] Interval       Transfer     Bandwidth
[328]  0.0-10.0 sec  1.06 GBytes   909 Mbits/sec

iperf z serwera wysyłającego do laptopa (pobierz)

> iperf -c miyuki
------------------------------------------------------------
Client connecting to miyuki, TCP port 5001
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[256] local 192.168.7.6 port 51871 connected with 192.168.7.100 port 5001
[ ID] Interval       Transfer     Bandwidth
[256]  0.0-10.1 sec  25.2 MBytes  20.8 Mbits/sec

> iperf -c miyuki -w 64k
------------------------------------------------------------
Client connecting to miyuki, TCP port 5001
TCP window size: 64.0 KByte
------------------------------------------------------------
[256] local 192.168.7.6 port 51872 connected with 192.168.7.100 port 5001
[ ID] Interval       Transfer     Bandwidth
[256]  0.0-10.0 sec  21.1 MBytes  17.6 Mbits/sec

Dla porównania tutaj są numery iperf między HTPC a serwerem

Server: Naru, Host: CC (CC sends to Naru)
iperf -c naru:        0.0-10.0 sec   363 MBytes   305 Mbits/sec
iperf -c naru -w 64k: 0.0-10.0 sec  1.06 GBytes   912 Mbits/sec

Server: CC, Host: Naru (Naru sends to CC)
iperf -c cc:        0.0-10.0 sec   322 MBytes   270 Mbits/sec
iperf -c cc -w 64k: 0.0-10.0 sec  1020 MBytes   855 Mbits/sec

Korzystanie z Wireshark do oglądania transferu z serwera do laptopa zawiera wiele następujących wpisów:

(:51aa is the server, :37a1 is the laptop)
No.   Time      Source                    Destination               Proto Info
37785 27.286240 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#13] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40517974
37786 27.286258 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#14] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40519414
37787 27.286277 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#15] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40520854
37788 27.286295 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#16] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40522294
37789 27.286313 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#17] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40523734
37790 27.286332 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#18] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40525174
37791 27.286351 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#19] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40499254 SRE=40526614
37792 27.286370 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Previous segment lost] [TCP segment of a reassembled PDU]
37793 27.286372 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP segment of a reassembled PDU]
37794 27.286375 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Fast Retransmission] [TCP segment of a reassembled PDU]
37795 27.286377 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
37796 27.286379 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
37797 27.286382 fe80::1569:8500:b24a:51aa fe80::3820:2199:1623:37a1  TCP  [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
37798 27.286413 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#20] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40528054 SRE=40529494 SLE=40499254 SRE=40526614
37799 27.286432 fe80::3820:2199:1623:37a1 fe80::1569:8500:b24a:51aa  TCP  [TCP Dup ACK 37753#21] 8360 > microsoft-ds [ACK] Seq=80228 Ack=40489174 Win=64800 Len=0 SLE=40528054 SRE=40530934 SLE=40499254 SRE=40526614

W tym momencie mam całkowitą i całkowitą stratę, co dalej.

Oryginalne pytanie

tło

Obecnie mam problem z moim świeżo zainstalowanym laptopem z systemem Windows 7. Problem pierwotnie pojawił się po zainstalowaniu systemu Windows 7 RC. Kiedy Windows Vista i Windows 7 Beta 1 zostały zainstalowane na tym laptopie, mogłem przesyłać dane z gigabitową prędkością przy włączonych ramkach Jumbo do zakresu 9KB / 9014. Dwa przełączniki między laptopem obsługują również ramki Jumbo.

Podczas kopiowania plików z mojego serwera na laptopa, działają one w tempie ślimaków (zwykle mniej niż 1 MB / s), podczas gdy inne urządzenia przechodzące przez te same przełączniki mogą przesyłać z większą prędkością (45-55 MB / s). Wydaje się, że kopiowanie z laptopa na serwer powoduje szybsze działanie sieci, ale nie powinno tak być.

Zaangażowane maszyny

• Miyuki: Laptop z problemem. Windows 7 x64 RTM. HP Pavilion dv9700 CTO. Wykorzystuje kartę Ethernet NVIDIA nForce 10/100/1000 Mbps. (Wideo to GeForce 8400M GS)
• Naru: Serwer z plikami. Niestandardowy system Windows Server 2008 R2 x64 SP2. Wykorzystuje adapter D-Link DGE-560T PCI Express Gigabit.
• CC: HTPC na tym samym przełączniku bez problemu. Windows Vista x86 SP2. Wykorzystuje wbudowany adapter Realtek RTL8168B / 8111B PCI-E GBE.

Po wykonaniu tych zdjęć ogromne ramki zostały wyłączone.

Obrazki

Kopiowanie zainicjowane z laptopa

Serwer -> Laptop _{(źródło: gibixonline.com )} Laptop -> Serwer

Kopiowanie zainicjowane z serwera

Serwer -> Laptop _{(źródło: gibixonline.com )} Niespodziewanie _zlecenie przez serwer skopiowania pliku z laptopa do siebie powoduje zwiększenie prędkości, których bym się spodziewał. (Laptop -> Serwer) _{(źródło: gibixonline.com )}

Powiedziałem wcześniej, że na innym komputerze z tym samym przełącznikiem nie ma tego problemu. Wysoka DPI jest włączona, ponieważ jest wyświetlana na telewizorze HD.
Serwer -> HTPC _{(źródło: gibixonline.com )}

Oczywiście jako test postanowiłem sprawdzić, jakie są prędkości między moim laptopem a HTPC. Niestety były dokładnie takie, jak się spodziewałem.
HTPC -> Laptop _{(źródło: gibixonline.com )}

Uwagi końcowe

Próbowałem wszystkiego, co mogłem wymyślić. Nawet duże ramki są w tym momencie wyłączone i wydaje się, że nic na to nie wpływa. Próbowałem wyłączyć ochronę antywirusową na zmianę używanych kabli. Obecnie wszystkie używane kable to CAT-5e, które zbudowałem. Próbowałem wziąć kabel z HTPC i podłączyć go do laptopa, aby sprawdzić, czy problem nie dotyczył okablowania. Dwa omawiane przełączniki to D-Link DGS-1216T i „głupi” przełącznik obsługujący duże ramki, D-Link DGS-2208.

Spróbuj wyłączyć funkcję automatycznego dostrajania systemu Windows.

W oknie CMD:

netsh interface tcp set global autotuning=disabled 

Uruchom ponownie test i sprawdź, czy zauważysz poprawę wydajności. Musiałem to zrobić na kilku laptopach z systemem Windows 7 w moim domu i to pomogło.

Jeśli sytuacja się pogorszy lub nie zauważysz żadnej poprawy, możesz ponownie włączyć autotuning poprzez:

netsh interface tcp set global autotuning=normal

Wydaje się, że jest to duży problem w systemie Windows 7. Kilku graczy skarżyło się na ten problem.

1. W wierszu polecenia (zwykle w Wszystkie programy -> Akcesoria -> Wiersz polecenia) uruchom „regedit”
2. Przejdź do HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ Tcpip \ Parameters \ Interfaces
3. Przeglądaj elementy pod interfejsami, aż znajdziesz taki, który ma wpis IPAddress pasujący do interfejsu sieciowego, na który chcesz wpływać (zazwyczaj adresy IP LAN zaczynają się od 192.168 lub 10.0); zwróć uwagę, że jeśli twój adres IP jest automatycznie przypisywany przez serwer DHCP, może być konieczne znalezienie pasującego adresu DhcpIP zamiast adresu IP
4. Kliknij interfejs prawym przyciskiem myszy i wybierz opcję Nowa> Wartość DWORD (32-bitowa), nazwij ją „TcpAckFrequency”
5. Kliknij prawym przyciskiem myszy nową wartość TcpAckFrequency i wybierz opcję Modyfikuj, wprowadź „1 ″ (należy wybrać przycisk szesnastkowy)
6. Kliknij interfejs prawym przyciskiem myszy i wybierz opcję Nowa> Wartość DWORD (32-bitowa), nadaj jej nazwę „TCPNoDelay” (zwróć uwagę, że tym razem wszystkie wielkie litery są duże - to celowe)
7. Kliknij prawym przyciskiem myszy nową wartość TCPNoDelay i wybierz opcję Modyfikuj, wprowadź „1 ″ (należy wybrać przycisk szesnastkowy)
8. Sprawdź, czy zarówno TcpAckFrequency, jak i TCPNoDelay są teraz wyświetlane na liście właściwości adaptera z typami REG_DWORD i wartościami 0 × 00000001
9. Wyjdź z regedit i uruchom ponownie (ponowne uruchomienie jest konieczne, aby zmiany odniosły skutek!)
   10. Zagraj w grę i ciesz się nowym niskim pingiem

Zmniejszyło to moje pingowanie w większości gier z 200–300 ms do 50–60 ms, co odpowiada opóźnieniu, które widziałbym przez tracert na serwerze gry.

Zaczerpnięte z zmniejszenia opóźnień w grze w systemie Windows 7 lub Vista

Aby sprawdzić, czy laptop nie jest winny, uruchom dysk CD z Ubuntu Live, zainstaluj iperf na ramdysku i uruchom test.

Powinno to przynajmniej przetestować jego stronę sieciową.

Sprawdź, czy nie ma upuszczonych pakietów. Nie jestem pewien, jak to zrobić w systemie Windows, ale jeśli masz komputer z systemem Linux, możesz to sprawdzić.

Miałem podobne doświadczenia z przełącznikiem gigabitowym, w którym tryb gigabitowy został zerwany i upuszczałem pakiety. Widziałem problemy tylko wtedy, gdy miałem podłączone 2 maszyny w tym trybie. W trybie 100K wszystko było w porządku. To był paskudny problem, który zajęło mi kilka dni. Mógłbym być D-Link. Rozejrzyj się za swoim modelem przełącznika. Znalazłem i odkryłem, że inni mieli ten sam problem co ja.

Zetknąłem się z tym wcześniej z innymi produktami AV. Mój problem dotyczył SMB, a produkt AV zakłócał nawet gdy był „wyłączony”. Pokazał podobne wyniki w wireshark, które masz. Oto jedna z wielu witryn, które sprawdziłem, aby dojść do głównej przyczyny: problem z SMB firmy Symantec i inny: błąd SMB2 z NTP

Ponadto możesz spróbować wyłączyć / zmienić wszystkie lub niektóre ustawienia w SMB. Rozważałbym nawet wyłączenie v2 w systemie operacyjnym. Zapoznaj się z tym artykułem opisującym problem z SMB w Win Vista, a ten link do Microsoft zawiera niektóre dane techniczne na temat ustawień reg SMB .

Wiem, że wspomniałeś o Avast, ale całkiem przypadkowo widziałem podobne wyniki Wireshark. Zauważ, że wszystko oprócz przesyłania plików w moim przypadku działało dobrze.

Miałem problemy z klientami komunikującymi się z serwerami Windows podczas korzystania z podpisywania pakietów. Nie doświadczyłem spowolnienia, ale raczej bardzo częste zaniki połączeń.

Przeczytaj tutaj, aby znaleźć rozwiązanie, które rozwiązało mój problem.

Nie widzę też żadnych sugestii dotyczących wyłączania funkcji TCP Chimney jedna po drugiej, aby sprawdzić, czy któraś z nich poszła nie tak.

Wygląda na to, że system operacyjny sprawdza pakiety przed zapisaniem na dysk. Zauważyłem, że wszystkie wolne transfery to te, które próbują pisać na laptopie ... Sugeruję

• sprawdzanie rozmiarów bloków partycji na laptopach HDD (małe rozmiary bloków mogą powodować zły czas poszukiwania wolnego miejsca podczas próby przeniesienia pojedynczego dużego pliku (lub tak dalej))
• sprawdzanie wszelkich zasad zapory, które sprawdzają przychodzące pakiety pod kątem zapisu na dysku
• sprawdzanie dowolnego monitora aktywności plików (nie powinno to budzić obaw ze względu na odinstalowanie programu antywirusowego) (jak wiesz, avast wykonuje sprawdzanie plików na żywo, co nieco spowalnia transfer sieciowy)
• defragmentacja partycji docelowej (ponownie o poszukiwaniu wolnego miejsca)

Inne są sugerowane i nie pomagają:

• autotuning
• poziom dupleksu
• kable ...

Ostatnia sugestia: czy możesz sprawdzić wykrywanie linków w trybie baterii w zaawansowanych właściwościach nic? To laptop i mogą występować problemy z właściwościami oszczędzania energii ... Spróbuj „Bez oszczędzania energii” na wykrywaniu linków w trybie baterii i „Pełny” na ustawieniach prędkości baterii.

Używam win7 na komputerze stacjonarnym i te opcje nie są uwzględnione w zaawansowanych właściwościach mojej nici. Tak długo, jak nigdy nie zajmowałem się tym problemem, możesz sprawdzić wartości „Kontrola przepływu” do „TX i RX włączone” jako opcje mojej nici. Jumbo jest wyłączone, Speed ​​i Duplex są również automatyczne w mojej konfiguracji ...

Nie mogę wymyślić żadnego innego rozwiązania ... Mam nadzieję, że to pomoże ...

Wcześniej ścigałem ogon dokładnie z tym samym problemem przez chwilę! Wolne prędkości transferu w jednym kierunku, w moim przypadku wychodzące (łącze w górę).

Windows 7 Pro, Celeron J1800 z wbudowaną kartą LAN Realtek Gigabit 8111C. QNAP 453a i MacBook Pro na drugim końcu.

Podczas pomiaru za pomocą Iperf3 uzyskiwałem 112 Mb / s przy moim systemie Windows 7 ustawionym jako klient (zużycie procesora wynosi 25-30%). I tylko 39-41 Mb / s, gdy jest ustawiony jako serwer, z dużym zużyciem procesora między 50-100%. Tak źle, że komputer zawiesza się w czasie testowania przepustowości.

Zwykły transfer plików nie przekracza 45 Mb / s, bez względu na to, czy przesyłałem lub pobierałem pliki na mój serwer NAS lub MAC.

Nie dostawałem nic więcej niż 35-45 megabajtów na sekundę. Dość frustrujące!

Skończyło się na złym sterowniku karty LAN. Miałem obsesję na punkcie aktualizowania sterowników i zawsze aktualizowałem sterowniki, gdy nowy będzie dostępny. Zgadnij co, po kilku aktualizacjach moja karta LAN zwolniła.

Niektórzy z was mogą powiedzieć, wystarczy usunąć stary sterownik i zainstalować nowy. Proste, ah? Próbowałem i próbowałem, To nie działało dla mnie.

Oto moje rozwiązanie:

Zainstalowane okna od zera ze sterownikami OEM ze strony producenta. Wykonałem również następujące czynności:

W obszarze Menedżer urządzeń / karta Lan / Ustawienia zaawansowane / Wyłącz wszystko oprócz KONTROLI PRZEPŁYWU.

W obszarze Funkcje systemu Windows wyłącz zdalną kompresję różnicową.

Teraz średnia prędkość wynosi od 80-100 Mb / s.

Ogólnie zakładam, że ustawiłeś karty sieciowe na pełny dupleks, 100 MBit, a nie na auto?

Prawdopodobnie nie znosisz tej odpowiedzi, ale muszę to powiedzieć!

Czy próbowałeś zaktualizować sterowniki?

Mam podobny problem na moim laptopie (karta sieciowa oparta na Realtek), przesyła z prędkością około 3 MB / s, ale z chwilą aktualizacji sterowników do najnowszych z ich strony idzie do około 40-50 MB / s

Tylko dlatego, że sterowniki z systemem Windows działają, to nie znaczy, że są najlepsze.

Podejrzewam, że jest to coś na drodze od serwera do laptopa, np .:

• Port przełącznika załatany na laptopie
• Okablowanie Ethernet lub połączenia między przełącznikiem a laptopem

Doskonała sugestia Per @ SaucemanSpiff, czy próbowałeś okablować laptopa bezpośrednio do serwera za pomocą znanego dobrego kabla CAT5E lub CAT6? Nie ma potrzeby stosowania specjalnego kabla z przeplotem, o ile co najmniej jeden z interfejsów obsługuje Gigabit Ethernet (co oznacza Auto MDI-X).

1. Pobiłeś komputer na śmierć dzięki aktualizacjom i przetestowałeś go poza siedzibą bez żadnych awarii. Czy próbowałeś robić aktualizacje i takie na SERWERZE „naru”?

2. Większość rozwiązań w tym wątku sugerowanych przez innych może odnosić się do serwera. Wypróbowałeś je tam?

3. Co się dzieje, gdy testujesz przy użyciu Robocopy (z jumbo i bez)? Jeśli jest szybki w obu kierunkach, użyłbym narzędzia netshark, aby spojrzeć na nagłówki sesji SMB na początku kopii w każdym kierunku i sprawdzić, czy coś wygląda inaczej w konfiguracji naru> miyuki.

Czy próbowałeś użyć teracopy? Używam tego jako standardowego zamiennika dla kopii systemu Windows od ponad roku i pokazałem poprawę prędkości transferu :)

Niby strzał w ciemność, ale może pomóc.

• Wyłącz „Zdalną kompresję różnicową” w Panelu sterowania - Programy i funkcje - Włącz lub wyłącz funkcje systemu Windows.
• Usuń IPv6 z właściwości sieci. Czy używasz IPv6 w swojej sieci LAN? Jeśli nie, wyłącz go.
• Wyczyść pamięć podręczną DNS za ipconfig /flushdnspomocą w interfejsie CLI.

jeśli jest to spowodowane zmianą systemu operacyjnego, to z pewnością problem leży w systemie operacyjnym. powinieneś spróbować zainstalować najnowszy dodatek Service Pack dla systemu Windows 7 i aktualizować system Windows o najnowsze aktualizacje. i mam nadzieję na najlepsze