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

From: Dave Zarzycki <[email-masked]>
Date: Wed, 31 Dec 97 07:45:58 -0800

On 12/31/97 5:12 AM, Nicolas MONNET ([email-masked]) wrote:

>On Tue, 30 Dec 1997, Dave Zarzycki wrote:
>
>> server config:
>> 
>> 200MHz PP200/512k L2
>> Intel Providence MB
>> 64MB EDO ECC memory
>> Seagate ST34371W (4GB UltraWide)
>> 3Com 3c509
>> (RNS?) 4 port 10/100 DEC tulip 21140
>
>	What OS???

Linux 2.0.32
RedHat Linux 5.0
The kernel is the available in their Hurricane updates directory.

>[snipped]
>> 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.

>> results: 134Mb/s
>
>	Do you have any other thing to compare to?

AppleShareIP 5.0.2 under the same circumstances (with less network cards 
of course) can/will saturate Fast Ethernet (100Mb/s) come January with 
new Apple servers. I wish I could say more, but I can't. (

>> questions unanswered:
>> how would a Pentium II do?
>> how would a Alpha do?
>> how would a Sparc do?
>> how would a PowerPC do?
>> would other drivers perform better?
>> How would a SMP system do?
>
>	As for any such benchmarks, the result depend of (in approximate
>decreasing order of importance):
>
>	+ Ram amount (for caching)
>	+ Disk
>	+ Scsi card
>	+ Network card
>	+ Processor/cache

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.)
 + 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.)
 + RAM (the more of it, the faster the server can do more at once)
 + Network card (servers spend most of their time pushing bits)
      Fast Ethernet == 100Mb/s or about 12MB/s
      Nearly all Ultra Wide SCSI drives today are 10-13MB/s
      If the data is in the cache/RAM, hard drive speed is irrelevant
 + Disk (but when the data is not in the cache, it must be fetched from
      the disk ;-)
 + SCSI card

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.

---

From: Nicolas MONNET <[email-masked]>
Date: Wed, 31 Dec 1997 18:47:25 +0100 (MET)

> 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.

> >decreasing order of importance):
[snip]
>       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.

>       in the system and not user space. I was processor bound when I got

	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 (the more of it, the faster the server can do more at once)

	No. It's all about cache.

>       If the data is in the cache/RAM, hard drive speed is irrelevant

	If it is.

>  + Disk (but when the data is not in the cache, it must be fetched from

	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.