Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ucbvax!sdcsvax!darrell
From: darrell@sdcsvax.UUCP
Newsgroups: mod.os
Subject: Re: Performance analysis of computer systems
Message-ID: <2695@sdcsvax.UCSD.EDU>
Date: Tue, 10-Feb-87 04:18:55 EST
Article-I.D.: sdcsvax.2695
Posted: Tue Feb 10 04:18:55 1987
Date-Received: Wed, 11-Feb-87 18:48:26 EST
Lines: 33
Approved: mod-os@sdcsvax.uucp

John Mashey writes:

> To illustrate the importance and value of really good simulations, one
> can observe the unfortunate problem of announcing performance, and then
> having to backtrack horribly when the product comes out...

I am reminded of the story in Fred Brooks's book, in which he mentions what
happened when the performance simulator for OS/360 started running.  It
showed a Model 75 with drums compiling Fortran at ten cards per minute, or
something like that.  This was investigated immediately, of course.  Turned
out that many of the OS group had never used disks before, and even the
innermost parts of OS were doing disk overlays with wild abandon.  It *did*
help the coders meet their core limits...  Needless to say, this could have
been an utter disaster if the simulation hadn't caught it early.

I also dimly recall an incident on one of the 370s, the model 135 I think,
in which consistent speed discrepancies between hardware and simulation
uncovered a hardware bug well after the system had been thoroughly tested
and released for production.  I forget the IBM buzzwords, but it was a case
where there were N copies of a resource for the sake of parallelism, but
the hardware in fact was only ever using one.  Nothing functionally wrong,
so the orthodox diagnostics never caught it.

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry



-- 
Darrell Long
Department of Computer Science & Engineers, UC San Diego, La Jolla CA 92109
ARPA: Darrell@Beowulf.UCSD.EDU  UUCP: darrell@sdcsvax.uucp
Operating Systems submissions to: mod-os@sdcsvax.uucp