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.