Windows TCP Window Scaling กดปุ่มที่ราบสูงเร็วเกินไป

สถานการณ์จำลอง: เรามีลูกค้า Windows จำนวนมากที่อัปโหลดไฟล์ขนาดใหญ่เป็นประจำ (FTP / SVN / HTTP PUT / SCP) ไปยังเซิร์ฟเวอร์ Linux ที่อยู่ห่างออกไป ~ 100-160ms เรามีแบนด์วิดท์แบบซิงโครนัส 1Gbit / s ที่สำนักงานและเซิร์ฟเวอร์เป็นอินสแตนซ์ AWS หรือโฮสต์ในสหรัฐอเมริกา DC

รายงานเริ่มต้นคือการอัปโหลดไปยังอินสแตนซ์ของเซิร์ฟเวอร์ใหม่ช้ากว่าที่ควรจะเป็น นี่เป็นสิ่งที่น่าเบื่อในการทดสอบและจากหลาย ๆ สถานที่ ลูกค้าเห็นเสถียรภาพ 2-5Mbit / s ไปยังโฮสต์จากระบบ Windows ของพวกเขา

ฉันโพiperf -sสต์อินสแตนซ์ AWS แล้วจากไคลเอนต์Windowsในสำนักงาน:

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

ตัวเลขหลังสามารถแตกต่างกันอย่างมีนัยสำคัญในการทดสอบครั้งต่อไป (Vagaries of AWS) แต่มักจะอยู่ระหว่าง 70 และ 130Mbit / s ซึ่งเกินพอสำหรับความต้องการของเรา เมื่อเห็นเซสชั่นฉันสามารถดู:

• iperf -c Windows SYN - หน้าต่าง 64kb, สเกล 1 - Linux SYN, ACK: หน้าต่าง 14kb, สเกล: 9 (* 512)
• iperf -c -w1M Windows SYN - Windows 64kb, สเกล 1 - Linux SYN, ACK: หน้าต่าง 14kb, สเกล: 9

เห็นได้ชัดว่าการเชื่อมโยงสามารถรักษาปริมาณงานสูง แต่ฉันต้องอธิบายขนาดของหน้าต่างเพื่อใช้ประโยชน์จากมันซึ่งแอพพลิเคชั่นโลกแห่งความเป็นจริงส่วนใหญ่จะไม่ยอมให้ฉันทำ Handshakes TCP ใช้จุดเริ่มต้นเดียวกันในแต่ละกรณี แต่บังคับหนึ่งสเกล

ในทางกลับกันจากไคลเอนต์ Linux บนเครือข่ายเดียวกันเป็นเส้นตรงiperf -c(โดยใช้ค่าเริ่มต้นของระบบ 85kb) ให้ฉัน:

