SAMBA digest 2551

Marco Bizzarri 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
>         then
>                 socket options = TCP_THROUGHPUT IPTOS_THROUGHPUT
>         then
>                 both
> 
>         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.
> 
> --dave
> --
> 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.

Thanks!

Bye
Marco


More information about the samba mailing list