Samba 3.0.1 read performance problem

Richard Sharpe rsharpe at
Sun Jan 18 22:03:27 GMT 2004

On Sun, 18 Jan 2004, Gerhard Wiesinger wrote:

> > I would venture to say that leaving those values unset, or setting them to
> > 65536 would give you better throughput!
> >
> OK, I tried (again) no option set and 65536 for the send buffer, but I'm
> quite away from the optimum (about 5000kB/s average now). I also tried
> buffer sizes up to 512KB, but performance still is not higher.
> > Grab an ethereal trace and look at a TCP Sequence Number graph. You should
> > see a stair-case effect caused by the delay between segments/packets as
> > the sending end is forced to wait for ACKs to clear out the unacknowledged
> > data in the send socket queue.
> >
> I had a look at the ethereal trace. With e.g. ftp it looks linear, but
> with Samba it is like a stair. I understand the problem, but why does it
> only appear with Samba?

OK, so now I would like to look at the actual trace ... to see what is 
going on.

I can check at work as well to see what read bandwidth we get ... The fact 
that we are still seeing a staircase effect suggests that we still do not 
have the window size or the send socket buffer correct. The window size 
is the receive window that Win2K is setting, and there is a registry 
setting we can effect.

However, it could also be that Windows is simply not submitting enough 
read requests to keep the pipe full, or the read requests are not big 
enough to keep the pipe full.

This we can check by looking at the tcpdump trace, but you will need to 
get it from the TCP connection start. The easiest way to do this is to 
kill the smbd for your Win2K client on the Samba server.

Richard Sharpe, rsharpe[at], rsharpe[at], 

More information about the samba-technical mailing list