[  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

มันจะขยายตามที่คาดไว้ นี่ไม่ใช่สิ่งที่จะเกิดขึ้นในระหว่างการกระโดดหรือสวิตช์ / เราเตอร์ในพื้นที่ของเราและดูเหมือนว่าจะมีผลกับไคลเอนต์ Windows 7 และ 8 เหมือนกัน ฉันได้อ่านคำแนะนำมากมายเกี่ยวกับการปรับจูนอัตโนมัติ แต่โดยทั่วไปแล้วสิ่งเหล่านี้เกี่ยวกับการปิดใช้งานการปรับสเกลพร้อมกันเพื่อหลีกเลี่ยงชุดเครือข่ายในบ้านที่แย่มาก

ใครสามารถบอกฉันว่าเกิดอะไรขึ้นที่นี่และให้วิธีการแก้ไขกับฉันได้ไหม (โดยเฉพาะอย่างยิ่งสิ่งที่ฉันสามารถติดในรีจิสทรีผ่าน GPO)

หมายเหตุ

อินสแตนซ์ AWS Linux ที่เป็นปัญหามีการใช้การตั้งค่าเคอร์เนลต่อไปนี้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

ฉันใช้การdd if=/dev/zero | ncเปลี่ยนเส้นทางไป/dev/nullที่จุดสิ้นสุดของเซิร์ฟเวอร์เพื่อแยกแยะiperfและลบคอขวดที่เป็นไปได้อื่น ๆ แต่ผลลัพธ์จะเหมือนกันมาก การทดสอบด้วยระดับncftp(Cygwin, Native Windows, Linux) ในลักษณะเดียวกับการทดสอบ iperf ด้านบนบนแพลตฟอร์มที่เกี่ยวข้อง

แก้ไข

ฉันพบสิ่งที่สอดคล้องกันอีกครั้งที่นี่ซึ่งอาจเกี่ยวข้อง:

นี่เป็นวินาทีแรกของการจับ 1MB ที่ซูมเข้าคุณสามารถเห็นการทำงานเริ่มช้าในขณะที่หน้าต่างขยายและบัฟเฟอร์ใหญ่ขึ้น นอกจากนี้แล้วนี้ที่ราบเล็ก ๆ ของ ~ 0.2s ตรงที่จุดที่การทดสอบหน้าต่างเริ่มต้น iperf flattens ออกไปตลอดกาล หลักสูตรนี้ปรับให้สูงขึ้นมาก แต่สงสัยว่ามีการหยุดชั่วคราวในการปรับขนาด (ค่า 1022bytes * 512 = 523264) ก่อนที่จะทำเช่นนั้น

อัปเดต - 30 มิถุนายน

ติดตามการตอบสนองต่าง ๆ :

• การเปิดใช้งาน CTCP - สิ่งนี้ไม่สร้างความแตกต่าง การปรับขนาดหน้าต่างเหมือนกัน (ถ้าฉันเข้าใจสิ่งนี้อย่างถูกต้องการตั้งค่านี้จะเพิ่มอัตราการขยายหน้าต่างคับคั่งแทนที่จะเป็นขนาดสูงสุดที่สามารถเข้าถึงได้)
• การเปิดใช้งานการประทับเวลา TCP - ไม่มีการเปลี่ยนแปลงที่นี่เช่นกัน
• อัลกอริทึมของ Nagle - มันสมเหตุสมผลแล้วและอย่างน้อยก็หมายความว่าฉันอาจเพิกเฉยต่อการผิดพลาดนั้นในกราฟเพื่อบ่งบอกถึงปัญหา
• ไฟล์ pcap: มีไฟล์ซิปที่นี่: https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip (ไม่ระบุชื่อด้วย bittwiste แยกเป็น ~ 150MB หนึ่งรายการจากไคลเอนต์แต่ละระบบปฏิบัติการสำหรับการเปรียบเทียบ)

อัปเดต 2 - 30 มิถุนายน

O ดังนั้นเมื่อ op ตามคำแนะนำของ Kyle ฉันได้เปิดใช้งาน ctcp และปิดใช้งานการถ่ายปล่องไฟ: 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

แต่น่าเศร้าที่ไม่มีการเปลี่ยนแปลงในปริมาณงาน

ฉันมีคำถามสาเหตุ / ผลที่นี่ แต่: กราฟเป็นค่า RWIN ที่ตั้งค่าใน ACK ของเซิร์ฟเวอร์ไปยังลูกค้า ด้วยไคลเอนต์ Windows ฉันคิดถูกว่า Linux ไม่ได้ปรับค่านี้เกินกว่าจุดต่ำสุดเนื่องจากไคลเอนต์ที่ จำกัด ของ CWIN จะป้องกันไม่ให้บัฟเฟอร์นั้นเต็ม มีเหตุผลอื่นอีกไหมที่ลีนุกซ์ จำกัด การใช้ RWIN อย่างผิด ๆ ?

หมายเหตุ: ฉันได้ลองเปิดใช้งาน ECN เพื่อหาขุมทรัพย์ของมันแล้ว แต่ไม่มีการเปลี่ยนแปลงที่นั่น

อัปเดต 3 - 31 มิถุนายน

ไม่มีการเปลี่ยนแปลงหลังจากปิดใช้งานการวิเคราะห์พฤติกรรมและการสลับอัตโนมัติของ RWIN ได้อัพเดตไดร์เวอร์เครือข่าย Intel เป็นเวอร์ชั่นล่าสุด (12.10.28.0) ด้วยซอฟต์แวร์ที่แสดงให้เห็นถึงความสามารถในการปรับแต่งแท็บ viadevice manager การ์ดดังกล่าวเป็นชิปเซ็ต 82579V บนเมนบอร์ด NIC - (ฉันจะทำการทดสอบเพิ่มเติมจากลูกค้าที่มี realtek หรือผู้ขายรายอื่น)

มุ่งเน้นไปที่ NIC สักครู่ฉันได้ลองทำสิ่งต่อไปนี้ (ส่วนใหญ่จะตัดสินผู้กระทำผิดที่ไม่น่าจะเกิดขึ้น):

• เพิ่มบัฟเฟอร์รับเป็น 2k จาก 256 และส่งบัฟเฟอร์เป็น 2k จาก 512 (ทั้งสองตอนนี้สูงสุด) - ไม่มีการเปลี่ยนแปลง
• ปิดใช้งานการตรวจสอบการถ่ายโอนข้อมูล IP / TCP / UDP ทั้งหมด - ไม่มีการเปลี่ยนแปลง.
• ปิดใช้งานการส่งข้อมูลขนาดใหญ่ - Nada
• ปิดใช้งาน IPv6, QoS scheduling - Nowt

อัปเดต 3 - 3 กรกฎาคม

พยายามที่จะกำจัดฝั่งเซิร์ฟเวอร์ Linux ผมเริ่มต้นขึ้นอินสแตนซ์เซิร์ฟเวอร์ 2012R2 และทำซ้ำการทดสอบโดยใช้iperf(ไบนารี Cygwin) และNTttcp

ด้วยiperfผมก็มีการระบุอย่างชัดเจน-w1mเกี่ยวกับทั้งสองฝ่ายก่อนที่จะเชื่อมต่อจะขนาดเกิน ~ 5Mbit / s (บังเอิญฉันสามารถตรวจสอบได้และ BDP ของ ~ 5Mbits ที่ 91ms latency เกือบ 64kb แม่นยำแม่นยำ จำกัด วงเงิน ... )

ไบนารี ntttcp แสดงข้อ จำกัด ดังกล่าวในขณะนี้ ntttcpr -m 1,0,1.2.3.5เมื่อใช้บนเซิร์ฟเวอร์และntttcp -s -m 1,0,1.2.3.5 -t 10บนไคลเอนต์ฉันสามารถดูปริมาณงานได้ดีขึ้นมาก:

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 / iperfวินาทีทำให้มันขึ้นมาในระดับที่ผมได้รับมีหน้าต่างบานใหญ่อย่างชัดเจนใน แม้ว่าจะผิดปกติ 80MB ใน 1273 บัฟเฟอร์ = บัฟเฟอร์ 64kB อีกครั้ง การเปลี่ยนแปลงเพิ่มเติมแสดงให้เห็นว่าตัวแปร RWIN ที่ดีนั้นกลับมาจากเซิร์ฟเวอร์ (ตัวประกอบขนาด 256) ที่ไคลเอ็นต์ดูเหมือนว่าจะเติมเต็ม ดังนั้นบางที ntttcp กำลังส่งหน้าต่างส่งผิด

อัพเดท 4 - 3 กรกฎาคม

ตามคำขอของ @ karyhead ฉันได้ทำการทดสอบเพิ่มเติมและสร้างการบันทึกเพิ่มเติมอีกสองสามรายการที่นี่: https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zip

• อีกสองiperfs ทั้งจาก Windows ไปยังเซิร์ฟเวอร์ Linux เดียวกันเช่นก่อน (1.2.3.4): หนึ่งที่มีขนาดซ็อกเก็ต 128k และหน้าต่าง 64k เริ่มต้น (จำกัด ถึง ~ 5Mbit / s อีกครั้ง) และหนึ่งที่มีหน้าต่างส่ง 1MB และซ็อกเก็ต 8kb เริ่มต้น ขนาด. (ตาชั่งที่สูงกว่า)
• หนึ่งการntttcpติดตามจากไคลเอนต์ Windows เดียวกันกับอินสแตนซ์ของเซิร์ฟเวอร์ 2012R2 EC2 (1.2.3.5) ที่นี่ปริมาณงานก็ขยายตัวได้ดี หมายเหตุ: NTttcp ทำสิ่งผิดปกติบนพอร์ต 6001 ก่อนที่จะเปิดการเชื่อมต่อทดสอบ ไม่แน่ใจว่าเกิดอะไรขึ้น
• หนึ่ง FTP ร่องรอยข้อมูล 20MB อัพโหลด/dev/urandomไปยังโฮสต์อยู่ใกล้กับลินุกซ์เหมือนกัน (1.2.3.6) โดยใช้ ncftpCygwin มีการ จำกัด อีกครั้ง รูปแบบเหมือนกันมากโดยใช้ Windows Filezilla

การเปลี่ยนiperfความยาวบัฟเฟอร์ทำให้เกิดความแตกต่างตามที่คาดไว้กับกราฟลำดับเวลา (ส่วนแนวตั้งอื่น ๆ อีกมากมาย) แต่ปริมาณงานที่แท้จริงไม่เปลี่ยนแปลง

คุณได้ลองเปิดใช้งานCompound TCP (CTCP) ในไคลเอนต์ Windows 7/8 ของคุณแล้วหรือยัง

กรุณาอ่าน:

การเพิ่มประสิทธิภาพด้านผู้ส่งสำหรับการส่งข้อมูล BDP สูง

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

...

อัลกอริทึมเหล่านี้ทำงานได้ดีสำหรับBDP ขนาดเล็กและขนาดหน้าต่างรับที่เล็กกว่า อย่างไรก็ตามเมื่อคุณมีการเชื่อมต่อ TCP ที่มีขนาดหน้าต่างรับขนาดใหญ่และBDP ขนาดใหญ่เช่นการจำลองข้อมูลระหว่างเซิร์ฟเวอร์สองเครื่องที่อยู่ในลิงค์ WANความเร็วสูงที่มีเวลาเดินทางรอบ 100msอัลกอริธึมเหล่านี้จะไม่เพิ่มหน้าต่างส่ง เร็วพอที่จะใช้ประโยชน์อย่างเต็มที่แบนด์วิดธ์ของการเชื่อมต่อ

เมื่อต้องการใช้แบนด์วิดท์ของการเชื่อมต่อ TCP ในสถานการณ์เหล่านี้ได้ดีขึ้นสแต็ก TCP / IP รุ่นใหม่จะรวม Compound TCP (CTCP) CTCP จะเพิ่มหน้าต่างการส่งสำหรับ การเชื่อมต่อที่มีขนาดหน้าต่างรับและ BDP ขนาดใหญ่ขึ้น CTCP พยายามเพิ่มปริมาณงานสูงสุดในการเชื่อมต่อประเภทนี้โดยการตรวจสอบความแปรปรวนของความล่าช้าและการสูญเสีย นอกจากนี้ CTCP รับรองว่าพฤติกรรมของมันจะไม่ส่งผลเสียต่อการเชื่อมต่อ TCP อื่น ๆ

...

CTCP ถูกเปิดใช้งานตามค่าเริ่มต้นในคอมพิวเตอร์ที่ใช้ Windows Server 2008 และปิดใช้งานโดยค่าเริ่มต้นในคอมพิวเตอร์ที่ใช้ Windows Vista คุณสามารถเปิดใช้งาน CTCP ด้วยnetsh interface tcp set global congestionprovider=ctcpคำสั่ง คุณสามารถปิดการใช้งาน CTCP ด้วยnetsh interface tcp set global congestionprovider=noneคำสั่ง

แก้ไข 6/30/2014

เพื่อดูว่า CTCP เป็น "เปิด" จริงหรือไม่

> netsh int tcp show global

กล่าวคือ

PO กล่าวว่า:

หากฉันเข้าใจสิ่งนี้อย่างถูกต้องการตั้งค่านี้จะเพิ่มอัตรา การขยายหน้าต่างคับคั่งแทนที่จะเป็นขนาดสูงสุดที่ สามารถเข้าถึงได้

CTCP เพิ่มหน้าต่างการส่งอย่างจริงจัง

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

Compound TCP

อัลกอริทึมที่มีอยู่ซึ่งป้องกันการส่ง TCP เพียร์จากเครือข่ายที่เรียกว่าการเริ่มต้นช้าและการหลีกเลี่ยงความแออัด อัลกอริทึมเหล่านี้เพิ่มจำนวนของเซกเมนต์ที่ผู้ส่งสามารถส่งเรียกว่าหน้าต่างส่งเมื่อเริ่มส่งข้อมูลในการเชื่อมต่อและเมื่อกู้คืนจากเซ็กเมนต์ที่หายไป การเริ่มต้นช้าเพิ่มหน้าต่างการส่งโดยหนึ่งส่วน TCP แบบเต็มสำหรับแต่ละส่วนการตอบรับที่ได้รับ (สำหรับ TCP ใน Windows XP และ Windows Server 2003) หรือสำหรับแต่ละส่วนที่รับทราบ (สำหรับ TCP ใน Windows Vista และ Windows Server 2008) การหลีกเลี่ยงความแออัดเพิ่มหน้าต่างการส่งโดยหนึ่งส่วน TCP เต็มสำหรับแต่ละหน้าต่างแบบเต็มของข้อมูลที่ได้รับการยอมรับ

อัลกอริทึมเหล่านี้ทำงานได้ดีสำหรับความเร็วสื่อ LAN และขนาดหน้าต่าง TCP ที่เล็กลง อย่างไรก็ตามเมื่อคุณมีการเชื่อมต่อ TCP ที่มีขนาดหน้าต่างรับขนาดใหญ่และผลิตภัณฑ์ที่มีแบนด์วิดท์ล่าช้าขนาดใหญ่ (แบนด์วิดท์สูงและความล่าช้าสูง) เช่นการเรพลิเคทข้อมูลระหว่างเซิร์ฟเวอร์สองเครื่องที่อยู่ในลิงค์ WAN ความเร็วสูง เวลาอัลกอริธึมเหล่านี้ไม่เพิ่มหน้าต่างส่งเร็วพอที่จะใช้แบนด์วิดท์ของการเชื่อมต่อได้อย่างเต็มที่ ตัวอย่างเช่นในลิงค์ 1 กิกะบิตต่อวินาที (Gbps) WAN ที่มีเวลาไปกลับ 100 มิลลิวินาที (RTT) อาจ ใช้เวลาหนึ่งชั่วโมงสำหรับหน้าต่างส่งเพื่อเพิ่ม ขนาดหน้าต่างใหญ่ที่เริ่มรับโฆษณา เพื่อกู้คืนเมื่อ มีเซ็กเมนต์ที่สูญหาย

เพื่อให้สามารถใช้แบนด์วิดท์ของการเชื่อมต่อ TCP ในสถานการณ์เหล่านี้ได้ดีขึ้นสแต็ก TCP / IP ยุคใหม่จะรวมCompound TCP (CTCP) CTCP จะเพิ่มหน้าต่างการส่งสำหรับการเชื่อมต่อที่มีขนาดหน้าต่างรับขนาดใหญ่และผลิตภัณฑ์ที่มีแบนด์วิดท์ล่าช้ามาก CTCP พยายามที่จะเพิ่มการส่งผ่านข้อมูลในประเภทนี้ของการเชื่อมต่อโดยการตรวจสอบรูปแบบความล่าช้าและการสูญเสีย CTCP ยังทำให้มั่นใจได้ว่าพฤติกรรมของมันจะไม่ส่งผลเสียต่อการเชื่อมต่อ TCP อื่น ๆ

ในการทดสอบดำเนินการภายใน Microsoft เวลาสำรองไฟล์จำนวนมากลดลงเกือบครึ่งสำหรับการเชื่อมต่อ 1 Gbps ด้วย RTMS 50ms การเชื่อมต่อกับผลิตภัณฑ์ที่ล่าช้าของแบนด์วิดท์ขนาดใหญ่สามารถมีประสิทธิภาพที่ดียิ่งขึ้น CTCP และ Receive Window Auto-Tuning ทำงานร่วมกันเพื่อเพิ่มการใช้ลิงค์และสามารถเพิ่มประสิทธิภาพได้อย่างมากสำหรับการเชื่อมต่อกับผลิตภัณฑ์ที่มีแบนด์วิดท์ล่าช้าขนาดใหญ่

ชี้แจงปัญหา:

TCP มีสองหน้าต่าง:

• หน้าต่างรับ: จำนวนไบต์ที่เหลืออยู่ในบัฟเฟอร์ นี่คือการควบคุมการไหลที่กำหนดโดยผู้รับ คุณสามารถดูขนาดของหน้าต่างการรับใน wireshark เนื่องจากมันประกอบด้วยขนาดของหน้าต่างและปัจจัยการปรับขนาดของหน้าต่างภายในส่วนหัว TCP ทั้งสองด้านของการเชื่อมต่อ TCP จะโฆษณาหน้าต่างรับของพวกเขา แต่โดยทั่วไปคนที่คุณใส่ใจคือคนที่ได้รับข้อมูลจำนวนมาก ในกรณีของคุณมันคือ "เซิร์ฟเวอร์" เนื่องจากไคลเอ็นต์กำลังอัปโหลดไปยังเซิร์ฟเวอร์
• หน้าต่างแออัด นี่คือการควบคุมการไหลที่กำหนดโดยผู้ส่ง สิ่งนี้ถูกดูแลโดยระบบปฏิบัติการและไม่แสดงในส่วนหัว TCP มันควบคุมอัตราความเร็วในการส่งข้อมูล

ในไฟล์จับภาพที่คุณระบุ เราจะเห็นได้ว่าบัฟเฟอร์การรับไม่เคยล้น:

การวิเคราะห์ของฉันคือว่าผู้ส่งไม่ได้ส่งเร็วพอเนื่องจากหน้าต่างส่ง (หรือที่เรียกว่าหน้าต่างควบคุมความแออัด) ไม่เปิดขึ้นเพียงพอที่จะตอบสนอง RWIN ของผู้รับ ดังนั้นในระยะสั้นผู้รับบอกว่า "Give me More" และเมื่อ Windows เป็นผู้ส่งจะไม่ส่งเร็วพอ

นี่คือหลักฐานจากความจริงที่ว่าในกราฟข้างต้น RWIN ยังคงเปิดอยู่และด้วยเวลาในการเดินทางรอบ. 09 วินาทีและ RWIN ของ ~ 500,000 ไบต์เราสามารถคาดหวังปริมาณงานสูงสุดตามผลิตภัณฑ์ล่าช้าแบนด์วิดท์เป็น (500000 /0.09) * 8 = ~ 42 Mbit / s (และคุณจะได้รับประมาณ ~ 5 ในการชนะของคุณในการดักจับลีนุกซ์)

จะแก้ไขได้อย่างไร?

ฉันไม่รู้ interface tcp set global congestionprovider=ctcpดูเหมือนสิ่งที่ถูกต้องที่จะทำกับฉันเพราะมันจะเพิ่มหน้าต่างส่ง (ซึ่งเป็นอีกคำหนึ่งสำหรับหน้าต่างแออัด) คุณบอกว่าไม่ทำงาน ดังนั้นเพื่อให้แน่ใจว่า:

1. คุณรีบูตหลังจากเปิดใช้งานสิ่งนี้หรือไม่
2. Is Chimney offload on หรือไม่? ถ้ามันอาจลองปิดมันเป็นการทดลอง ฉันไม่ทราบว่าสิ่งใดได้รับการ offloaded อย่างแน่นอนเมื่อเปิดใช้งานนี้ แต่ถ้าการควบคุมหน้าต่างส่งเป็นหนึ่งในนั้น congestionprovider อาจไม่มีผลเมื่อเปิดใช้งาน ... ฉันแค่คาดเดา ...
3. นอกจากนี้ฉันคิดว่านี่อาจเป็น pre windows 7 แต่คุณอาจลองเพิ่มและเล่นกับรีจิสตรีคีย์สองคีย์ที่ชื่อว่า DefaultSendWindow และ DefaultReceiveWindow ใน HKEY_LOCAL_MACHINE ระบบปัจจุบัน CurrentControlSet-Services-AFD- พารามิเตอร์ หากสิ่งเหล่านี้ยังใช้งานได้คุณอาจถูกปิดใช้งาน ctcp
4. ลองเดาดูnetsh interface tcp show heuristicsอีกครั้ง ฉันคิดว่ามันอาจจะเป็น RWIN แต่ก็ไม่ได้พูดดังนั้นอาจเล่นด้วยการปิด / เปิดใช้งานในกรณีที่มันส่งผลกระทบต่อหน้าต่างส่ง
5. ตรวจสอบให้แน่ใจว่าไดรเวอร์ของคุณเป็นรุ่นล่าสุดในไคลเอนต์ทดสอบของคุณ บางทีบางสิ่งก็พัง

ฉันจะลองการทดลองทั้งหมดเหล่านี้ด้วยคุณสมบัติการถ่ายข้อมูลออกทั้งหมดเพื่อเริ่มต้นเพื่อกำจัดความเป็นไปได้ที่ไดรเวอร์เครือข่ายกำลังทำการเขียนใหม่ / แก้ไขสิ่งต่าง ๆ (เก็บซีพียูที่ตาในขณะที่ปิดการโหลด) TCP_OFFLOAD_STATE_DELEGATED structดูเหมือนว่าอย่างน้อยหมายความว่า CWnd ถ่ายที่น้อยที่สุด

มีข้อมูลที่ยอดเยี่ยมที่นี่โดย @Pat และ @Kyle ให้ความสนใจอย่างแน่นอนกับคำอธิบายของ@ Kyle เกี่ยวกับ TCP ที่ได้รับและส่ง windows ฉันคิดว่ามีความสับสนบ้าง เพื่อสร้างความสับสนให้กับเรื่องเพิ่มเติม iperf ใช้คำว่า "หน้าต่าง TCP" กับการ-wตั้งค่าซึ่งเป็นชนิดของคำที่ไม่ชัดเจนที่เกี่ยวข้องกับหน้าต่างรับ, ส่งหรือหน้าต่างบานเลื่อนโดยรวม สิ่งที่จริงแล้วคือการตั้งค่าซ็อกเก็ตส่งบัฟเฟอร์สำหรับ-cอินสแตนซ์ (ไคลเอนต์) และซ็อกเก็ตได้รับบัฟเฟอร์บน-sอินสแตนซ์ (เซิร์ฟเวอร์) ใน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 ));
}

