Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site geowhiz.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!ut-sally!seismo!uwvax!geowhiz!larry
From: larry@geowhiz.UUCP (Larry McVoy)
Newsgroups: net.arch,net.unix-wizards
Subject: Re: IOCALL results and problems
Message-ID: <336@geowhiz.UUCP>
Date: Fri, 20-Dec-85 17:37:08 EST
Article-I.D.: geowhiz.336
Posted: Fri Dec 20 17:37:08 1985
Date-Received: Sun, 22-Dec-85 01:27:39 EST
References: <354@ncr-sd.UUCP> <457@rna.UUCP> <761@petrus.UUCP> <335@geowhiz.UUCP> <1035@homxb.UUCP>
Reply-To: larry@geowhiz.UUCP (Larry McVoy)
Organization: UW Madison, Geology Dept.
Lines: 44
Xref: watmath net.arch:2341 net.unix-wizards:16206

>I wrote:
>>I tend to agree with Dan.  I think what people would like to see is a 
>>benchmark which measures how well Unix, running multiple users, performs
>>on each machine.  The benchmark would have to measure something that did
>>not vary widely (such as I/O devices), as those results would only reflect
>
Rick Richardson writes:
>I don't think that running multiple dhrystones would measure anything more
>than the cost of doing a context switch once every <scheduling granularity>.
>Except on a multiple processor machine, the time will be N*1 dhrystone +
>M context switches.  There are easier ways to measure the time to do a context
>switch.  If you want to measure multi-user response, you've GOT to open the
>IO can-of-worms, since they WILL be doing IO.
>
>P.S. Rheinhold Weicker is the author of Dhrystone.  I apologize for
>creating the bastardized {C}Ada source from his original Ada!

Well, ok, so you don't think multiple dhrystones would be interesting.  Hmm...
I do - it would be interesting to know how well they do when there's lots of
them.  You say it's no more than testing context switches implying that
all context switches are equal.  Uh-uh.  For example:  I heard (from guy
harris who I'm sure will correct any inaccuracies) that Sun-3 memory management
is done such that 8 memory mapping context blocks are in memory at all times.
This leads to fast-fast-fast response for active jobs <= 8, but what happens
when you go to 16? 32?

I think we both agree that testing I/O is a mess.  Really hard to get an 
objective and accurate reflection of a machines performance.  I think we
also both agree that what people would like to see is some sort of 
measurement of a machines multi-{user,tasking} capability.  So, I made a 
pass -- what have you to offer instead?

-larry

BTW - sorry about the {C}Ada crack, just my peevishness at not being able
      to decipher it...
-- 
Larry McVoy
-----------
Arpa:  mcvoy@rsch.wisc.edu                              
Uucp:  {seismo, ihnp4}!uwvax!geowhiz!geophiz!larry      

"If you are undertaking anything substantial, C is the only reasonable 
 choice of programming language"   -  Brian W. Kerninghan