[Slightly OT?] Performance of SMB over WANs

Urban Widmark urban at teststation.com
Fri Mar 1 04:41:03 GMT 2002

On Fri, 1 Mar 2002, Jason Haar wrote:

> Our company's WAN runs primarily over IPSec VPNs. Benchmarking shows
> Linux-to-Linux FTP/HTTP peaks at around 80% of the available Internet link
> over which the VPN operates - so that's looking pretty sweet.
> However, Microsoft networking runs at ***1/10th*** that amount! i.e. SMB
> transfers are a fraction of FTP transfer rates. 

MS to MS?

> I originally thought this was a M$ stack issue, but then brought Samba in
> and benchmarked it on the same two Linux boxes used for the FTP tests - they
> had the same poor throughput.
> So, can anyone explain to me what's so different about SMB that would so
> radically affect it over a WAN link? I would have thought that after the
> initial auth/perms checks are done, the streaming of the data would approach
> FTP speeds...

HTTP is really simple, one request is all it takes to read a file, but SMB
can only transfer up to 64k in one message so it may need more 

You should probably take a look at how the client is reading the file. Use
ethereal or similar.

If windows has any parameters to set for how readahead should be done you 
may want to look at those.

If the linux smbfs client is involved in any of your tests then it is
expected that performance of raw transfers will be poor. It is doing
something like this:

read	--->
	<---	data (4k or less)
read	--->
	<---	data
read	--->
	<---	data

Which means that it waits for the reply to be fully read before requesting
the next page of data. It's bad enough on a 100Mbps LAN ...

But SMB allows multiplexing requests and it should be possible to do like

read 1	--->
read 2	--->
read N	--->
	<---	data 1
	<---	data 2
	<---	data N

Possibly with the requests and responses overlapping.

Note that not everything requires downloading the whole file. A program
might mmap the file and then only the accessed parts are downloaded. So as
with all benchmarks the 1/10th figure isn't the whole truth.


More information about the samba-technical mailing list