ตามที่ Kyle กล่าวถึงปัญหาไม่ได้อยู่ที่หน้าต่างรับบนกล่อง Linux แต่ผู้ส่งไม่เปิดหน้าต่างส่งเพียงพอ ไม่ใช่ว่ามันไม่เปิดเร็วพอมันแค่ปิดที่ 64k

ขนาดบัฟเฟอร์ซ็อกเก็ตเริ่มต้นใน Windows 7 คือ 64k นี่คือสิ่งที่เอกสารอธิบายเกี่ยวกับขนาดบัฟเฟอร์ซ็อกเก็ตที่สัมพันธ์กับปริมาณงานที่MSDN

เมื่อส่งข้อมูลผ่านการเชื่อมต่อ TCP โดยใช้ซ็อกเก็ต Windows เป็นสิ่งสำคัญที่จะต้องเก็บข้อมูลที่เพียงพอ (ส่ง แต่ยังไม่ได้รับการยอมรับ) ใน TCP เพื่อให้ได้ปริมาณงานสูงสุด ค่าที่เหมาะสมที่สุดสำหรับปริมาณข้อมูลที่โดดเด่นเพื่อให้ได้ปริมาณงานที่ดีที่สุดสำหรับการเชื่อมต่อ TCP เรียกว่าขนาดในอุดมคติ send backlog (ISB) ค่า ISB เป็นฟังก์ชันของผลิตภัณฑ์ที่ใช้แบนด์วิดท์ล่าช้าของการเชื่อมต่อ TCP และหน้าต่างรับของผู้รับโฆษณา (และส่วนหนึ่งคือปริมาณความแออัดในเครือข่าย)

