Transportation tuning tips.

[Kenichi Okuyama]

Dear all,

I'm new here. So, if this is not the right place to talk, please
do tell me so.


I think there are several key tips missing on "smb.conf.5".
( or I might be mis-reading the manual, but at least, I couldn't
  find the very key words when I read it.)


1) Service Parameter "include":
   Even if you fail in reading "include file", smbd will not fail.
   It simply skip to next line.

2) Only "very last declared" 'socket options' line will take effect.

# Or, am I wrong? ... but at least, it works on 2.0.6 ....


Here is what I have just experenced that I beleave they are so important:

            ----------------------------

I'm using Samba 2.0.6 on FreeBSD(from now, I'll call this machine
'Samba'), connecting Windows98SP1 on ThinkPad535E with Laneed
10/100CD(from now, I'll call this machine 'Win98'), and WindowsNT4
SP6a(from now, I'll call this machine 'WinNT').

When I tried to send 12Mbytes of files from Samba->Win98, it took me
660 sec. I thought that this was the normal case, but when I (by
mitake) tried Win98->Samba direction, it only took 30sec for
transfer.

So, I decided to measure the time, and what's going on using tcpdump
on Samba. Here are the results:

Samba->Win98:  660sec
Samba->WinNT:  600sec
Win98->Samba:   36sec
WinNT->Samba:	40sec
Win98->WinNT:	31sec
WinNT->Win98:	33sec

What was happening on Samba->Win* was, that Windows drops many IP
packets, right after they sent Ack, but FreeBSD tries to send as
much as possible. Then, since there are so many "resend" request ack
pattern, FreeBSD sleeps for 1sec to settle, then start sending
again.

This "1sec sleep" occurs from 500 to 550 times on Samba->Win*. And
this was the reason why it's taking so long time.
I did set SO_SNDBUF to 8192bytes, but this still occur.

So, I looked at Win98->WinNT sending pattern and found that,
if Winsock2 communicates with Winsock2, sender takes following steps:

   Send IP packet.
   Send IP packet.
   Wait for Ack.

Also, for some reasons I could not figure out, Win98 will claim for
mss=536 against Samba, and 1460 against WinNT.

WinNT's mss was always 1460bytes.


# It was NetBIOS/TCP transfer. I did check it with tcpdump.


Finally, I've found the way to make Samba take exactly the same
steps as Winsock are doing. That is:

1) find out the mss size of specific target.
2) Set SO_SNDBUF to '<mss size>*2'.
   (even <mss size>*2+4 will mess the balance :p)

By this, though I could not fix the mss, I got good performance of

Samba->Win98:	30sec
Samba->WinNT:	35sec.


Now, the problem was, that I wanted to change SO_SNDBUF for each
machine smbd was connecting to. But there were no guide about it.
Nor, smb.conf.5 had any comment about "include will not make smbd
fail even if file was not found."

... I did found those things out, by try-and-error + many helps from
Japanese Samba user group peoples. So, my final smb.conf's [global]
field looks like:

[global]
  .....
  # all the general settings being defined above.

  include /usr/local/etc/smb.conf.global.%a
  include /usr/local/etc/smb.conf.global.%M
  include /usr/local/etc/smb.conf.global.%a.%M

and having:

smb.conf.global.Win98.Win98.my.network:
  socket options = TCP_NODELAY SO_SNDBUF=1072

smb.conf.global.WinNT.WinNT.my.network:
  socket options = TCP_NODELAY SO_SNDBUF=2920


With them, now I have (at least) as same performance as
WinNT<->Win98 communication.


So, I beleave that:

* include will not fail smbd even if file is not found.
* only very last line of 'socket options' will take effect.

is very important keywords.

#Plus, above tips is important for Speed.txt.

---- 

By the way, Is it possible to print out mss size to smb.log?
I don't think it is nice idea to use tcpdump everytime you need to
tune for stupid Network Interface cards.

# Or, if there are way to have mss size like %MSS on smb.conf,
#it's also nice, I beleave.

best regards,
---- 
Kenichi Okuyama@ Tokyo Research Lab. IBM. Co. Japan