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

Richard Sharpe rsharpe at
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:
> Q99234
> and
> Q223140
> and
> Q279282

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 
refers to:

   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], rsharpe[at], 

More information about the samba-technical mailing list