ตกลง blah blah blah ตอนนี้เราไปที่นี่:

แอปพลิเคชันที่ดำเนินการร้องขอการส่งหรือการบล็อกที่ไม่ใช่การบล็อกครั้งละครั้งจะขึ้นอยู่กับการบัฟเฟอร์การส่งภายในโดย Winsock เพื่อให้ได้ปริมาณงานที่เหมาะสม ขีด จำกัด บัฟเฟอร์การส่งสำหรับการเชื่อมต่อที่กำหนดถูกควบคุมโดยตัวเลือกซ็อกเก็ต SO_SNDBUF สำหรับการปิดกั้นและไม่ปิดกั้นวิธีการส่ง, ขีด จำกัด ส่งบัฟเฟอร์กำหนดเท่าใดข้อมูลจะถูกเก็บไว้ที่โดดเด่นใน TCP หากค่า ISB สำหรับการเชื่อมต่อมีขนาดใหญ่กว่าขีด จำกัด บัฟเฟอร์การส่งข้อมูลปริมาณงานที่ทำได้ในการเชื่อมต่อจะไม่เหมาะสม

ปริมาณงานเฉลี่ยของการทดสอบ iperf ล่าสุดของคุณโดยใช้หน้าต่าง 64k คือ 5.8Mbps มาจากสถิติ> สรุปใน Wireshark ซึ่งนับจำนวนบิตทั้งหมด ในทำนองเดียวกัน iperf กำลังนับปริมาณข้อมูล TCP ซึ่งเป็น 5.7Mbps เราเห็นประสิทธิภาพเดียวกันกับการทดสอบ FTP เช่นกัน ~ 5.6Mbps

