samba - Jul 2004 - Windows XP - samba 1.1.9 slow file transfer problem

I'm experiencing a problem with slow file transfer from a Solaris 2.6
Samba 1.1.9 server to Windows XP clients. This problem does not occur
for Windows 2000 clients. In attempting to troubleshoot the problem,
I've run Ethereal on both clients and noticed a marked difference in
the logs of a transfer of the same file from the server.

The Windows 2000 logs shows AndX SMB requests and responses with
various sizes ranging around 1000-8000 bytes. The number of packets in
the TCP conversation to transfer the file is 42 packets. With Windows
XP the logs show AndX SMB requests and responses around 2 to 4 bytes
long. The number of packets required for that transfer is 571. The
time to transfer is 3 seconds on Windows 2000 and 30 seconds on
Windows XP.

A notable factor is that this SMB file transfer is occuring over a WAN
connection, so the long ACK delay may be the problem factor, but I
don't see how it would become a problem on Windows XP clients, but not
on Windows 2000 clients.

I've already tried changing the socket options parameter in the global
section of the smb.conf file on the server. It previously was set to
TCP_NODELAY, and I tried a setting of IPTOS_THROUGHPUT SO_SNDBUFF=8192
SO_RCVBUFF=8192.

Any suggestions? Would upgrading to Samba 3.x resolve this issue?

Thanks for any input. Greg Adams

On Tue, Jul 13, 2004 at 07:50:27PM -0700, Greg Adams
wrote:
> I'm experiencing a problem with slow file transfer from a Solaris 2.6
> Samba 1.1.9 server to Windows XP clients. This problem does not occur
> for Windows 2000 clients. In attempting to troubleshoot the problem,
> I've run Ethereal on both clients and noticed a marked difference in
> the logs of a transfer of the same file from the server.
Samba 1.1.x is *very* old. Please upgrade if just for securitys
sake.
> Any suggestions? Would upgrading to Samba 3.x resolve this issue?
Samba 3.0.x has been tuned to provide the same defaults to the
client as Windows 2000 - so hopefully you shouldn't get this
problem.

Jeremy.