ความเร็วเครือข่ายกิกะบิตช้าที่ไม่สามารถอธิบายได้

18

ปรับปรุง

ตกลงฉันได้ลองคำตอบด้านล่างแล้วไม่มีอะไรเปลี่ยนแปลง ฉันระบุชิปเซ็ตในแล็ปท็อปเป็น NVIDIA nForce 520 ฉันดาวน์โหลดไดรเวอร์ Vista x64 ล่าสุดสำหรับ nForce 520 (NVIDIA ยังไม่มีไดรเวอร์สำหรับชิปเซ็ตนั้นสำหรับ Win 7 เลย) ฉันได้ลองติดตั้งซอฟต์แวร์ไฟร์วอลล์ที่มีให้ (คิดว่าอาจจะรบกวน - ไม่ใช่) ฉันถอนการติดตั้งซอฟต์แวร์ป้องกันไวรัสอย่างสมบูรณ์ (ฉันใช้ Avast!) คิดว่าไดรเวอร์ตัวกรองเครือข่ายอาจทำให้เกิดปัญหาซึ่งไม่ได้ช่วยเช่นกัน

ฉันนำแล็ปท็อปของฉันไปที่บ้านพี่น้องของฉันและสามารถคัดลอกไฟล์ที่ 10 - 12 MB / s ผ่านเครือข่าย 100Mbit ของเขาดังนั้นฉันจึงไม่คิดว่ามันเป็นฮาร์ดแวร์

ฉันใช้ iperf พร้อมผลลัพธ์ที่น่าแปลกใจแล้ว:
iperf จากแล็ปท็อปที่ส่งไปยังเซิร์ฟเวอร์ (อัปโหลด)

> 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 จากเซิร์ฟเวอร์ที่ส่งไปยังแล็ปท็อป (ดาวน์โหลด)

> 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

สำหรับการเปรียบเทียบนี่คือหมายเลข iperf ระหว่าง HTPC และเซิร์ฟเวอร์

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

ใช้ wireshark เพื่อดูการถ่ายโอนจากเซิร์ฟเวอร์ไปยังแล็ปท็อปทำรายการต่อไปนี้มากมาย:

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

ณ จุดนี้ฉันกำลังสูญเสียที่สมบูรณ์และเต็มที่ว่าจะลองทำอะไรต่อไป

คำถามเดิม

พื้นหลัง

ฉันกำลังประสบปัญหาในแล็ปท็อป Windows 7 ที่เพิ่งติดตั้งใหม่ ปัญหานี้เกิดขึ้นหลังจากที่ฉันติดตั้ง Windows 7 RC เมื่อติดตั้ง Windows Vista และ Windows 7 Beta 1 บนแล็ปท็อปนี้ฉันสามารถถ่ายโอนด้วยความเร็วกิกะบิตด้วยการเปิดเฟรมจัมโบ้ไปยังช่วง 9KB / 9014 สองสวิตช์ระหว่างแล็ปท็อปรองรับเฟรมจัมโบ้เช่นกัน

เมื่อคัดลอกไฟล์จากเซิร์ฟเวอร์ของฉันไปยังแล็ปท็อปของฉันไฟล์เหล่านั้นจะทำงานอย่างช้ามาก (น้อยกว่า 1 MB / วินาที) ในขณะที่อุปกรณ์อื่น ๆ ที่ใช้สวิตช์เดียวกันสามารถถ่ายโอนข้อมูลด้วยความเร็วสูงกว่า (45 - 55 MB / วินาที) ดูเหมือนว่าการคัดลอกจากแล็ปท็อปไปยังเซิร์ฟเวอร์ทำให้ความเร็วเร็วขึ้น แต่ก็ไม่เหมือนที่ควร