ทรูพุตเชิงทฤษฎีที่มีบัฟเฟอร์การส่ง 64k และ RTMS 91ms คือ .... 5.5Mbps ใกล้พอสำหรับฉัน

ถ้าเราดูการทดสอบ iperf ของหน้าต่าง 1MB ของคุณ tput คือ 88.2Mbps (86.2Mbps สำหรับข้อมูล TCP เท่านั้น) ทฤษฎี tput ที่มีหน้าต่าง 1MB คือ 87.9Mbps อีกครั้งใกล้พอสำหรับงานรัฐบาล

สิ่งนี้แสดงให้เห็นว่าบัฟเฟอร์การส่งซ็อกเก็ตควบคุมหน้าต่างการส่งโดยตรงและที่ควบคู่กับหน้าต่างรับจากอีกด้านหนึ่งควบคุมปริมาณงาน หน้าต่างรับที่โฆษณามีห้องดังนั้นเราจึงไม่ถูก จำกัด โดยผู้รับ

เดี๋ยวก่อนธุรกิจเกี่ยวกับการปรับอัตโนมัตินี้ล่ะ Windows 7 จัดการกับสิ่งนั้นโดยอัตโนมัติหรือไม่? ดังที่ได้กล่าวไว้ Windows จะจัดการปรับขนาดหน้าต่างรับโดยอัตโนมัติ แต่ยังสามารถจัดการบัฟเฟอร์ส่งแบบไดนามิกได้เช่นกัน กลับไปที่หน้า MSDN:

