max xmit default to 0x4104 (16644). Why ...
rsharpe at richardsharpe.com
Mon Nov 3 18:43:34 GMT 2003
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)...
> 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:
OK, I am confused now ...
My trace of a Win2K SP4 client copying a 1.3GB file from Samba shows that
after some initial messing around, it then seems to settle down to copying
61440 byte chunks from the server (this is with max xmit set to 65535) and
each of the segments seems to be spit out quite quickly and the subsequent
request is sent by Win2K quite quickly as well.
If we look at the KB articles referred to above, we see that Q99234
SizReqBuf is the size in bytes for buffers that the server uses to take
requests from workstations.
and Q223140 relates to
SMB Block Size Negotiation When Copying Files with Windows NT Explorer
which is getting closer and does mention 32768 and Q279282 relates to
Slow File Write from Windows 2000 to Windows NT 4.0 Server
which seems to be the opposite direction to what we are interested in and
it suggests setting SizReqBuf on NT systems to 65535!
In addition, I have copied a 1.3GB file from Samba to Win2K using DOS (as
I said above) with max xmit set to 65535 and 32768 and there appears no
subjective difference in the time taken. I will now try it with the
Explorer, which seems to be the issue as well.
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org,
More information about the samba-technical