เครื่องจักรที่เกี่ยวข้อง

  • Miyuki: แล็ปท็อปที่มีปัญหา Windows 7 x64 RTM HP Pavilion dv9700 CTO ใช้อแด็ปเตอร์อีเทอร์เน็ต NVIDIA nForce 10/100/1000 Mbps (วิดีโอคือ GeForce 8400M GS)
  • Naru: เซิร์ฟเวอร์พร้อมไฟล์ Windows Server 2008 R2 x64 SP2 ที่กำหนดเอง ใช้อะแดปเตอร์ PCI Express Gigabit D-Link DGE-560T
  • CC: HTPC บนสวิตช์เดียวกันโดยไม่มีปัญหา Windows Vista x86 SP2 ใช้อะแด็ปเตอร์ Realtek RTL8168B / 8111B PCI-E GBE แบบออนบอร์ด

เมื่อภาพเหล่านี้ถูกถ่ายเฟรมจัมโบ้ถูกปิด

ทั้งรูปภาพ

การคัดลอกเริ่มต้นจากแล็ปท็อป

เซิร์ฟเวอร์ -> แล็ปท็อป(ที่มา: gibixonline.com ) แล็ปท็อป -> เซิร์ฟเวอร์



การคัดลอกเริ่มต้นจากเซิร์ฟเวอร์

เซิร์ฟเวอร์ -> แล็ปท็อป(ที่มา: gibixonline.com ) การให้เซิร์ฟเวอร์คัดลอกไฟล์จากแล็ปท็อปไปยังตัวเองอย่างไม่คาดคิดทำให้เกิดความเร็วที่ฉันคาดหวัง (แล็ปท็อป -> เซิร์ฟเวอร์) (ที่มา: gibixonline.com )




ฉันระบุไว้ก่อนหน้านี้ว่าเครื่องอื่น ๆ ที่สวิตช์เดียวกันไม่มีปัญหานี้ High DPI ถูกเปิดใช้งานเนื่องจากสิ่งนี้แสดงบน HDTV
เซิร์ฟเวอร์ -> HTPC (ที่มา: gibixonline.com )

ฉันตัดสินใจที่จะดูว่าความเร็วเป็นอะไรระหว่างแล็ปท็อปของฉันกับ HTPC น่าเสียดายที่พวกเขาเป็นสิ่งที่ฉันคาดไว้
HTPC -> แล็ปท็อป(แหล่งที่มา: gibixonline.com )

บันทึกสุดท้าย

ฉันลองทุกอย่างที่ฉันสามารถคิดได้ ถึงตอนนี้เฟรมจัมโบ้ก็ถูกปิดและไม่มีอะไรน่าจะส่งผลกระทบต่อมัน ฉันได้ลองปิดการป้องกัน Anti-Virus ของฉันไปที่การเปลี่ยนสายเคเบิลที่ฉันใช้ ปัจจุบันสายเคเบิลที่ใช้งานทั้งหมดเป็น CAT-5e ที่ฉันสร้างขึ้น ฉันลองใช้สายเคเบิลจาก HTPC และเสียบเข้ากับแล็ปท็อปของฉันเพื่อดูว่าการเดินสายเคเบิลเป็นปัญหาหรือไม่ สวิตช์สองตัวที่สงสัยคือ D-Link DGS-1216T และสวิตช์ "dumb" ที่รองรับเฟรมจัมโบ้ D-Link DGS-2208

windows-server-2008  windows-7  slow-connection  gigabit 
— โจชัว
แหล่งที่มา
1
คุณลองใช้เครื่องมือเช่น iperf (google for iperf win32) เพื่อวัดแบนด์วิดธ์ที่มีอยู่หรือไม่ถ้า iperf ให้ความเร็วที่เหมาะสมอาจเป็นสิ่งประดิษฐ์ drm ใหม่: / ฉันสงสัยมัน - แต่มันคุ้มค่าการตรวจสอบอย่างอื่นตรวจสอบอีกครั้งหากไม่มีการสะกดผิดเพล็กซ์
— pQd
คุณลอง pscp ไปที่เซิร์ฟเวอร์ใกล้เคียงเพื่อดูว่าคุณได้ความเร็วเท่าไร?
— chris
1
คุณลองข้ามการเชื่อมต่อเซิร์ฟเวอร์และแล็ปท็อปเข้าด้วยกันเพื่อไม่ให้มีการสลับระหว่างกัน
— โจเซฟ
แก้ไขสิ่งที่โยเซฟพูดถึง โปรดลองกำจัดสวิตช์ออกจากสมการ
— Jeremy Visser

คำตอบ:

5

ลองปิดการใช้งานคุณสมบัติการปรับจูนอัตโนมัติของ Window

ในหน้าต่าง CMD:

netsh interface tcp set global autotuning=disabled

เรียกใช้การทดสอบอีกครั้งและดูว่าคุณสังเกตเห็นการปรับปรุงประสิทธิภาพหรือไม่ ฉันต้องทำเช่นนี้กับแล็ปท็อปสองเครื่องที่ใช้ Windows 7 ในบ้านของฉันและมันก็ช่วยได้

หากสิ่งเลวร้ายลงหรือคุณไม่สังเกตเห็นการปรับปรุงใด ๆ คุณสามารถเปิดใช้งานการโหลดอัตโนมัติอีกครั้งโดย:

netsh interface tcp set global autotuning=normal
— ทิมเคนเนดี้
แหล่งที่มา
3

นี่น่าจะเป็นปัญหาใหญ่สำหรับ Windows 7 นักเล่นเกมหลายคนบ่นเรื่องนี้

  1. จากพรอมต์คำสั่ง (โดยปกติจะอยู่ในโปรแกรมทั้งหมด -> อุปกรณ์เสริม -> พร้อมท์คำสั่ง) ให้เรียกใช้“ regedit”
  2. เรียกดู HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ Tcpip \ Parameters \ การเชื่อมต่อ
  3. เรียกดูรายการภายใต้อินเทอร์เฟซจนกระทั่งคุณพบรายการที่มีรายการ IPAddress ที่ตรงกับอินเทอร์เฟซเครือข่ายที่คุณต้องการส่งผลกระทบ (โดยทั่วไปแล้วที่อยู่ IP ของ LAN เริ่มต้นด้วย 192.168 หรือ 10.0) โปรดทราบว่าหากที่อยู่ IP ของคุณถูกกำหนดโดยเซิร์ฟเวอร์ DHCP โดยอัตโนมัติคุณอาจต้องค้นหา DhcpIPAddress ที่ตรงกันแทน IPAddress
  4. คลิกขวาที่อินเทอร์เฟซแล้วเลือกใหม่> DWORD (32- บิต) ค่าตั้งชื่อ“ TcpAckFrequency”
  5. คลิกขวาที่ค่า TcpAckFrequency ใหม่และเลือก Modify จากนั้นป้อน“ 1″ (ควรเลือกปุ่มตัวเลขฐานสิบหก)
  6. คลิกขวาที่อินเทอร์เฟซและเลือกใหม่> DWORD (32- บิต) ค่าตั้งชื่อ“ TCPNoDelay” (โปรดทราบว่า TCP เป็นตัวพิมพ์ใหญ่ทั้งหมดในเวลานี้ - โดยเจตนา)
  7. คลิกขวาที่ค่า TCPNoDelay ใหม่และเลือก Modify จากนั้นป้อน“ 1″ (ควรเลือกปุ่มตัวเลขฐานสิบหก)
  8. ตรวจสอบว่าทั้ง TcpAckFrequency และ TCPNoDelay ปรากฏขึ้นในรายการคุณสมบัติของอะแดปเตอร์ที่มีประเภท REG_DWORD และค่า 0 × 00000001
  9. ออกจาก regedit และรีบูต (จำเป็นต้องรีบูตเพื่อให้การเปลี่ยนแปลงมีผล!)
    1. เล่นเกมและสนุกไปกับการ ping ต่ำอันใหม่ของคุณ

สิ่งนี้ลดค่า ping ของฉันในเกมส่วนใหญ่จาก 200-300ms เป็น 50-60ms ซึ่งตรงกับเวลาแฝงที่ฉันเห็นผ่าน tracert ไปยังเซิร์ฟเวอร์ของเกม

