> On Sun, 15 Nov 1998, Jan Kratochvil wrote:
> Hmmm... are you saying the Ethernet driver was broken on the Windows
> machine, or under Linux? I assume the DOS/Win machine.... I may look into
No - Linux. :-) Becker's tulip.c was the one distributed with Linux kernel
(not the one from Becker's web) and it was dropping packets massively
probably
due to missing PCI kludge settings (don't ask more - just the only possible
part in CHANGES).
> new drivers - but my 2 client machines here at the house use different
> network cards, hence different drivers. The results are similar, so I
> guess that's not an issue...
OK. Probably not a problem.
> > Please send me some fragment (but large enough to stabilize the
results -
> > - about 2000 lines at least)
> In light of my answer below, we may want to skip the log for now - if you
> still want to look at one, and think you can help me "tune"
things, I'll
> be happy to send one tomorrow...
As it looks it will really probably be not the right showstoppper as you
say... I'll not bother now. :-)
> > If it is a lot of small files, try using 2.1.x kernels. They are
> Ok, you *REALLY* hit the nail on the head there. I started off my
> benchmarking with a single LARGE file (500MB CD-ROM image file), and had
> gone from that to copying a directory tree. The directory in question was
> Borland C++ Builder. About 300MB worth of C++ compiler stuff! A *LOT* of
> small files in there too.... plus just a lot of files period (3000+).
I assume that Samba is already compiled with -DFAST_SHARE_MODES. Anyway
the locking is still not the easiest work for Samba. Removing locking/sharing
will probably improve the performance a lot (just guessing) but ...
... it's not the best to do it for the production machine. :-(
It would be nice to profile samba (gcc -pg) but it's rather Andrew
Tridgell's
[hi and thx - not only you - for all this stuff] problem. :-)
> Sooo.... I went back to testing, from a different PC this time, and get
> some different results - this time as a client from both Win95 *AND*
> Linux, and with the socket buffer size options *NOT* in my smb.conf:
>
> Copy Single 45MB file FROM server
> ---------------------------------
> 1. Linux 2.0.35, using NFS: 1:12 (630 kb/sec)
> 2. Linux 2.0.35, using smbfs: 0:49 (926 kb/sec)
> 3. Linux 2.0.35, using smbclient: 0:46 (952 kb/sec)
> 4. Linux 2.0.35, using ncftp: 0:39 (1.1 MB/sec)
> 5. Win95, using mapped drive: 0:52 (872 kb/sec)
In point (2) Try using 'cat x >y' instead of 'cp'.
There's a performance problem
in kernel which can be fixed by tweaking reported filesystem blocksize
constant 1024 to 4096 in
/usr/src/linux/fs/smbfs/proc.c/smb_init_dirent()/fattr->f_blksize=1024;
I wrote about it to samba@samba.anu and linux-kernel@vger but with
no response. :-(
> Obviously, when just doing raw data transfer - i.e. not opening and
> closing a bunch of files - Samba is coming close to FTP in speed. Some
> further testing with different mixes of files show that as the number of
> small files increases, the overall transfer rate drops towards the 500
> kb/sec mark that I've been seeing.
>
> I suppose that if I were to upgrade to a 2.1.xxx kernel, this would
> improve. However, being as I am putting this system into a production
> environment in a couple of days, I think I will stay with the 2.0.36
> kernel I am running right now, along with a production release of Samba...
Hmm...
> > You have the sources, the ultimate, unlimited power! :-)
[snipped]> doing that with a commercial OS! ;-)
:-)
> Thanks for all your advice - and you did give me the clue that led to the
It is a personal challenge - some buch of crap outperforming Linux... :-(
> answer (i.e. lots of small files). So now I can go to bed and quite
I've slept 1:30 now (and was awakened by mail notification as GSM mobile
SMSes), now it's 8:25AM. :-)
> worrying that this $7000 PC I've assembled on the dining room table is
not
> performing as it should.... :-)
Ouch - pretty fat price. :-?
> Thanks!
You're welcome. Not much solved in real world but we know where the dog
is digged in now (at least I *think* I know).
> | Jim Morris | jim@morris.net |
Lace
