SAMBA digest 2551
m.bizzarri at icube.it
Fri Jun 9 22:04:38 GMT 2000
> Date: Thu, 08 Jun 2000 11:31:17 -0400
> From: David Collier-Brown <David.Collier-Brown at canada.sun.com>
> To: Marco Bizzarri <m.bizzarri at icube.it>
> Subject: re: Samba performance problem over a radio link.
> Message-ID: <393FBC45.F98BB11 at canada.sun.com>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Marco wrote:
> | We have a performance problem over a 2 Mbits radio link.
> >From your message, it looks like this is what you have, in
> the same units: please correct me if this isn't right, as
> I'm really reduced to guessing from your description...
> Description KB/S Kbit/S Mbits/S % of max
> Theoretical Max. 100 Mbit/S Eth. 12500 100000 100 100
> local smb read, win9x 5000 40000 40 40
> local smb read, win9x to NT server 160 1280 1.28 1.28
> This can't be true...
Of course it can't. My mail was not at all clear. Performance, according
to your schema were:
On the 100 Mbit Ethernet
local smb read, win9x 5000 40000 40 40
local smb read, win9x to NT server --- NOT measured
On the 2 Mbit/s radio
remote smb read, win9x 70
remote ftp read, win9x 100
remote smb read, NT 100
remote smb read, win9x to an NT server 160
Is this a little more clear?
> I'm going to assume you want to know why Samba
> with win9x clients is slower than ftp and NT clients
> over the speed-limited link.
> I **think** that the win9x SMB client program is not
> as good as packing lots of no-response-required
> operations into packets as the NT SMB client, and this
> shows up strongly on the speed-limited network. The
> client send a request, and starts waiting for an ACK.
> This is called "stop-wait" processing, for obvious
> reasons (;-)) The desired behavior is to send a bunch
> of requests and never wait.
> Playing with the receive window will allow the sender to
> send as many packets, containing SMBs, as possible, but the
> SMB protocol can defeat this. I suspect that's why the
> improvement from playing with rwin levels off suddenly.
> TCP gurus, do please chime in!
> I think you might try two experiments: tuning the TCP for
> large file throughput (normally not recommended) and turning
> off raw read/write (ditto).
> In three separate experiments, try
> read raw = no
> write raw = no
> socket options = TCP_THROUGHPUT IPTOS_THROUGHPUT
> If any causes a significant improvement, please tell
> the list: these are contra-intuitive approaches...
> Once we're past this, we'll look at SO_SNDBUF= with large values.
> David Collier-Brown, | Always do right. This will gratify some people
> 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
> Willowdale, Ontario | //www.oreilly.com/catalog/samba/author.html
> Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb at canada.sun.com
Ok, I will try all the suggestion, and then I will make you know what
are the results.
More information about the samba