นำมาจากลดเวลาในการตอบสนองของเครือข่ายเกมใน windows 7 หรือ vista

— JJ01
แหล่งที่มา
1
tracert ใช้ ICMP ไม่ใช่ TCP คีย์เหล่านี้ใช้สำหรับ TCP ดังนั้นจึงไม่มีการเปลี่ยนแปลงใด ๆ สำหรับ ICMP ไม่ทราบว่าทำไมคุณเห็นเวลาตอบสนองที่ดีขึ้นผ่าน tracert
— Mathieu Chateau
ฉันไปข้างหน้าและลองสิ่งนี้และมันก็ยังคงเหมือนเดิม ฉันกำลังอัปเดตคำถามเดิมพร้อมข้อมูลเพิ่มเติมและสิ่งที่ฉันลอง
— Joshua
2
Matthieu เขาไม่ได้บอกว่าเขาเห็นเวลาที่ดีกว่าจากผู้ติดตาม เขาบอกว่าเวลาแฝงในเกมนั้นเทียบเท่ากับ tracert ซึ่งหมายความว่าเวลาแฝงที่สังเกตได้ในทราฟฟิก TCP นั้นคล้ายคลึงกับทราฟฟิก ICMP ซึ่งทำงานได้ตามปกติ
— MDMarra
3

ในการตรวจสอบว่าแล็ปท็อปไม่ใช่ความผิดหรือไม่ให้รัน ubuntu live cd, ติดตั้ง iperf บน ramdisk และทำการทดสอบ

อย่างน้อยควรทดสอบด้านเครือข่ายของมัน

— ด้าน
แหล่งที่มา
1

ตรวจสอบแพ็กเก็ตที่ทิ้ง ไม่แน่ใจว่าจะทำอย่างไรใน windows แต่ถ้าคุณมีเครื่อง linux คุณสามารถตรวจสอบได้

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

1

ฉันเคยเจอสิ่งนี้มาก่อนกับผลิตภัณฑ์ AV อื่น ๆ ปัญหาของฉันคือกับ SMB และผลิตภัณฑ์ AV แทรกแซงแม้เมื่อ "ปิดการใช้งาน" มันแสดงผลลัพธ์ที่คล้ายกันใน wireshark ที่คุณมี นี่เป็นหนึ่งในหลาย ๆ เว็บไซต์ที่ฉันตรวจสอบเพื่อหาสาเหตุที่แท้จริง: ปัญหาของ Symantec SMBและอีกอย่าง: SMB2 ล้มเหลวด้วย NTP

นอกจากนี้คุณอาจลองปิด / เปลี่ยนการตั้งค่าทั้งหมดหรือบางส่วนภายใน SMB ฉันจะพิจารณาปิดการใช้งาน v2 บนระบบปฏิบัติการด้วย ตรวจสอบบทความนี้อธิบายถึงปัญหา SMB ภายใน Win Vistaและการเชื่อมโยงนี้ไปยัง Microsoft แสดงข้อมูลเทคโนโลยีบางอย่างเกี่ยวกับการตั้งค่า SMB reg

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

— เบ็นแคมป์เบล
แหล่งที่มา
1

ฉันมีปัญหากับลูกค้าที่สื่อสารกับ Windows Servers เมื่อใช้ Packet Signing ฉันไม่ได้รับความเชื่องช้า แต่การเชื่อมต่อแบบดรอปเอาท์ค่อนข้างมาก

อ่านที่นี่สำหรับวิธีการแก้ไขปัญหาของฉัน

นอกจากนี้ฉันไม่เห็นคำแนะนำใด ๆ ที่นี่สำหรับการปิดฟังก์ชั่น TCP Chimney หนึ่งต่อหนึ่งเพื่อดูว่าหนึ่งในนั้นผิดพลาดหรือไม่

— Dom
แหล่งที่มา
ถูกไฟไหม้ตามนี้ด้วย ...
— เบนแคมป์เบล
1

ดูเหมือนว่าระบบปฏิบัติการกำลังตรวจสอบแพ็กเก็ตก่อนที่จะเขียนลงดิสก์ ฉันสังเกตว่าการถ่ายโอนที่ช้านั้นเป็นสิ่งที่พยายามเขียนลงในแล็ปท็อป ... ฉันแนะนำ

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

มีคนอื่นแนะนำและดูเหมือนจะไม่ได้ช่วย:

  • อัตโนมัติ tunning
  • ระดับเพล็กซ์
  • สายเคเบิ้ล ...

หนึ่งข้อเสนอแนะสุดท้ายคือคุณสามารถตรวจสอบการเชื่อมโยงโหมดแบตเตอรี่ในคุณสมบัติขั้นสูงของ nic? มันเป็นแล็ปท็อปและอาจมีปัญหาบางอย่างเกี่ยวกับคุณสมบัติการประหยัดพลังงาน ... ลอง "ไม่ประหยัดพลังงาน" ในการตรวจจับการเชื่อมโยงโหมดแบตเตอรี่และ "เต็ม" ในการตั้งค่าความเร็วของแบตเตอรี่

ฉันใช้ win7 บนเดสก์ท็อปพีซีและตัวเลือกเหล่านั้นไม่รวมอยู่ในคุณสมบัติขั้นสูงของ nic ตราบใดที่ฉันยังไม่เคยผ่านปัญหานี้คุณสามารถตรวจสอบค่าของ "Flow Control" ถึง "TX และ RX Enabled" เป็นตัวเลือกของ nic ได้เช่นกัน จัมโบ้ถูกปิดการใช้งานความเร็วและเพล็กซ์ก็เป็นอัตโนมัติในการกำหนดค่าของฉัน ...

ฉันไม่สามารถคิดวิธีอื่น ๆ ได้ ... หวังว่านี่จะช่วย ...

— The_aLiEn
แหล่งที่มา
1

ก่อนหน้านี้ฉันไล่ตามหางของฉันด้วยปัญหาเดียวกันอยู่พักหนึ่ง! ความเร็วในการถ่ายโอนช้าลงในทิศทางเดียวในกรณีของฉันขาออก (อัปลิงค์)

Windows 7 Pro, Celeron J1800 พร้อม Realtek Gigabit 8111C ในตัวการ์ดแลน อีกด้านหนึ่งคือ QNAP 453a และ MacBook Pro

เมื่อวัดผ่าน Iperf3 ฉันได้รับ 112 mbps ด้วยการตั้งค่า Windows 7 ของฉันเป็นไคลเอนต์ (การใช้งาน CPU ที่ 25-30%) และเพียง 39-41 Mbps เมื่อตั้งเป็นเซิร์ฟเวอร์ที่มีการใช้งาน CPU สูงระหว่าง 50-100% แย่มากที่พีซีจะค้างในช่วงเวลาของการทดสอบแบนด์วิดท์

การถ่ายโอนไฟล์ปกติต่อยอดสูงสุดที่ 45mbps ไม่ว่าฉันจะอัพโหลดหรือดาวน์โหลดไฟล์ไปยัง NAS หรือ MAC ของฉัน

ฉันได้รับอะไรมากกว่า 35-45 เมกะไบต์ต่อวินาที น่าผิดหวังมาก!

จบลงด้วยการเป็นคนขับการ์ด LAN ที่ไม่ดี ฉันหมกมุ่นกับการอัปเดตไดรเวอร์และอัปเดตไดรเวอร์ของฉันเสมอเมื่อมีไดรเวอร์ใหม่ให้ใช้งาน คาดเดาสิ่งหลังจากอัปเดตการ์ดแลนของฉันช้าลงหลายครั้ง

คุณบางคนอาจจะบอกว่าเพียงแค่ลบไดรเวอร์เก่าและติดตั้งใหม่ ง่ายใช่มั้ย ฉันพยายามแล้วพยายามมันไม่ได้ผลสำหรับฉัน

นี่คือทางออกของฉัน:

ติดตั้ง windows ตั้งแต่เริ่มต้นด้วยไดรเวอร์ OEM จากเว็บไซต์ของผู้ผลิต เช่นกันที่ฉันทำต่อไปนี้:

ภายใต้ Device Manager / การ์ด Lan / การตั้งค่าขั้นสูง / ปิดการใช้งานทุกอย่างยกเว้นการควบคุมการไหล

ภายใต้คุณสมบัติของ Windows ให้ปิดใช้งานการบีบอัดส่วนต่างระยะไกล

ขณะนี้ความเร็วเฉลี่ยอยู่ระหว่าง 80-100 Mbps

— Gi Cakov
แหล่งที่มา
0

ทุกอย่างฉันคิดว่าคุณได้ตั้งการ์ดเครือข่ายเป็นฟูลดูเพล็กซ์ 100MBit และไม่ใช่อัตโนมัติ?

— คริส
แหล่งที่มา
1
+1 สำหรับ "ไม่ใช่อัตโนมัติ" :)
— dimitri.p
ใช่ฉันได้ลองใช้กับการ์ดของฉันทั้งหมดแล้ว ... 10 ครึ่งเต็ม 10 เต็ม 100 ครึ่งเต็ม 100 และเต็ม 1000 ไม่มีผู้ใดที่ได้รับผลกระทบในทางใดทางหนึ่งและตามสวิตช์ที่พวกเขาทำการเจรจาที่ 1,000 เต็ม
— โจชัว
10
อย่าทำอย่างนั้นถ้าสวิตช์นั้นไม่สามารถจัดการได้ หากคุณถูกบังคับให้เต็มเพล็กซ์ที่ด้านหนึ่ง แต่อัตโนมัติในด้านอื่น ๆ อีกด้านหนึ่งกลายเป็นครึ่งเพล็กซ์ จากนั้นคุณก็เริ่มที่จะสูญเสียแพ็กเก็ต (มาก ... ) เปลี่ยนว่าคุณไม่สามารถจัดการได้อัตโนมัติ ทำให้อัตโนมัติบนเซิร์ฟเวอร์ของคุณและตรวจสอบว่าอินเทอร์เฟซ negociated เต็มเพล็กซ์ ตรวจสอบข้อผิดพลาดของอินเทอร์เฟซเช่นกัน
— Mathieu Chateau
4
-1 สำหรับ "ไม่ใช่อัตโนมัติ" คุณต้องการการตั้งค่าเดียวกันที่ปลายทั้งสองข้าง (สวิตช์และ NIC) รวมถึงการต่อรองอัตโนมัติ
— dunxd
5
ฉันอยากรู้อยากเห็นคุณลองถอดสวิตช์ออกจากสมการและใช้สายเคเบิลแบบไขว้จาก "เซิร์ฟเวอร์" โดยตรงไปที่ "แล็ปท็อป" หรือไม่?
— SpacemanSpiff
0

คุณอาจจะเกลียดคำตอบนี้ แต่ฉันต้องบอกว่า!

คุณลองอัปเดตไดรเวอร์แล้วหรือยัง

ฉันพบปัญหาที่คล้ายกันในแล็ปท็อปของฉัน (Realtek based NIC) มันถ่ายโอนที่ประมาณ 3MB / s แต่แล้วตอนที่ฉันอัปเกรดไดรเวอร์เป็นไดรเวอร์ล่าสุดจากเว็บไซต์ของพวกเขามันจะเพิ่มขึ้นประมาณ 40-50MB / s

เพียงเพราะไดรเวอร์ที่ทำงานกับ Windows ไม่ได้แปลว่าดีที่สุด

— William Hilsum
แหล่งที่มา
ฮ่าฮ่าใช่นั่นเป็นสิ่งแรกที่ฉันได้ลอง ตอนนี้ฉันกลับมาที่ไดร์เวอร์ Windows 7 ในกล่อง แต่ฉันได้ลองตัว nvidia รุ่นล่าสุดแล้วเช่นกัน ไดรเวอร์เดียวที่ฉันไม่ได้ลองคือไดรเวอร์จาก Windows 7 เบต้าหรือ Vista
— Joshua
ลองใช้ Vista และดูว่ากระทะนั้นเป็นอย่างไร ฉันมีปัญหาเล็กน้อยหลายอย่างที่ได้รับการแก้ไขในการอัปเดตสำหรับ Win7 ในตอนนี้ ฉันแก้ไขด้วยตนเองโดยติดตั้งไดรเวอร์ Vista สำหรับฮาร์ดแวร์
— เดวิดริกส์
0

ฉันสงสัยว่ามันเป็นสิ่งที่อยู่บนเส้นทางจากเซิร์ฟเวอร์ไปยังแล็ปท็อปเช่น:

  • สลับพอร์ตไปยังแล็ปท็อป
  • สายเคเบิลอีเทอร์เน็ตหรือการเชื่อมต่อระหว่างสวิตช์และแล็ปท็อป

คำแนะนำที่ยอดเยี่ยมของ Per @ SaucemanSpiff คุณลองใช้สายแล็ปท็อปกับเซิร์ฟเวอร์โดยตรงโดยใช้สายเคเบิล CAT5E หรือ CAT6 ที่รู้จักกันดีหรือไม่? ไม่จำเป็นต้องใช้สายเคเบิลครอสโอเวอร์พิเศษตราบใดที่หนึ่งในอินเทอร์เฟซที่เกี่ยวข้องสนับสนุน Gigabit Ethernet (ซึ่งหมายถึง Auto MDI-X)

— Skyhawk
แหล่งที่มา
0

  1. คุณเอาชนะพีซีจนเสียชีวิตด้วยการอัปเดตและทดสอบนอกสถานที่โดยไม่มีข้อผิดพลาด คุณได้ลองทำการอัปเดตและทำเช่นนี้ใน SERVER "naru" หรือไม่?

  2. วิธีแก้ปัญหาส่วนใหญ่ในกระทู้นี้ที่ผู้อื่นแนะนำสามารถนำไปใช้กับเซิร์ฟเวอร์คุณลองใช้ที่นั่นหรือไม่

  3. จะเกิดอะไรขึ้นเมื่อคุณทดสอบการใช้ Robocopy (โดยมีและไม่มีจัมโบ้) ถ้ามันรวดเร็วทั้งสองทิศทางฉันจะใช้ netshark เพื่อดูส่วนหัวของเซสชัน SMB ที่จุดเริ่มต้นของสำเนาในแต่ละทิศทางและดูว่ามีบางอย่างที่แตกต่างกันในการตั้งค่า naru-> miyuki

— เครื่องหมาย
แหล่งที่มา
0

คุณเคยลองใช้ teracopy หรือไม่? ฉันใช้สิ่งนี้เป็นสิ่งทดแทนมาตรฐานสำหรับการคัดลอก windows มานานกว่าหนึ่งปีและมันแสดงให้เห็นถึงการปรับปรุงความเร็วในการถ่ายโอน :)

— บาห์เรน
แหล่งที่มา
-1

ชนิดของการยิงในที่มืด แต่มันสามารถช่วยได้

  • ปิดใช้งาน "การบีบอัดส่วนต่างระยะไกล" ในแผงควบคุม - โปรแกรมและคุณสมบัติ - เปิดหรือปิดคุณสมบัติ Windows
  • ลบ IPv6 ออกจากคุณสมบัติเครือข่าย คุณใช้ IPv6 ใน LAN ของคุณหรือไม่ หากไม่ปิดการใช้งาน
  • ล้างแคช DNS ด้วย ipconfig /flushdnsบน CLI
— duenni
แหล่งที่มา
-1

ถ้ามันเกิดจากการเปลี่ยนระบบปฏิบัติการแล้วแน่นอนปัญหาอยู่ในระบบปฏิบัติการ คุณควรพยายามติดตั้ง service pack ล่าสุด windows 7 และปรับปรุง windows ด้วยการปรับปรุงล่าสุด และหวังว่าจะดีที่สุด

— Farhan
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.