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

[Don McCall]

"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)...
I modified OUR code so that we returned the same NT MAX buffer size
and resolved the problem.
After seeing this, did some poking around at the MS sites, and 
noted the following microsoft articles that discuss this phenomena:
Q99234
and
Q223140
and
Q279282
Bottom line is, depending on the client, this read performance 
enhancement may have write performance degredation; best bet would be 
to make the Max NT Buffer Size field in the negprog.c module a smb.conf 
parameter so it could be tuned based on the particular customer sites 
needs, as is done with the Microsoft servers via the registry key 
ReqBufSize...
So I talked to Jeremy about it, and that's what we did.
 
You could get a trace of it by setting the max xmit smb.conf back to 65535 and running a test using the various clients.  We made it tuneable because different servers returned different values for this, and this way you could emulate the behavior that best matched your client needs.
 
 
Hope this helps,
Don

Richard Sharpe <rsharpe at richardsharpe.com> wrote:
Hi,

In tracking down a benchmarking problem, I discovered the following:

/* Was 65535 (0xFFFF). 0x4101 matches W2K and causes major speed 
improvements... */
/* Discovered by 2 days of pain by Don McCall @ HP :-). */
Globals.max_xmit = 0x4104;

This causes me major problems and I was wondering why the previous value 
(of 65535) caused problems with Win2K.

I have not yet tested with Win2K and my testing has been confined to using 
cifs_bm, but it also seems unlikely to be a problem on the surface. This 
is the setting of the max amount data that Samba is capable of writing in 
one go. If Windows does not like it, it is free to use a smaller size in 
read(&X) requests if it likes to.

I wonder if anyone (Don McCall?) has a capture of this behavior so we can 
see what exactly is going on?

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


---------------------------------
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears