Subject: Re: [netatalk-admins] netatalk+asun benchmark (afp/tcp)
From: Dave Zarzycki (zarzycki@ricochet.net)
Date: Wed Dec 31 1997 - 13:33:29 EST
On 12/31/97 9:47 AM, Nicolas MONNET (nico@idnet.fr) wrote:
<...snip...>
>> >> test software: ThruPut 1.2
>
>> > What is it?
>
>> A very simple program that reads and write to files on a mounted volume
>> to measure performance. When I did the test, I picked 4MB files and only
>> to use one of them. That way the file would stay in the cache on the
>> server, and we would spend more of our time transferring bits than
>> negotiating which bits to transfer.
>
> It's always interesting (if not essential) when you're talking
>benchmarks to know exactly what the program is doing.
Yes, but I was just trying to see how quickly we could push bits out the
network adaptor. That is why I made the setup the way I did. I made sure
that the files stayed in the (RAM) cache because I had plenty of RAM to
hold three 4MB files (one for each client). Therefore hard drives and
SCSI are no longer a bottleneck.
<...snip...>
>> Ah, I would argue differently, unless you are speaking generally for any
>> workstation and not a server.
>>
>> + Server OS (drivers, drivers, and optimization or lack there of.
>> As far as I could tell, the tulip driver needs better optimization.)
>
> Right, but I had Linux in mind, which uses all the ram it has for
>buffering anyway.
You are correct, but let me reiterate, I was processor bound, therefore
the fastest I can go out of this box is 134Mb/s. I can add more RAM to
cache more data, and more hard drives to increase disk throughput, but
the speed limit will always be there until I upgrade the processor or
more importantly, tweak the tulip driver to go faster. Let me explain:
90% of the CPU was being utilized by the system, and the tulip driver
obviously had it's hands full by looking at the console. I have several
clients here at work that can saturate Fast Ethernet (individually), if
the server is fast enough, but the tulip driver couldn't do it (Or Linux
couldn't, eek!) I could get only 7-8MB/s per adaptor (not at the same
time of course). Therefore, I would conclude that to raise the maximum
speed of the server, I would fix the ethernet driver on the server.
I guess it's time to turn of profiling in the kernel...
>> + Processor/cache (When I was doing the test, most of the time was spent
>> in the system and not user space. I was processor bound when I got
>> the numbers I did.)
>
> Hm, from my experience I can bet that ram is the most important
>factor. Of course, going from 32 meg to 64 meg makes much more difference
>than going from 1gig to 2gigs. (As a web server, an old Sun w/ plenty of
>ram does a good job.)
RAM is great for many reasons, in the case of a web server and one might
draw a parallel to afpd, is that by adding more RAM, several things
happen:
more data can be buffered for quicker retrieval
more instances of httpd or in this case, afpd can run without swapping
Eventually after adding enough RAM your entire web site or hard disk will
be buffered and swapping will never happen. But the speed of the box will
still be a constant.
>> + RAM (the more of it, the faster the server can do more at once)
>
> No. It's all about cache.
Sorry, I guess i didn't explain myself well, I hope the above makes more
sense.
<...snip...>
> This one was silly in my list. The only interesting point is that
>a good SCSI will not hog the CPU too much (it will handle most of the work
>by itself). The same applies for the network adapter.
Agreed. In fact, a good SCSI card and network card can make a
considerable difference in terms of performance vs. CPU utilization.
davez
----------------------------------------------------------------------
Dave Zarzycki Student
Intern San Jose State University
Apple Computer, Inc. dzarzyck@email.sjsu.edu
zarzycki@apple.com zarzycki@ricochet.net
----------------------------------------------------------------------
PGP Fingerprints (RSA): 8AF2 1040 8A9C D025 47BE 70DD A51C C887
DSS/Diffie-Hellman: CB9E 2621 B4BA 3F96 3516 B312 15B4 D842 3809 EF99
Contact pgpkeys.mit.edu for my public keys.
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:28:34 EST