เพิ่มบัฟเฟอร์การส่งแบบไดนามิกสำหรับ TCP ใน Windows 7 และ Windows Server 2008 R2 โดยค่าเริ่มต้นการส่งบัฟเฟอร์แบบไดนามิกสำหรับ TCP ถูกเปิดใช้งานเว้นแต่ว่าแอปพลิเคชันจะตั้งค่าตัวเลือกซ็อกเก็ต SO_SNDBUF บนซ็อกเก็ตสตรีม

iperf ใช้SO_SNDBUFเมื่อใช้-wตัวเลือกดังนั้นบัฟเฟอร์การส่งแบบไดนามิกจะถูกปิดใช้งาน แต่ถ้าคุณไม่ได้ใช้แล้วก็ไม่ได้ใช้-w SO_SNDBUFการบัฟเฟอร์ส่งแบบไดนามิกควรเปิดโดยค่าเริ่มต้น แต่คุณสามารถตรวจสอบ:

netsh winsock show autotuning

เอกสารบอกว่าคุณสามารถปิดการใช้งานด้วย:

netsh winsock set autotuning off

แต่นั่นไม่ได้ผลสำหรับฉัน ฉันต้องทำการเปลี่ยนแปลงรีจิสทรีและตั้งค่านี้เป็น 0:

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

ฉันไม่คิดว่าการปิดใช้งานสิ่งนี้จะช่วยได้ มันเป็นเพียง FYI

ทำไมการส่งบัฟเฟอร์การปรับสเกลของคุณไม่เกิน 64k เริ่มต้นเมื่อส่งข้อมูลไปยังกล่อง Linux ที่มีพื้นที่มากมายในหน้าต่างรับ เป็นคำถามที่ดีมาก เคอร์เนล Linux ยังมี TCP stack อัตโนมัติ เช่นเดียวกับ T-Pain และ Kanye ทำเพลงคู่อัตโนมัติด้วยกันมันอาจฟังดูไม่ดี อาจมีปัญหาบางอย่างกับทั้งสองกองอัตโนมัติ TCP กองซ้อนกันพูดคุยกัน

บุคคลอื่นมีปัญหาเช่นเดียวกับคุณและสามารถแก้ไขได้ด้วยการแก้ไขรีจิสทรีเพื่อเพิ่มขนาดบัฟเฟอร์การส่งเริ่มต้น น่าเสียดายที่มันดูเหมือนว่าจะไม่ทำงานอีกต่อไปอย่างน้อยมันก็ไม่เหมาะกับฉันเมื่อฉันลองทำ

ณ จุดนี้ฉันคิดว่ามันชัดเจนว่าปัจจัย จำกัด คือขนาดบัฟเฟอร์ส่งบนโฮสต์ Windows เนื่องจากดูเหมือนว่ามันจะไม่เติบโตแบบไดนามิกอย่างเหมาะสมผู้หญิงควรทำอะไร

คุณสามารถ:

• ใช้แอพพลิเคชั่นที่อนุญาตให้คุณตั้งค่าตัวเลือกการส่งของบัฟเฟอร์เช่นหน้าต่าง
• ใช้พร็อกซี Linux ในเครื่อง
• ใช้พรอกซี Windows ระยะไกลหรือไม่
• เปิดเคสด้วย Microsofhahahahahahaha
• เบียร์

ข้อจำกัดความรับผิดชอบ: ฉันใช้เวลาหลายชั่วโมงในการค้นคว้าและมันถูกต้องตามความรู้และ google-fu ของฉัน แต่ฉันจะไม่สาบานกับหลุมศพของแม่ฉัน (เธอยังมีชีวิตอยู่)

