3

SMB transfers for me are extremely slow. I have two Windows 10 machines and have tried transferring data between the two and get only ~500 mbps over a gigabit connection in both directions.

I have also tried transferring files from android (Neuxs 6P and Pixel XL) to the Windows 10 machine and get an average speed of around ~800 kbps. However, when I transfer from the Windows 10 machine to the phone, I get speeds of ~40 mbps. This speed is faster in this direction, but still much slower than expected.

Iperf3 tests between the two Windows 10 machines show ~900 mbps in both directions. Iperf3 tests from android to the Windows 10 machine is ~200 mbps. I am using Unifi UAP-AC-Lites for the wireless transfers.

What is causing this slow transfer speed?

Improve this question
10
  • 500mbps over gigabit is not extremely slow. that's close to 50MB/s in actual transfer. Its not the best, but far from bad. Note that most mechanical hard disks can't handle large transfers at much more than that (they tend to peak at 100-150 and fall steadilly the longer the read goes).
    – Frank Thomas
    Commented Mar 18, 2017 at 23:17
  • @FrankThomas I guess that is not terrible but 800kbps over wireless does not sound right at all. I just find that it should be transferring at 900mbps since iperf3 shows those numbers.
    – ayao1337
    Commented Mar 18, 2017 at 23:37
  • iperf just shows your network capability, it is for the most part, raw network traffic. When you measure SMB, you're measuring network traffic in addition server response time (CPU/Memory/disk speed) on server - basically its capabilities to actually serve the data requested. Much of the time, if you're not working with enterprise gear, your bottleneck is not going to be the network, but disk speed or CPU resources on one of the machines.
    – MaQleod
    Commented Mar 19, 2017 at 3:08
  • Also take into consideration that Windows by default uses ram to speed up disk writes. So, if the transfer fits within the buffer (usually around 1.5GB) then you're not seeing a disk speed bottleneck on the receiving end. This helps explain the Android test. The Android devices are getting fast NVRAM read speeds, and Windows is getting fast buffer write speeds. If you try to transfer a larger file (say 6GB or so) you can monitor your system performance using the task manager and likely see things slow down as Windows reaches its buffer limits.
    – David Woodward
    Commented Mar 19, 2017 at 14:57
  • @DavidWoodward I guess I can accept that explanation for larger files but the files I have been transferring have been only 300mb-1gb. I don't actually see any slowdown as it is always this single speed. My systems have 8gb and 12gb of ram. Same thing for my android devices, it is always ~800 kbps. It never speeds up then slows down. Especially for the android side, I really can't accept that speed as it was faster before at about 12MB/s. I'm not sure what happened to cause this slowdown so that's why I'm asking here.
    – ayao1337
    Commented Mar 19, 2017 at 16:25

2 Answers 2

Reset to default
0

I haven't actually tried these myself but a lot of internet sources seem to recommended disabling TCP Large Send Offload in the network card device properties page and editing some TCP stack settings, mainly autotuninglevel of the TCP Receive Window size.

To show global TCP settings:

> netsh interface tcp show global

Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : disabled

Receive Window Auto-Tuning Level : normal

Add-On Congestion Control Provider : default
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Initial RTO : 3000
Receive Segment Coalescing State : enabled
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 2
Fast Open : enabled
Fast Open Fallback : enabled
Pacing Profile : off

Values for autotuninglevel:

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 accommodate almost all scenarios.
experimental: Allow the receive window to grow to accommodate extreme scenarios.

The fix implies trying:

netsh interface tcp set global autotuninglevel=disabled

These settings require a computer restart. Here's a Microsoft article describing the TCP features.

Improve this answer
0

I did eventually figure it out at the time. To bring some closure to this question, the problem was with the client itself, ES File Explorer. From what I remember, this app was using an older version of SMB which caused slow transfer speeds. Switching to a different app which supported newer standards resolved the issue.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .