> Date: Thu, 08 Jun 2000 11:31:17 -0400
> From: David Collier-Brown <David.Collier-Brown@canada.sun.com>
> To: Marco Bizzarri <m.bizzarri@icube.it>
> Subject: re: Samba performance problem over a radio link.
> Message-ID: <393FBC45.F98BB11@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@canada.sun.com
>
Ok, I will try all the suggestion, and then I will make you know what
are the results.
Thanks!
Bye
Marco