smbclient put 1/100 of the speed only

[Thorsten Schnier]

Hi !

I have a problem with samba that I cannot seem to solve: smbclient put
it extremely slow.

I am setting up a two-computer home network, with a '95 client (also
print server), and a Linux 2.2.0-pre8 server, using samba-2.0. I've
finished the setup, and most things work fine. However, I noticed that
doing a 'put' with smbclient is extremely slow. I've read the
documentation, and played with all kinds of options, installed winsock-2
on the windows machine (plus two newer patches), nothing helped. I tried
other kinds of communication between the machines, all fine, and
discovered that everything is fine (and much faster) if instead of using
smbclient, I mount the win95 file system and then use unix cp or mv:


Mounted smbfs, unix mv:


95 -> unix  983 KB/sec
unix -> 95  915 KB/sec


Mounted smbfs, unix cp:

95 -> unix  960 KB/sec
unix -> 95  471 KB/sec


using smbclient:

95 -> unix 580 KB/sec
unix -> 95 9.8 KB/sec   <-<-<- !!!!!!!!!!!!!


For comparison, I checked http unix -> 95, native 95 -> 95 (booting the
server in 95), and using win explorer to copy from a unix partition to
95, they all have a throughput of about 200 to 300 KB/sec (estimated by
counting seconds).


After discovering that put actually works fine using smbmounted
filesystems, I straced smbclient, and noticed the following (repeated
over and over):

write(3, "\0\0\10;\377SMB/\0\0\0\0\10\1\0\0"..., 2111) = 2111
select(4, [3], NULL, NULL, {20, 0})     = 1 (in [3], left {19, 780000})
read(3, "\0\0\0/", 4)                   = 4
read(3, "\377SMB/\0\0\0\0\210\1\0\0\0\0\0"..., 47) = 47
write(3, "\0\0\5\360\377SMB/\0\0\0\0\10\1\0"..., 1524) = 1524
select(4, [3], NULL, NULL, {20, 0})     = 1 (in [3], left {19, 780000})
read(3, "\0\0\0/", 4)                   = 4
read(3, "\377SMB/\0\0\0\0\210\1\0\0\0\0\0"..., 47) = 47


In other words, it writes, then waits 220ms for a read. From reading the
source, it seems the first read indicates the size of the packet, and
the contents (in the second read, 47 bytes) is probably some kind of
ack? Watching smbclient debug output, the delays are actually quite
visible.

It always waits exactly 220 ms, and with a packet size of 2111 bytes,
this exactly accounts for the throughput (in a test writing to a local
smb mount, the select call always returned immediately).

Now WHY it takes windows 220ms to send the ack I don't know, my
knowledge of windows is not very deep. All the tuning suggestions I've
found seem to be more fine-tuning of the TCP-Ip code, but this seems
more fundamental ? Other people found 'put' performance slower than
'get' but not this much...

Unfortunately, printing uses smbclient, and since print files can easily
reach 5MB/colour page, this renders the setup pretty much useless.


I'll appreciate any help...

thorsten



----------------------------------------------------------------------- 
       \    k                                       
        \   e                                          Thorsten Schnier
         \  y                       
     /\   \                              Key Centre of Design Computing
    /     / c                                      University of Sydney
    \    /  e                                                  NSW 2006
     \  /   n                      
      \/    t                                 thorsten at arch.usyd.edu.au 
    DESIGN  r                    http://www.arch.usyd.edu.au/~thorsten/
  COMPUTING e