Skenario: Kita memiliki sejumlah klien Windows secara teratur meng-upload file besar (FTP/SVN/HTTP PUT/SCP) untuk Linux server yang ~100-160ms jauh. Kami telah 1Gbit/s sinkron bandwidth di kantor dan server yang baik AWS contoh fisik atau di-host di US DCs.
Laporan awal itu upload ke server baru contoh yang jauh lebih lambat dari yang mereka bisa. Hal ini melahirkan dalam pengujian dan dari beberapa lokasi; klien melihat stabil 2-5Mbit/s ke host dari sistem Windows.
Saya pecah iperf -s
pada sebuah AWS contoh dan kemudian dari a Windows klien di kantor:
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
Angka terakhir dapat bervariasi secara signifikan pada tes selanjutnya, (Keanehan AWS) tetapi biasanya antara 70 dan 130Mbit/s yang lebih dari cukup untuk kebutuhan kita. Wiresharking sesi, saya bisa melihat:
iperf -c
Windows SYN - Jendela 64kb, Skala 1 - Linux SYN, ACK: Jendela 14kb, Skala: 9 (*512)
iperf -c -w1M
Windows SYN - Windows 64kb, Skala 1 - Linux SYN, ACK: Jendela 14kb, Skala: 9
Jelas link dapat mempertahankan produktivitas yang tinggi, tapi aku harus explicity mengatur ukuran jendela untuk membuat penggunaan itu, yang paling aplikasi dunia nyata won't membiarkan saya lakukan. TCP jabat tangan sama-sama menggunakan titik awal dalam setiap kasus, tetapi dipaksa satu timbangan
Sebaliknya, dari klien Linux pada jaringan yang sama yang lurus, iperf -c
(menggunakan sistem default 85kb) memberikan saya: [ 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
Tanpa memaksa, sisik seperti yang diharapkan. Hal ini dapat't menjadi sesuatu yang di campur hop atau lokal kami switch/router dan tampaknya mempengaruhi Windows 7 dan 8 klien yang sama. I'telah membaca banyak panduan tentang auto-tuning, tapi biasanya ini adalah tentang cara menonaktifkan scaling sama sekali untuk bekerja di sekitar buruk yang mengerikan jaringan rumah kit. Siapa pun dapat memberitahu saya apa yang's terjadi di sini dan memberi saya cara memperbaikinya? (Sebaiknya sesuatu yang saya dapat menempel di registri melalui GPO.)
AWS Linux misalnya dalam pertanyaan berikut kernel settings diterapkan di 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
I've digunakan dd if=/dev/zero | nc
komputer /dev/null
di server end untuk mengesampingkan iperf
dan menghapus yang lain kemacetan yang mungkin, tetapi hasilnya sama. Tes dengan ncftp
(Cygwin, Asli Windows, Linux) skala dalam banyak cara yang sama seperti di atas iperf tes pada platform mereka masing-masing.
I've terlihat lain yang konsisten hal di sini yang mungkin relevan: Ini adalah pertama kedua dari 1MB menangkap, diperbesar. Anda dapat melihat Slow Start dalam tindakan sebagai jendela scale up dan buffer akan lebih besar. Ada's maka ini kecil dataran tinggi ~0.2 s persis pada titik yang default jendela iperf tes mendatar selamanya. Yang satu ini tentu saja timbangan untuk banyak dizzier ketinggian, tapi itu's penasaran yang ada's ini jeda dalam skala (Nilai 1022bytes * 512 = 523264) sebelum ia melakukannya.
Menindaklanjuti berbagai tanggapan:
O, jadi setelah op pada Kyle saran, I've diaktifkan ctcp dan cacat pembongkaran cerobong asap: Parameter Global TCP
----------------------------------------------
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
Tapi sayangnya, tidak ada perubahan dalam produktivitas. Saya tidak memiliki penyebab/efek pertanyaan di sini, meskipun: grafik dari nilai RWIN yang ditetapkan dalam server's ACKs untuk klien. Dengan klien Windows, apa aku benar berpikir bahwa Linux isn't skala nilai ini melampaui titik rendah karena klien's limited CWIN mencegah bahkan bahwa buffer sedang diisi? Mungkin ada beberapa alasan lain bahwa Linux adalah artifisial membatasi RWIN? Catatan: saya've mencoba menyalakan ECN untuk neraka itu, tetapi tidak ada perubahan, tidak ada.
Tidak ada perubahan berikut menonaktifkan heuristik dan RWIN autotuning. Telah diperbarui Intel jaringan driver terbaru (12.10.28.0) dengan perangkat lunak yang memperlihatkan functioanlity tweak viadevice manager tab. Kartu adalah 82579V Chipset on-board NIC - (I'm akan melakukan beberapa pengujian lebih lanjut dari klien dengan realtek atau vendor lainnya) Berfokus pada NIC untuk sesaat, aku've mencoba mengikuti (Kebanyakan hanya mengesampingkan kemungkinan penyebab):
Mencoba untuk menghilangkan Linux server side, saya mulai sebuah Server 2012R2 contoh dan mengulangi tes menggunakan iperf
(cygwin biner) dan NTttcp.
Dengan iperf
, saya harus secara eksplisit menentukan -w1m
pada kedua belah pihak sebelum sambungan akan berkembang melampaui ~5Mbit/s. (Kebetulan, saya dapat diperiksa dan BDP dari ~5Mbits di 91ms latency hampir justru 64kb. Spot batas...)
Yang ntttcp binari sekarang menunjukkan batasan-batasan tersebut. Menggunakan ntttcpr -m 1,0,1.2.3.5
pada server dan ntttcp -s -m 1,0,1.2.3.5 -t 10
pada klien, saya bisa melihat banyak throughput yang lebih baik:
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 menempatkan itu di tingkat saya mendapatkan secara eksplisit dengan jendela-jendela besar di iperf
. Anehnya, meskipun, 80MB di 1273 buffer = a 64kB penyangga lagi. Lebih lanjut wireshark menunjukkan, variabel RWIN datang kembali dari server (faktor Skala 256) bahwa klien tampaknya untuk memenuhi; jadi mungkin ntttcp adalah misreporting kirim jendela.
Di @karyhead's permintaan, I've dilakukan beberapa pengujian dan dihasilkan beberapa menangkap, berikut ini: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip
ntttcp
jejak dari klien Windows Server 2012R2 contoh EC2 (1.2.3.5). di sini, throughput skala baik. Catatan: NTttcp melakukan sesuatu yang aneh pada port 6001 sebelum membuka tes koneksi. Tidak yakin apa yang's terjadi di sana. /dev/urandom
ke dekat identik linux host (1.2.3.6) menggunakan Cygwin ncftp
. Lagi batas yang ada. Pola ini hampir sama dengan menggunakan Windows Filezilla.
Mengubah iperf
buffer suhu udara turun tidak membuat diharapkan perbedaan urutan waktu grafik (jauh lebih bagian vertikal), tetapi throughput yang sebenarnya adalah tidak berubah. Apakah anda mencoba mengaktifkan Senyawa TCP (CTCP) di Windows 7/8 klien.
Silakan baca:
Meningkatkan Pengirim-Sisi Kinerja Tinggi BDP Transmisi
http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx
...
algoritma Ini bekerja dengan baik untuk kecil BDPs dan yang lebih kecil menerima jendela ukuran. Namun, ketika anda memiliki koneksi TCP dengan besar menerima ukuran jendela dan besar BDP, seperti replikasi data antara dua server yang berlokasi di kecepatan tinggi WAN link dengan 100ms round-trip waktu, algoritma ini tidak meningkatkan mengirim jendela cukup cepat untuk sepenuhnya memanfaatkan bandwidth koneksi.
Untuk lebih memanfaatkan bandwidth koneksi TCP ini situasi, Generasi Berikutnya TCP/IP stack termasuk Senyawa TCP (CTCP). CTCP lebih agresif meningkatkan mengirim jendela untuk koneksi dengan besar menerima ukuran jendela dan BDPs. CTCP upaya untuk memaksimalkan throughput pada jenis koneksi dengan pemantauan penundaan variasi dan kerugian. Selain itu, CTCP memastikan bahwa perilaku tidak berdampak negatif lainnya koneksi TCP.
...
CTCP diaktifkan secara default di komputer yang menjalankan Windows Server 2008 dan dinonaktifkan oleh default di komputer yang menjalankan Windows Vista. Anda dapat mengaktifkan CTCP dengan
netsh interface tcp set global congestionprovider=ctcp
perintah. Anda dapat menonaktifkan CTCP dengannetsh interface tcp set global congestionprovider=tidak ada
perintah.
Edit 6/30/2014
untuk melihat apakah CTCP adalah benar-benar "on"
> netsh int tcp show global
yaitu
PO berkata:
Jika saya memahami ini dengan benar, pengaturan ini meningkatkan tingkat di yang tersumbat jendela membesar lebih dari ukuran maksimum dapat mencapai
CTCP agresif meningkatkan mengirim jendela
http://technet.microsoft.com/en-us/library/bb878127.aspx
Senyawa TCP
ada algoritma yang mencegah pengiriman TCP peer dari besar jaringan yang dikenal sebagai slow start dan kemacetan penghindaran. Algoritma ini meningkatkan jumlah segmen yang pengirim dapat mengirim, yang dikenal sebagai mengirim jendela, ketika awalnya mengirim data pada sambungan dan ketika pulih dari kehilangan segmen. Mulai lambat meningkatkan mengirim jendela dengan satu segmen TCP baik untuk masing-masing pengakuan segmen diterima (untuk TCP pada Windows XP dan Windows Server 2003) atau untuk setiap segmen mengakui (untuk TCP di Windows Vista dan Windows Server 2008). Menghindari kemacetan meningkatkan mengirim jendela dengan satu segmen TCP untuk masing-masing penuh jendela dari data yang diakui.
algoritma Ini bekerja dengan baik untuk LAN media kecepatan dan lebih kecil TCP window ukuran. Namun, ketika anda memiliki koneksi TCP dengan besar menerima ukuran jendela dan besar bandwidth-delay produk (bandwidth tinggi dan tinggi delay), seperti replikasi data antara dua server yang berlokasi di kecepatan tinggi WAN link dengan 100 ms round trip time, ini algoritma tidak meningkatkan mengirim jendela cukup cepat untuk sepenuhnya memanfaatkan bandwidth koneksi. Misalnya, pada 1 Gigabit per detik (Gbps) WAN link dengan 100 ms round trip time (RTT), dapat memakan waktu hingga satu jam untuk mengirim ke jendela awalnya meningkatkan ke besar ukuran jendela yang diiklankan oleh penerima dan untuk memulihkan ketika ada yang hilang segmen.
Untuk lebih memanfaatkan bandwidth koneksi TCP ini situasi, Generasi Berikutnya TCP/IP stack termasuk Senyawa TCP (CTCP). CTCP lebih agresif meningkatkan mengirim jendela untuk koneksi dengan besar menerima ukuran jendela dan besar bandwidth-delay produk. CTCP upaya untuk memaksimalkan throughput pada jenis koneksi dengan pemantauan penundaan variasi dan kerugian. CTCP juga memastikan bahwa perilakunya tidak berdampak negatif lainnya TCP koneksi.
Dalam pengujian yang dilakukan secara internal di Microsoft, besar file backup kali yang berkurang hampir setengah untuk 1 Gbps koneksi dengan 50ms RTT. Koneksi dengan bandwidth yang lebih besar penundaan produk dapat memiliki lebih baik kinerja. CTCP dan Menerima Window Auto-Tuning bekerja bersama-sama untuk meningkat link pemanfaatan dan dapat mengakibatkan kinerja substansial keuntungan untuk besar bandwidth-delay produk koneksi.
TCP memiliki dua jendela:
Dalam penangkapan file yang anda berikan. Kita dapat melihat bahwa menerima buffer tidak pernah dipenuhi:
Analisis saya adalah bahwa pengirim isn't pengiriman cukup cepat karena mengirim jendela (alias kemacetan jendela kontrol) isn't membuka cukup untuk memenuhi RWIN penerima. Jadi singkatnya penerima mengatakan "Memberi saya Lebih banyak", dan ketika Windows pengirim isn't pengiriman cukup cepat.
Hal ini dibuktikan oleh fakta bahwa di atas grafik RWIN tetap terbuka, dan dengan perjalanan waktu .09 detik dan RWIN dari ~ 500,000 byte kita bisa mengharapkan max throughput bandwidth delay produk yang akan (500000/0.09) * 8 =~ 42 Mbit/s (dan anda hanya mendapatkan sekitar ~5 di win anda untuk Linux capture).
Saya don't tahu. interface tcp set global congestionprovider=ctcp
terdengar seperti hal yang benar untuk lakukan untuk saya karena itu akan meningkatkan mengirim jendela (yang merupakan istilah lain untuk congestion window). Anda mengatakan bahwa isn't bekerja. Jadi hanya untuk memastikan:
netsh interface tcp menunjukkan heuristik
. Saya berpikir bahwa mungkin RWIN, tapi itu doesn't mengatakan, jadi mungkin bermain dengan menonaktifkan/mengaktifkan bahwa dalam kasus itu dampak mengirim jendela.Saya akan mencoba semua percobaan ini dengan semua yang anda offloading fitur off untuk mulai dengan, untuk menghilangkan kemungkinan bahwa driver jaringan yang melakukan beberapa rewriting/memodifikasi hal-hal (mengawasi CPU saat pembongkaran dinonaktifkan). The [TCP_OFFLOAD_STATE_DELEGATED struct][2] tampaknya setidaknya menyiratkan bahwa CWnd pembongkaran setidaknya mungkin.
[2]: http://msdn.microsoft.com/en-us/library/windows/hardware/ff570939(v=vs. 85).aspx
Ada's telah beberapa informasi yang besar di sini by @Pat dan @Kyle. Pasti memperhatikan @Kyle's penjelasan TCP menerima dan mengirim windows, saya pikir ada beberapa kebingungan di sekitar itu. Untuk membingungkan masalah lebih lanjut, iperf menggunakan istilah "TCP window" dengan w
pengaturan yang agak ambigu istilah berkaitan dengan menerima, mengirim, atau secara keseluruhan jendela geser. Apa yang sebenarnya adalah mengatur soket mengirim buffer untuk -c
(klien) contoh dan soket menerima buffer pada -s
(server) misalnya. Di 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 ));
}
Sebagai Kyle menyebutkan, masalah ini isn't dengan menerima window di Linux box, tapi pengirim isn't membuka mengirim jendela yang cukup. It's tidak bahwa itu doesn't membuka cukup cepat, hanya topi di 64k. Default socket ukuran buffer pada Windows 7 adalah 64k. Berikut ini's apa dokumentasi yang mengatakan tentang socket ukuran buffer dalam kaitannya dengan throughput pada [BACA][2]
Saat mengirim data melalui sebuah koneksi TCP menggunakan soket Windows, hal ini penting untuk menjaga jumlah data yang cukup luar biasa (dikirim tapi tidak mengakui belum) di TCP dalam rangka mencapai tertinggi throughput. Nilai ideal untuk jumlah data yang luar biasa untuk mencapai throughput yang terbaik untuk koneksi TCP disebut ideal kirim backlog (ISB) ukuran. ISB nilai adalah fungsi dari bandwidth-delay produk dari koneksi TCP dan penerima's diiklankan menerima jendela (dan sebagian jumlah kemacetan di network). Ok, bla bla bla, Sekarang di sini kita pergi: Aplikasi yang melakukan satu memblokir atau non-blocking mengirim permintaan di waktu biasanya bergantung pada internal mengirim buffer dengan Winsock untuk mencapai layak throughput. Kirim penyangga batas untuk suatu koneksi dikendalikan oleh SO_SNDBUF soket pilihan. Untuk memblokir dan non-blocking mengirim metode, kirim penyangga batas menentukan berapa banyak data disimpan beredar di TCP. Jika ISB nilai untuk koneksi lebih besar daripada mengirim buffer batas, maka produktivitas yang dicapai pada koneksi tidak akan optimal. Throughput rata-rata yang paling baru-baru ini iperf tes menggunakan 64k jendela 5.8 Mbps. Yang's dari Statistik > Ringkasan di Wireshark, yang menghitung semua bit. Mungkin, iperf adalah menghitung TCP throughput data yang lebih 5.7 Mbps. Kita melihat kinerja yang sama dengan FTP tes juga, ~5.6 Mbps. Teori throughput dengan 64k mengirim buffer dan 91ms RTT adalah....5.5 Mbps. Cukup dekat untuk saya. Jika kita melihat 1MB jendela iperf tes, output adalah 88.2 Mbps (86.2 Mbps untuk hanya data TCP). Teori output dengan 1MB jendela 87.9 Mbps. Lagi, cukup dekat untuk bekerja di pemerintahan. Apa ini menunjukkan bahwa mengirim buffer soket langsung mengontrol mengirim jendela dan itu, ditambah dengan jendela menerima dari sisi lain, kontrol throughput. Diiklankan menerima jendela memiliki ruang, jadi kami're tidak terbatas oleh penerima. Terus, bagaimana ini autotuning bisnis? Doesn't Windows 7 menangani hal-hal itu secara otomatis? Seperti yang telah disebutkan, Windows tidak menangani auto-scaling dari jendela menerima, tetapi juga dapat secara dinamis menangani buffer kirim juga. Let's kembali ke MSDN halaman: Dinamis mengirim buffer untuk TCP ditambahkan pada Windows 7 dan Windows Server 2008 R2. Secara default, dinamis mengirim buffer untuk TCP diaktifkan kecuali aplikasi set SO_SNDBUF soket pilihan di sungai socket. iperf menggunakan
SO_SNDBUF
ketika menggunakanw
pilihan, begitu dinamis mengirim buffer akan dinonaktifkan. Namun, jika anda don't menggunakanw
maka itu doesn't menggunakanSO_SNDBUF
. Dinamis mengirim buffer harus diaktifkan secara default, tetapi anda dapat memeriksa:
netsh winsock show autotuning
Dokumentasi mengatakan anda dapat menonaktifkannya dengan:
netsh winsock set autotuning off
Tapi itu tidak't bekerja untuk saya. Saya harus membuat perubahan registri dan set ke 0:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DynamicSendBufferDisable
Saya don't pikir menonaktifkan ini akan membantu; it's just FYI.
Mengapa isn't anda mengirim buffer skala di atas default 64k ketika mengirimkan data ke kotak Linux dengan banyak ruang dalam menerima jendela? Pertanyaan besar. Linux kernel juga memiliki autotuning TCP stack. Seperti T-Pain dan Kanye melakukan autotune duet bersama-sama, itu hanya mungkin tidak terdengar baik. Mungkin ada's beberapa masalah dengan dua autotuning TCP tumpukan berbicara satu sama lain.
Orang lain punya masalah sama seperti milik anda dan mampu memperbaikinya dengan mengedit registry untuk meningkatkan standar ukuran buffer kirim. Sayangnya, yang doesn't tampaknya bekerja lagi, setidaknya itu didn't untuk saya ketika saya mencoba itu.
Pada titik ini, saya pikir itu's jelas faktor pembatas adalah mengirim ukuran buffer di host Windows. Mengingat bahwa itu doesn't tampaknya akan tumbuh secara dinamis dengan benar, apa yang's seorang gadis yang harus dilakukan?
Anda dapat:
Setelah anda memiliki TCP stack disetel, anda mungkin masih memiliki hambatan dalam Winsock lapisan. Saya telah menemukan bahwa konfigurasi Winsock (Fungsi Tambahan Driver di registry) membuat perbedaan besar untuk kecepatan upload (mendorong data ke server) di Windows 7. Microsoft telah mengakui bug dalam TCP autotuning untuk non-blocking soket-hanya jenis soket yang menggunakan browser ;-)
Tambahkan DWORD key untuk DefaultSendWindow dan set ke BDP atau lebih tinggi. Saya menggunakan 256000.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters\DefaultSendWindow
Mengubah Winsock pengaturan untuk popularitas mungkin bisa membantu - tambahkan tombol untuk DefaultReceiveWindow.
Anda dapat melakukan percobaan dengan berbagai soket tingkat pengaturan dengan menggunakan Fiddler Proxy dan perintah untuk mengatur klien dan server socket ukuran penyangga:
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
Setelah membaca semua analisa jawaban, masalah ini sangat banyak suara seperti anda mungkin menjalankan Windows7/2008R2 alias Windows 6.1
Networking stack (TCP/IP & Winsock) di Windows 6.1 mengerikan cacat dan memiliki seluruh host bug dan masalah kinerja yang Microsoft akhirnya ditangani selama bertahun-tahun hotfixing sejak rilis awal 6.1.
Cara terbaik untuk menerapkan perbaikan terbaru ini adalah untuk secara manual menyaring melalui semua halaman yang relevan di support.microsoft.com dan manual permintaan dan men-download versi LDR network stack perbaikan (ada banyak puluhan ini).
Untuk menemukan relevan perbaikan terbaru, anda harus menggunakan www.bing.com dengan kueri penelusuran berikut
site:support.microsoft.com 6.1.7601 tcpip.sys
Anda juga perlu memahami bagaimana LDR/GDR perbaikan kereta api bekerja di Windows 6.1
Saya umumnya digunakan untuk menjaga saya sendiri daftar LDR perbaikan (bukan hanya tumpukan jaringan perbaikan) untuk Windows 6.1 dan kemudian secara proaktif menerapkan perbaikan untuk Windows 6.1 server/client yang saya datang di. Itu sangat memakan waktu tugas untuk secara teratur memeriksa baru LDR perbaikan terbaru.
Untungnya, Microsoft telah menghentikan praktek LDR pembaruan dengan versi OS yang lebih baru dan perbaikan bug yang sekarang tersedia melalui update otomatis layanan dari Microsoft.
UPDATE: Hanya satu contoh dari banyak jaringan bug di Windows7SP1 - https://support.microsoft.com/en-us/kb/2675785
UPDATE 2: Berikut's lain perbaikan terbaru yang menambahkan netsh beralih untuk memaksa Window scaling setelah kedua transmisi ulang sebuah paket SYN (secara default, jendela scaling dinonaktifkan setelah 2 paket SYN yang disiarkan) https://support.microsoft.com/en-us/kb/2780879
Saya melihat ini adalah sedikit posting yang lebih tua tapi bisa membantu orang lain.
Singkatnya anda harus mengaktifkan "Menerima Window Auto-Tuning":
netsh int tcp set global autotuninglevel=normal
CTCP berarti apa-apa tanpa di atas diaktifkan.
Jika anda menonaktifkan "Menerima Window Auto-Tuning" anda akan terjebak di 64KB ukuran paket yang memiliki dampak negatif yang lebih panjang RTT's tinggi koneksi broadband. Anda juga dapat bereksperimen dengan "terbatas" dan "highlyrestricted" opsi.
Sangat baik untuk referensi: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html
Saya mengalami masalah yang sama dengan Klien Windows (Windows 7). Aku pergi melalui sebagian debugging anda telah pergi melalui, menonaktifkan Nagle algorithm, TCP Pembongkaran Cerobong asap, dan banyak lainnya TCP terkait perubahan pengaturan. Bebas dari mereka memiliki efek apapun.
Apa yang akhirnya tetap itu bagi saya adalah memodifikasi default mengirim jendela registry dari AFD layanan. Masalah ini tampaknya terkait dengan afd.sys file. Saya diuji beberapa klien, beberapa dipamerkan lambat tanggal, dan beberapa didn't, tapi semua Windows 7 mesin. Mesin-mesin yang dipamerkan lambat perilaku memiliki versi yang sama AFD.sys. Registry solusi yang dibutuhkan untuk komputer dengan versi tertentu dari AFD.sys (maaf, tidak ingat versi #'s).
HKLM\CurrentControlSet\Services\AFD\Parameters
Add - DWORD - DefaultSendWindow
Nilai - Desimal - 1640960
Nilai itu adalah sesuatu yang saya ditemukan di sini: https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-
Saya berpikir untuk menggunakan nilai yang tepat, anda harus menghitung sendiri menggunakan:
misalnya. Diiklankan Tanggal: 15 Mbps = 15,000 Kbps
(15000 / 8 ) * 1024 = 1920000
Dari apa yang saya mengerti, perangkat lunak klien harus menimpa pengaturan ini dalam registry, tapi jika mereka don't, nilai default yang akan digunakan, dan rupanya default adalah nilai yang sangat rendah dalam beberapa versi AFD.sys file.
Saya melihat bahwa sebagian besar MS produk telah lambat tanggal masalah (YAITU, Mini-redirector(WebDAV), FTP melalui Windows Explorer, dll...) Bila menggunakan 3rd party software (ex. Filezilla) yang saya lakukan sama sekali tidak lambat-downs.
Yang AFD.sys efek semua koneksi Winsock, sehingga perbaikan ini harus berlaku untuk FTP, HTTP, HTTPS, dll...
Juga, perbaikan ini tercantum di atas suatu tempat yang baik, jadi saya don't ingin mengambil kredit untuk itu jika ia bekerja untuk siapa pun, namun ada begitu banyak informasi di thread ini yang aku takut itu mungkin telah dipoles.
Yah, aku've mengalami situasi yang sama diriku sendiri (pertanyaan saya di sini), dan pada akhirnya saya harus menonaktifkan TCP scaling heuristik, secara manual mengatur autotuning profil dan mengaktifkan CTCP:
# 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.
Saya don't memiliki cukup poin untuk komentar, jadi saya'll posting "menjawab" sebagai gantinya. I'm memiliki apa yang muncul untuk menjadi serupa/identik masalah (lihat serverfault pertanyaan di sini). Saya (dan mungkin anda) masalah adalah mengirim buffer dari iperf client pada windows. Itu tidak tumbuh melampaui 64 KB. Windows seharusnya tumbuh secara dinamis buffer ketika itu tidak secara eksplisit berukuran sedang oleh proses. Tapi yang dinamis pertumbuhan tidak terjadi.
I'm tidak yakin tentang jendela skala grafik yang menunjukkan pembukaan jendela hingga 500.000 byte untuk anda "lambat" Windows kasus. Saya berharap untuk melihat bahwa grafik terbuka untuk hanya ~64,000 byte mengingat bahwa anda terbatas untuk 5 Mbps.
Ini adalah menarik benang dan sama persis dengan masalah yang saya've telah menggunakan Win7/iperf untuk menguji throughput pada panjang pipa lemak.
Solusi untuk Windows 7 adalah dengan mengeksekusi perintah berikut pada kedua iperf server DAN klien.
netsh interface tcp set global autotuninglevel=eksperimental
NB: Sebelum anda melakukan ini, pastikan untuk merekam status autotuning:
netsh interface tcp acara global
Menerima Window Auto-Tuning Level : disabled
Kemudian menjalankan iperf server/client di masing-masing ujung pipa.
Reset autotuning nilai yang mengikuti tes anda:
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.