เมื่อคุณปรับแต่งสแต็ก TCP แล้วคุณอาจยังมีปัญหาคอขวดในเลเยอร์ Winsock ฉันได้พบว่าการกำหนดค่า Winsock (Ancillary Function Driver ในรีจิสทรี) สร้างความแตกต่างอย่างมากสำหรับความเร็วในการอัปโหลด (การส่งข้อมูลไปยังเซิร์ฟเวอร์) ใน Windows 7 Microsoft ได้ยอมรับข้อผิดพลาดในการโหลดอัตโนมัติ TCP สำหรับซ็อกเก็ตที่ไม่ปิดกั้น ประเภทของซ็อกเก็ตที่เบราว์เซอร์ใช้ ;-)

เพิ่มคีย์ DWORD สำหรับ DefaultSendWindow และตั้งเป็น BDP หรือสูงกว่า ฉันใช้ 256000

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

การเปลี่ยนการตั้งค่า Winsock สำหรับการดาวน์โหลดอาจช่วยได้ - เพิ่มรหัสสำหรับ DefaultReceiveWindow

คุณสามารถทดลองใช้การตั้งค่าระดับซ็อกเก็ตต่าง ๆ โดยใช้พร็อกซีFiddlerและคำสั่งเพื่อปรับขนาดบัฟเฟอร์ของไคลเอ็นต์และเซิร์ฟเวอร์ซ็อกเก็ต:

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

เมื่ออ่านการวิเคราะห์ทั้งหมดในคำตอบแล้วปัญหานี้ฟังดูคล้ายกับว่าคุณกำลังใช้งาน Windows7 / 2008R2 หรือที่รู้จักใน Windows 6.1

เครือข่ายสแต็ค (TCP / IP & Winsock) ใน Windows 6.1 นั้นมีข้อบกพร่องอย่างน่ากลัวและมีโฮสต์ทั้งหมดของข้อบกพร่องและปัญหาด้านประสิทธิภาพซึ่ง Microsoft ได้แก้ไขปัญหาหลาย ๆ ปีที่ผ่านมานับตั้งแต่เริ่มต้นรุ่น 6.1

วิธีที่ดีที่สุดในการใช้โปรแกรมแก้ไขด่วนเหล่านี้คือการลอดผ่านหน้าเว็บที่เกี่ยวข้องทั้งหมดใน support.microsoft.com ด้วยตนเองและขอและดาวน์โหลดเวอร์ชัน LDR ของโปรแกรมแก้ไขด่วนเครือข่ายสแต็ก (มีหลายสิบหลายตัว)

ในการค้นหาโปรแกรมแก้ไขด่วนที่เกี่ยวข้องคุณต้องใช้ www.bing.com กับคำค้นหาต่อไปนี้ site:support.microsoft.com 6.1.7601 tcpip.sys

คุณต้องเข้าใจว่าการฝึกอบรม LDR / GDR ทำงานอย่างไรใน Windows 6.1

โดยทั่วไปฉันใช้เพื่อรักษารายการแก้ไข LDR ของตัวเอง (ไม่ใช่เฉพาะการแก้ไขสแต็กเครือข่าย) สำหรับ Windows 6.1 จากนั้นใช้การแก้ไขเหล่านี้ในเชิงรุกกับเซิร์ฟเวอร์ / ไคลเอนต์ Windows 6.1 ใด ๆ ที่ฉันเจอ มันเป็นงานที่ต้องใช้เวลามากในการตรวจสอบโปรแกรมแก้ไขด่วน LDR ใหม่เป็นประจำ

โชคดีที่ Microsoft ได้หยุดการฝึกหัดโปรแกรมแก้ไขด่วน LDR ด้วยระบบปฏิบัติการรุ่นใหม่กว่าและตอนนี้มีการแก้ไขข้อบกพร่องผ่านบริการอัพเดทอัตโนมัติจาก Microsoft

ปรับปรุง : เพียงหนึ่งตัวอย่างของข้อบกพร่องของเครือข่ายมากมายใน Windows7SP1 - https://support.microsoft.com/en-us/kb/2675785

UPDATE 2 : นี่คือโปรแกรมแก้ไขด่วนอื่นที่เพิ่มสวิทช์ netsh เพื่อบังคับให้ปรับหน้าต่างหลังจาก retransmission ที่สองของแพ็คเก็ต SYN (โดยค่าเริ่มต้นการปรับขนาดหน้าต่างถูกปิดใช้งานหลังจาก 2 SYN แพ็คเก็ตมี retransmitted) https://support.microsoft.com/en- เรา / กิโลไบต์ / 2780879

ฉันเห็นว่านี่เป็นโพสต์ที่เก่ากว่าเล็กน้อย แต่ก็สามารถช่วยเหลือผู้อื่นได้

ในระยะสั้นคุณต้องเปิดใช้งาน "รับการปรับแต่งหน้าต่างอัตโนมัติ":

netsh int tcp set global autotuninglevel=normal

CTCP ไม่มีความหมายหากไม่มีการเปิดใช้งานด้านบน

หากคุณปิดการใช้งาน "รับการปรับแต่งอัตโนมัติของหน้าต่าง" คุณจะติดอยู่ที่ขนาดแพ็คเก็ต 64KB ซึ่งจะส่งผลเสียต่อ RTT ที่ยาวนานในการเชื่อมต่อบรอดแบนด์สูง นอกจากนี้คุณยังสามารถทดสอบด้วยตัวเลือก "ถูก จำกัด " และ "จำกัด อย่างสูง"

การอ้างอิงที่ดีมาก: https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

