max xmit default to 0x4104 (16644). Why ...

[Richard Sharpe]

On Mon, 3 Nov 2003, Don McCall wrote:

> "On a read customer would expect to see 61440byte packet sent,
> they have traced and found that it is sending 61377byte packet request
> on the read and then 63byte request to make up the rest of the request
> Looking at the negotiate protocol, the main difference between the two 
> is nt server responds with capabilities of using unicode strings, and 
> with NT MAX buffer size = 0x1104 (4356 decimal)
> we respond to the same client that we cannNOT use unicode strings, and 
> our NT MAX buffer size = 0xFFFF (65535 decimal)...

OK, so the issue here is that a large read is split into one that is 
63-bytes shorter than expected and then the 63-byte end piece is read 
after that. (Did they really ask for 61440 rather than 65536? I have seen 
65536-byte reads similarly split.)

However, was this really causing perforance problems?

My issue is that 32kB reads are split into two 16kB reads and that limits 
performance because of the extra CPU overhead (even with sendfile in use).

I also have a trace of a copy from Samba to W2K SP4 of a large file 
showing that it will use larger than 16384 if you set the max xmit size to 
65525. I do not see any performance problems in this copy. I will look 
again.

I realize that we can tune this value in the smb.conf, but suspect that a 
default of 32768+a bit (256) would probably be better. However, I haven't 
yet looked at the kb articles :-)

Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com