Slow write performance with Win 98 and Samba (fwd)

[Gerald Carter]

[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