ฉันประสบปัญหาคล้ายกันกับไคลเอนต์ Windows (Windows 7) ฉันผ่านการดีบักส่วนใหญ่ที่คุณได้ทำไปแล้วปิดการใช้งานอัลกอริทึม Nagle, TCP Chimney Offloading และการเปลี่ยนแปลงอื่น ๆ ที่เกี่ยวข้องกับการตั้งค่า TCP ไม่ใช่ของพวกเขามีผลกระทบใด ๆ

ในที่สุดสิ่งที่แก้ไขให้ฉันคือการปรับเปลี่ยนหน้าต่างส่งเริ่มต้นในรีจิสทรีของบริการ AFD ดูเหมือนว่าปัญหาจะเกี่ยวข้องกับไฟล์ afd.sys ฉันทดสอบลูกค้าหลายรายบางคนแสดงว่าอัพโหลดช้าและบางคนก็ไม่ได้ แต่ทั้งหมดเป็นเครื่อง Windows 7 เครื่องที่แสดงพฤติกรรมที่ช้ามี AFD.sys รุ่นเดียวกัน วิธีแก้ปัญหารีจิสทรีเป็นสิ่งจำเป็นสำหรับคอมพิวเตอร์ที่มี AFD.sys บางรุ่น (ขออภัยอย่าจำรุ่น #)

HKLM \ CurrentControlSet \ Services \ AFD \ Parameters

เพิ่ม - DWORD - DefaultSendWindow

ค่า - ทศนิยม - 1640960

ค่านั้นเป็นสิ่งที่ฉันพบที่นี่: https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-

ฉันคิดว่าการใช้ค่าที่เหมาะสมคุณควรคำนวณด้วยตัวคุณเองโดยใช้:

เช่น. การอัปโหลดโฆษณา: 15 Mbps = 15,000 Kbps

(15000/8) * 1024 = 1920000

จากสิ่งที่ฉันเข้าใจซอฟต์แวร์ไคลเอนต์โดยทั่วไปควรแทนที่การตั้งค่านี้ในรีจิสทรี แต่ถ้าไม่ทำจะใช้ค่าเริ่มต้นและค่าเริ่มต้นจะต่ำมากในไฟล์ AFD.sys บางรุ่น

ฉันสังเกตเห็นว่าผลิตภัณฑ์ MS ส่วนใหญ่มีปัญหาการอัปโหลดช้า (IE, Mini-redirector (WebDAV), FTP ผ่าน Windows Explorer และอื่น ๆ ) เมื่อใช้ซอฟต์แวร์บุคคลที่สาม (เช่น Filezilla) ฉันไม่ได้มีการชะลอตัวแบบเดียวกัน .

AFD.sys มีผลกับการเชื่อมต่อ Winsock ทั้งหมดดังนั้นการแก้ไขนี้ควรใช้กับ FTP, HTTP, HTTPS และอื่น ๆ

นอกจากนี้การแก้ไขนี้ถูกแสดงไว้ที่ใดที่หนึ่งด้วยดังนั้นฉันไม่ต้องการเครดิตสำหรับมันถ้ามันเหมาะกับทุกคนอย่างไรก็ตามมีข้อมูลมากมายในกระทู้นี้ที่ฉันกลัวว่ามันอาจจะถูกคัดสรร

ฉันได้พบกับสถานการณ์ที่คล้ายกันด้วยตัวเอง (คำถามของฉันที่นี่ ) และในที่สุดฉันก็ต้องปิดใช้งานฮิวริติกสเกลของ TCP ปรับตั้งค่าโปรไฟล์การปรับอัตโนมัติด้วยตนเองและเปิดใช้งาน 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. 

ฉันไม่มีคะแนนพอที่จะแสดงความคิดเห็นดังนั้นฉันจะโพสต์ "คำตอบ" แทน ฉันมีสิ่งที่ดูเหมือนจะเป็นปัญหาที่คล้ายกัน / เหมือนกัน (ดูคำถามเซิร์ฟเวอร์ผิดพลาดที่นี่ ) ปัญหาของฉัน (และของคุณ) คือบัฟเฟอร์การส่งของไคลเอนต์ iperf บน windows มันไม่เติบโตเกิน 64 KB Windows ควรจะขยายบัฟเฟอร์แบบไดนามิกเมื่อไม่ได้กำหนดขนาดอย่างชัดเจนโดยกระบวนการ แต่การเติบโตแบบไดนามิกนั้นไม่ได้เกิดขึ้น

ฉันไม่แน่ใจเกี่ยวกับกราฟมาตราส่วนของหน้าต่างที่แสดงหน้าต่างที่เปิดสูงสุด 500,000 ไบต์สำหรับกรณี Windows "ช้า" ของคุณ ฉันคาดว่าจะเห็นกราฟที่เปิดให้เพียง 64,000 ไบต์เท่านั้นเนื่องจากคุณถูก จำกัด ไว้ที่ 5 Mbps

นี่เป็นหัวข้อที่น่าสนใจและตรงกับปัญหาที่ฉันเคยใช้ Win7 / iperf เพื่อทดสอบปริมาณงานของท่อไขมันยาว

โซลูชันสำหรับ Windows 7 คือการดำเนินการคำสั่งต่อไปนี้บนทั้งเซิร์ฟเวอร์ iperf และไคลเอนต์

tcp ส่วนต่อประสานชุดการตั้งค่า autotuninglevel ทั่วโลก = การทดลอง

หมายเหตุ: ก่อนที่คุณจะทำสิ่งนี้ให้แน่ใจว่าได้บันทึกสถานะปัจจุบันของการบรรจุอัตโนมัติ:

ส่วนต่อประสาน tcp แสดงทั่วโลก

รับหน้าต่างปรับระดับอัตโนมัติ: ปิดการใช้งาน

จากนั้นเรียกใช้เซิร์ฟเวอร์ iperf / ไคลเอ็นต์ที่ปลายแต่ละด้านของไปป์

รีเซ็ตค่าการปรับค่าอัตโนมัติตามการทดสอบของคุณ:

tcp ส่วนต่อประสานชุดการตั้งค่า 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.