max xmit default to 0x4104 (16644). Why ...
donmccall1 at yahoo.com
Mon Nov 3 12:41:35 GMT 2003
"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:
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
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,
Richard Sharpe <rsharpe at richardsharpe.com> wrote:
In tracking down a benchmarking problem, I discovered the following:
/* Was 65535 (0xFFFF). 0x4101 matches W2K and causes major speed
/* 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?
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org,
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
More information about the samba-technical