Slow write performance with Win 98 and Samba (fwd)

[Christopher R. Hertel]

Scott Prather wrote:
> I have seen this problem also.  98 sends the ~64k SMBwriteraw then the
> small SMBwrite packet when sending to NT also.  The problem seems to be
> in the delayed ack for that small packet.  98 will time out waiting for
> that ack (~300ms each) before sending any more data to the server.

I have heard of this.  When I was at Connectathon the Sun folk talked
about this problem.  I think their solution was to pre-send the ack to
keep Windows going.  I need a better understanding of the problem.  I
would particularly like to know what NT is doing to prevent this problem. 

Jerry Carter wrote:
> > This looks like the problem you were working on.  Any progress?

I have been distracted.  I have some traces and some ideas (most of which
have come from other folks). 

Mike Gahagan wrote:
> >  I have been researching a problem with Windows 98 and Samba. The problem
> >  is a significant slowdown in certain types of files transfers. This
> >  appears to be a problem specific to a Windows 98 client uploading a file
> >  to a Samba server which is in "server" security mode.

I have *only* seen the problem manifest itself with Windows Explorer.  
On the same system, doing an upload to the server from the command line 
does not show the problem.

Mike Gahagan: could you verify please that the problem goes away when 
using the command line?

Anyone else:  I am told that this also happens with W/Me.  If there's 
anyone out there who hasn't given up on W/Me it would be nice to verify 
this.

> >  Problem Description
> > 
> >  When the transfer is viewed with a network packet analyzer, two different
> >  protocol modes are seen. Normally, Windows 98 will upload files using
> >  large file chunks, of about 64K bytes in size. There are sent with either
> >  an SMBwrite or an SMBwriteraw packet, followed by enough continuation
> >  messages to transfer the 64K chunk. Windows 98 is free to send all 64K
> >  without waiting for a reply. This is what I will call fast transfer mode.
> > 
> >  The slow transfer mode is characterized by a small SMBwrite of only 1536
> >  or fewer bytes, followed by an SMBflush command.

Note the comments under "strict sync" in the smb.conf(5) manual page.  I 
wonder if we can get rid of these parameters if we can get Samba to *not* 
cause this behavior.

I should mention that this is clearly a Windows bug, but that only Samba 
causes it to manifest itself.

> >  There are two reasons
> >  this is slow. The small packet size is all that Windows 98 can send before
> >  having to wait for a reply. The flush command causes the remote file
> >  system to write the bytes to disk before the flush reply can be sent back.

We work around the latter with "strict sync" and "sync always", but it's 
just a work-around.

> >  The Windows 98 client has to wait for both requests to travel the net and
> >  be replied to before the next small chunk of the file can be sent.

Right.  I call it 'rabbit poop packet mode'.

> >  Characterization
> > 
> >  There are six conditions which must be in place in order for this problem
> >  to occur:
> >  1. The client must be Windows 98 (not Windows NT).

     ...or could be W/Me

> >  2. The server must be Samba (not Windows NT).
> >  3. The Samba server must be in "security = server" mode (not share or
> >  domain mode)

     Right.  Same behavior seen here.

> >  4. The file being transferred must be uploaded (not downloaded).
> >  5. The file must be transferred by the Windows explorer (not a command
> >  line copy).

     Yes.  (Forget my comment earlier about testing the command line.)
     It seems to be a Windows Explorer bug.

> >  6. The drive must have been mapped by name (not by IP address).

     Again, based on the information I have, I concur.

> >  Using the six conditions, the problem is produced 100% of the time. If any
> >  one of the conditions are changed, the problem is not produced. If any of
> >  these six conditions are not met (are replaced by their alternative), then
> >  Windows 98 will choose fast transfer mode. In condition two, Samba is
> >  specified as the server. This is because we haven't tested with any other
> >  type of server which is not participating in the Microsoft Networking
> >  Domain as Windows NT would. Also, I did not mention Windows 98 in
> >  condition two, because I have not tested with Windows 98 as the server.

     Yup...

> >  Samba is certainly always affected by this, so it makes a good test
> >  platform for reproducing the problem.

     I'd say, rather, that W/98 Explorer is affected by Samba... The key 
     here is that Samba is causing W/98 Explorer to go into this mode so 
     we need to know what Samba is doing differently.

     One place to look is in the NegProt.  My traces comparing against NT 
     show that we are not doing what NT does.  I noted particular 
     discrepency in the negotiation of Unicode.

     Could that be where the problem lies?  I don't know.  I think that 
     Scott may have hit on at least part of the problem with the ACK 
     timeout issue.

> >  I have noticed during packet tracing that name resolution causes Windows
> >  98 to open a session with the Samba server directly. If the IP address of
> >  the Samba server is used instead, the name resolution system fails, and
> >  Windows 98 resorts to doing an NBSTAT request to the Samba server itself.
> >  This returns the full list of names the server has registered, which
> >  Windows 98 then uses to open a direct session. When the latter name
> >  resolution method is used, Windows 98 always chooses fast transfer mode in
> >  any uploads to the drive being mapped. If the same drive is mapped by name
> >  (even at the same time), all file uploads are in slow mode.

This is weird because, as you point out, the NBSTAT process is followed by
a direct connect.  So, following the name resolution process, the
behavior, in theory, should be the same. 

...but yes, I have reports of the same thing from other sources.

<snip>

> > This seems to be a problem with Windows 98 forcing the use of the small
> > block size, possibly because it doesn't think that the Samba server is an
> > authenicated member of the domain.  

Possibly.  Interesting idea.

> > Is there any workaround for this that
> > would force the client to always use the 64k block size through Windows
> > Explorer?

Don't know.

My goal is to figure out what Samba is doing to cause this bug to 
manifest.  How do we differ from NT, since NT servers don't cause this to 
happen.

> > 
> > Thanks in advance...

Help me out folks.   I want to nail this one!

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services

    Ideals are like stars; you will not succeed in touching them
    with your hands...you choose them as your guides, and following
    them you will reach your destiny.  --Carl Schultz