Hi everyone,
Since as long a way back as I can remember I've been using Linux and
Samba, I've been wondering why the throughput across a switched 100Mbps
link wouldn't go beyond 2MBps to 3MBps. I've tried all sorts of wiring
setups, Samba socket options, et al. I've never had a Linux client with a
100Mbps link, though, and I've never had the patience to methodically test
things. I've either blamed the switch (which is an Intel InBusiness
10/100Mbps switch, nothing like those managed switches) or the fact that
FAT/VFAT sucks. ;>
Tonight I did some tests and I'd like to share them with the group.
The trigger was getting proftpd installed (the bliss of Debian: apt-get
install proftpd) on Gusi, my primary file server, and lftp on Spolario, my
design workstation and one of our fastest aside from the server, which now
dual-boots Windows 98 and Linux (2.4.7-xfs kernel, with an optimized XFS
filesystem).
A simple 'get filename.iso' resulted in a whopping average of 7.74MBps
transfer. No FTP optimizations done on either end. This was a 600MB ISO
image (great way to test everything in my system from the LAN to XFS to
the RAID5 system, although admitted does not isolate the network
transfer).
This immediately ruled out the need to get a new switch. The Intel
InBusiness does it's job, at least when one and only one file transfer is
being done.
So I worked on Samba: I downloaded my custom-built i686 optimized packages
from Gusi onto Spolario, installed them, and matched the smb.conf socket
options on both machines to "IPTOS_LOWDELAY TCP_NODELAY SO_SNDBUF=4096
SO_RCVBUF=4096". I used smbclient and did a get of another ISO image. This
time it was a little better than normal, but much lower than the ftp
performance. An average of around 4700KBps. Ouch. For all my capacity and
this great 3ware card, for all my tuning and my work with XFS ... I get a
lousy 4700KBps, but it's because of Samba.
I remember the man page recommending only the first two settings, so I
decide to match both smb.conf files to have socket options of only
"IPTOS_LOWDELAY TCP_NODELAY". Again I use smbclient and get yet another
ISO image (I have enough to do my tests, hahaha!). Now I'm much happier. I
get 7679KBps, which is very near my FTP results! Yeah!!!
So I do yet another test. Keeping the smb.conf options, I test smbfs by
mounting the share on a mountpoint and do a "cp -a testfile /dest" and
watch the results of the transfer via IPTraf running on the server. Not so
good, as it's around 4700KBps, too.
BTW, I also did a test of lftp's pget parallelizing the get five times and
the results were not good. Somewhere to the tune of 5MBps, too. Wierd.
I decide to be fair to Windows, and reboot Spolario to run Windows 98. I
fire up the System Monitor set to monitor the Microsoft Network Client
data transfers, and copy one of my ISO images. Unfortunately there is no
significant improvement. A rough average of around 4MBps as before. :(
Conclusions:
o To transfer my ISO images to Spolario (to unload the server) I will use
lftp's mirror command without parallelization. I will also see if mget can
recurse directories. I was thinking of using a mounted Samba partition for
this but it doesn't look like that would do me any good. This way I retain
the date and time of creation, and am pretty confident the md5sum remains
intact.
o Try the above mentioned socket options, they might benefit you.
o With more time, patience, energy, et al, maybe I will try NFS, Coda,
AFS, SFS, et al.
o I'm _sure_ SCP won't be too good, that CPU overhead will tax the
transfer.
--> Jijo
--
Federico Sevilla III :: [EMAIL PROTECTED]
Network Administrator :: The Leather Collection, Inc.
_
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
To subscribe to the Linux Newbies' List: send "subscribe" in the body to
[EMAIL PROTECTED]
