Slow write performance with Win 98 and Samba (fwd)

Scott Prather sprather at austin.ibm.com
Wed Jun 20 14:25:19 GMT 2001


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.  

--
Scott Prather
MCSE, MCP+I
Software Engineer
AIX PC Interoperability
sprather at austin.ibm.com
(512)838-3313

> [moved to samba-technica...]
> 
> 
> Chris,
> 
> This looks like the problem you were working on.  Any progress?
> 
> 
> 
> 
> 
> 
> cheers, jerry
> 
> ---------- Forwarded message ----------
> Date: Tue, 19 Jun 2001 18:31:42 -0400 (EDT)
> From: Mike Gahagan <mgahagan at redhat.com>
> To: samba at lists.samba.org
> Subject: Slow write performance with Win 98 and Samba
> 
>  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.
> 
>  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. 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.
>  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.
> 
>  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).
>  2. The server must be Samba (not Windows NT).
>  3. The Samba server must be in "security = server" mode (not share or
>  domain mode)
>  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).
>  6. The drive must have been mapped by name (not by IP address).
> 
>  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.
>  Samba is certainly always affected by this, so it makes a good test
>  platform for reproducing the problem.
> 
>  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.
> 
>  Putting the Samba server into domain mode was also tested. Named mapping
>  caused Windows 98 to choose fast transfer mode. The packet traces of a
>  server mode versus a domain mode name lookup, drive mapping, and file
>  transfer were compared, and no significant differences were found. What
>  was different was the name of the Samba server (two were used), the
>  session ID, the session key, the encrypted password, the multiplex ID, and
>  the TCP port, acknowledgement, and sequence numbers.
> 
>  Test Data
> 
>  I used the following minimal smb.conf files to produce this problem. The
>  tests were done on a Samba server running version 2.0.7, but I have
>  reports that this same problem can be demonstrated on later releases of
>  Samba. The Windows domain "CENTRAL" PDC, and the WINS server are the same
>  machine: A Windows NT server at 10.240.27.29. The use "tester" is a
>  valid user in the domain, and on the Samba server.
> 
>  Here is the share mode smb.conf, which causes fast transfers no matter how
>  the drive is mapped:
> 
>  [global]
>     workgroup = CENTRAL
>     security = share
> 
>     interfaces = eth0
> 
>  [test]
>      path = /test
>      writable = yes
>      guest ok = yes
>      guest only = yes
>  ;end_of_section -- Tag line do not remove
> 
>  Here is the server mode smb.conf I used. This configuration goes fast with
>  IP address mapped drives, and slow with name mapped drives:
> 
>  [global]
>     workgroup = CENTRAL
>     security = server
> 
>     encrypt passwords = yes
>     username level = 20
>     interfaces = eth0
>     password server = 10.240.27.29
> 
>  [test]
>     path = /test
>     writable = yes
>     valid users = "tester"
>  ;end_of_section -- Tag line do not remove
> 
> 
>  I have captured two packet traces using a third host which is attached to
>  the same 10baseT hub as the Windows 98 client. The first one shows a chunk
>  of a file being transferred in fast mode. This was captured with the
>  "security = server" smb.conf file in effect, with the drive mapped using
>  its IP address. One write raw packet is shown (with the large buffer size)
>  followed by one of the many continuation packets that are needed to write
>  the remaining bytes up to 64K. I can post the packet traces here if
> needed.
> 
> 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. Is there any workaround for this that
> would force the client to always use the 64k block size through Windows
> Explorer?
> 
> 
> Thanks in advance...
> 
> Mike
> 
> 
> 
> -- 
> ------------------------------------------------------------------------------
> Mike Gahagan, RHCE                     | Red Hat Inc.
> Commercial Services Group              | Meridian Office
> mikeg at redhat.com                       | Durham, NC
> -----------------------------------------------------------------------------
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  http://lists.samba.org/mailman/listinfo/samba
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  http://lists.samba.org/mailman/listinfo/samba
> 
> ----- End forwarded message -----
> 




More information about the samba-technical mailing list