I've recently set up Windows file sharing over a gigabit ethernet network (I'm not using jumbo frames) with a Samba server and a Windows Vista client. I've done a few file copies, but the maximum throughput I'm seeing is 20MB/s (megabytes, not megabits) which is about 15% of the theoretical 125MB/s maximum for the network. The server has a RAID array that can manage about 75MB/s (the bottleneck is the PCI bus), and the client can manage about 40MB/s in a disk-to-disk copy.

I should add that there was no other traffic on the network at the time.

I understand I won't ever get the theoretical maximum, but I didn't think it would be this bad.

What's the typical performance of Windows File Sharing (SMB) on a gigabit ethernet network?

Bonus points: what can I tune (besides using jumbo frames) to make this faster?

  • 2
    I've fixed the performance problems on my network: they were a combination of a poor on-board NIC on the server and old NIC drivers on the client. I'm now seeing between 50MB/s and 80MB/s on a few bulk copies I did to test. Though, the transfers do seem to pause unexpectedly for a few seconds, from time to time. – Kaypro II Jan 17 '10 at 7:47
  • 1
    Another cause of my poor network performance was that by merely running Virtual PC (without necessarily having any images running), something seems to throttle my NIC to ~100Mbps on my Vista machine. – Kaypro II Jan 23 '10 at 1:10

The quality of your network cards, switches, and cabling can all have an effect. It might be worth searching for reviews of the NICs and switch(es) you are using to see if other people report them as not performing too well. I'm tol that built-into-the-mothboard NICs are worse of Gbit transfers, though in my experience this doesn't seem to make much, if any, difference in my environment.

As a point of reference, I've just install a new Gbit switches in our office (replacing old 100Mbit switches) and large SMB transfers run at close to (but less than) 30Mbyte/sec between each combination of machines I tested. I've just done a quick test with netcat between two of the machines and got similar results so I don't think that SMB is the bottleneck. The two machines I just tested do have two switches between them which may have an effect, but I guess that effect is minimal given how close the figures where to an SMB transfer to a machine on the same switch.

The best transfer rate I've seen over a Gbit network was a little shy of 50Mbyte/sec at its fastest. This was while transferring a drive image from one machine to a file on the other (for the purposes of converting to a VMWare virtual drive. In that case the two machines were connected via a short cross-over cable rather then via a switch. Coincidently one of the machines in question was one of the machines I've just tested and got ~29Mbyte/sec from - the most likely culprit for the main bottleneck in my case is probably the 8 year old wiring in the building that may have been done on the cheap! A quick (and equally unscientific) test on my little home network sees transfer rates more like 35Mbyte/sec copy a file from a Samba share to a Windows box and 25Mbyte/sec in the other direction (I'm not sure why there is a discrepancy there as in both cases the copy was manages by teracopy on the Windows box - I might have to investigate that further at some later time).

Jumbo frames are going to make a difference for bulk transfers, so I suggest you give that a try if all your kit supports them properly.

To cut a long story short: going by my anecdotal experience your 20Mbyte/sec is a bit slow, but not massively so. All my Windows and Samba installs are pretty much completely untuned, so I suspect that your hardware/wiring are the difference between what I see and what you see.


Of course, five years on from this answer, hardware and software has moved on. I often see 90+ MiB/sec transfers on machines with Gbit networking even with cheap kit. My home media/backup/other server seems limited to a little over 60 for bulk for transfers but that seems to be samba being CPU-bound on a single core of the box's hardware.

| improve this answer | |
  • Cabling shouldn't be an issue for me, the gigabit portion of my network is completely CAT6. I can't use jumbo frames because my (home) network is heterogeneous - I've got wifi and a 100Mbit segment - and it's my understanding that jumbo frames are gigabit-only. Though, if I could limit jumbo frames to certain pairs of hosts, that might work. That's a good point about the hardware. All of mine is consumer grade; I'll have to look into that. Another thought that I had is how the built-in NICs are connected may be an issue. If one's on the PCI bus, that could be a factor. – Kaypro II Nov 22 '09 at 22:42
  • 1
    don't you mean "your 20Mbyte/sec is a bit slow, but not massively so" (there ate the end)? otherwise +1, nice writeup. – quack quixote Nov 23 '09 at 1:33
  • Good catch ~quack, duly edited. – David Spillett Nov 23 '09 at 11:15
  • arrrgh. sadly i can't edit comments, or i'd stop eating the end... – quack quixote Nov 24 '09 at 20:18

Ahh...this is where it is important for a server guy to understand what's under the hood. Since this is two years old I figure he's solved it already. However for posterity or anyone with a similar issue what he probably ran into is this

(TCP window size * 8bits / RTT in milliseconds) = Max TCP throughput in bps

While you might have a Gigabit network a single TCP flow won't likely be able to get that high.

Here is a simple table assuming you have the default 65535Byte TCP window size in Vista

RTT 10 ms => TCP throughput = 52428000 bps = 52Mbps

RTT 20 ms => TCP throughput = 26214000 bps = 26Mbps

RTT 50 ms => TCP throughput = 10485600 bps = 10Mbps

RTT 100 ms => TCP throughput = 5242800 bps = 5.2Mbps

RTT 150 ms => TCP throughput = 3495200 bps = 4.3Mbps

RTT 200 ms => TCP throughput = 2621400 bps = 2.5Mbps

RTT 300 ms => TCP throughput = 1747600 bps = 1.7Mbps

RTT 500 ms => TCP throughput = 1048560 bps = 1Mbps

At 20Mbytes/sec or 160Mbits/sec your roundtrip latency is likely on the order of about 3 milliseconds. The only other way to speed that up is by using TCP optimizers that do de-dup over the wire or splice together fragments into larger packets. Over a LAN that likely isn't going to gain you much for the expense. If you are using SoHo gear like Linksys or Netgear your latency is probably getting introduced by the lack of shared buffers on the switch. If it's a larger switch like a 24 port, try making sure that the two devices are connected to the same ASIC. This will help the serialization delay, but not by much. If you could drop it down to 2ms you'd get a boost up to about 31-32Mbytes/sec. If they are on two different switches there isn't much you can do without new hardware.

| improve this answer | |

Not that this helps you in this instance but Vista/Windows 7 talking to a Windows 2008 Server will use SMB2 which is much more efficient than plain SMB and will utilise much more of the network bandwidth. See File Server performance improvements with the SMB2 protocol in Windows Server 2008 and Enhanced Network Performance with Microsoft Windows Vista and Windows Server 2008 for more info.

SMB2 is being worked on in Samba 4 but it looks like it is being backported to Samba 3.5.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.