Extremely Slow SMB transfers

1

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?

ayao1337

Posted 2017-03-18T22:20:48.917

Reputation: 478

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 – 2017-03-18T23:17:14.597

@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 – 2017-03-18T23:37:02.800

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 – 2017-03-19T03:08:21.963

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 – 2017-03-19T14:57:06.273

@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 – 2017-03-19T16:25:35.633

@MaQleod I really don't believe that a constant 800 kbps could be reasonable for any system enterprise or not. It was not always like this so I know my system can handle it but something that I cannot figure out is causing a slowdown. – ayao1337 – 2017-03-19T16:27:01.637

Apologies. I didn't catch that it was 800kbps from Android. I was thinking 800mbps. – David Woodward – 2017-03-19T21:08:01.700

@DavidWoodward No problem. Do you happen to know any possible causes for this? I just cannot understand what is happening. – ayao1337 – 2017-03-19T21:58:21.893

Afraid not. Fortunately I don't need to use SMB from Android enough to warrant spending a lot of time making it faster. I have noticed it's a bit slow, but I think the last time I used it I got closer to 3-5mbps or something like that. So, I would be thrilled with the 40mbps you get in the opposite direction (the direction I generally use). What app are you using to make these transfers on Android? Perhaps there's something in their implementation of SMB that would help explain this. (I usually use ES File Explorer) – David Woodward – 2017-03-19T22:34:14.460

@DavidWoodward I think you may be on to something actually. I was using ES File Explorer to transfer my files in the past and now. I used to receive 12MB/s but now I get 800kbps. I just tried a different file explorer (solid file explorer) and was able to obtain 3.5MB/s while es still gave 800kbps. It's still not as fast as it should be but it is an improvement. I'll try to downgrade Es File Explorer and see if I get faster speeds. – ayao1337 – 2017-03-20T12:08:20.787

Answers

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.

ayao1337

Posted 2017-03-18T22:20:48.917

Reputation: 478

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.

Paul-Sebastian Manole

Posted 2017-03-18T22:20:48.917

Reputation: 111