[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: funny idle time from time

On Sat, 1 Sep 2001 12:18, Wouter Verhelst wrote:
> I agree with most of what you say, but not with this. You can say a lot
> about NFS, including that it's bad, insecure, to be thrown away and
> changed by CODA or sth else, but not that it's slow.
> I've seen data transfers of ~800KByte/s via NFS. Over my 10MBit coax
> network. From a Pentium 166 to a Pentium 133. I don't know any other
> network file serving protocol that can do this.

What other network protocols have you tried?

I have attached the results from running Bonnie++ with my Thinkpad (P3-650,
256M) as an NFS client with both 10 baseT PC-Card and 100baseT CardBus
network cards connected to an Athlon 800 with 256M, PCI 100baseT card and
with a full duplex switch in between.  The only time that NFS is really
efficient is bulk input.

I mounted the NFS share with rsize?92,wsize?92,nolock.

Both machines run 2.4.9 and the NFS serving is in the kernel.

I tried using smbfs but it dropped out under load (seems to be a bug in the
client code).

I tried making the Thinkpad the NFS server, but it wasn't fast enough and the
client thought that it had fallen off the net and started the laborious
back-off process (which kills performance).

The end result, NFS isn't nearly as fast as it should be, but SMB is worse
because I couldn't get it to work.

Let's redirect this discussion to debian-user...

http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page
Title: Bonnie++ Benchmark results
Version 1.92aSequential OutputSequential InputRandom
Sequential CreateRandom Create
SizeChunk SizePer CharBlockRewritePer CharBlockNum FilesMax SizeCreateReadDeleteCreateReadDelete
K/sec% CPUK/sec% CPUK/sec% CPUK/sec% CPUK/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU/sec% CPU

Reply to: