Subject: Re: [netatalk-admins] netatalk+asun benchmark (afp/tcp)

From: Dave Zarzycki <[email-masked]>
Date: Wed, 31 Dec 97 10:33:29 -0800

On 12/31/97 9:47 AM, Nicolas MONNET ([email-masked]) 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.                         [email-masked]
[email-masked]                           [email-masked]
----------------------------------------------------------------------
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.