Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: comp.arch
Subject: Re: myths & magazines [really: HZ]
Message-ID: <28200072@ccvaxa>
Date: Mon, 23-Nov-87 09:59:00 EST
Article-I.D.: ccvaxa.28200072
Posted: Mon Nov 23 09:59:00 1987
Date-Received: Sun, 29-Nov-87 18:01:10 EST
References: <953@winchester.UUCP>
Lines: 25
Nf-ID: #R:winchester.UUCP:953:ccvaxa:28200072:000:1224
Nf-From: ccvaxa.UUCP!aglew    Nov 23 08:59:00 1987


..> Mis-setting HZ when running a benchmark

This is an example of a more general problem: how do you *know* the 
configuration your benchmark was run on? Especially if you've made
an automated benchmark tool that can be run by people who do not know
how to read the boards off the backplane?

I have a tool that dumps as much of the configuration info as is possible
to determine by software, but some things are simply not made available
by hardware, or to a user process - eg. memory interleaving factors,
which can make a sizable difference.

I think that providing a standard way for the user process to obtain such
configuration info should be part of the basic system design (and, yes, I think
that all DIP switches and jumper blocks on your boards should be readable by 
software, if not controlled by software - put a scan path through them all).


Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
aglew@mycroft.gould.com    ihnp4!uiucdcs!ccvaxa!aglew    aglew@gswd-vms.arpa
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.