mash@mips.UUCP (John Mashey) (11/21/87)
In article <15580@watmath.waterloo.edu> ccplumb@watmath.waterloo.edu (Colin Plumb) writes: >In article <925@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes: ... >And in the benchmark skill list: >>5) Wizard: not only does all of 4), but is competent at spotting ... >>Has good idea when somebody sets HZ wrong. Knows when disk benchmarks >(blush)... What's "HZ"? The closest I can come is Hertz, but that's >usually not settable by anything but a motherboard swap. :-) The following varies from UNIX to UNIX, and from system to system, but basically, UNIX times are usually reported in 1/HZ units, where HZ is the clock rate used for process timing. Benchmarks that perform their own internal timing will usually contain: #define HZ 60 and then convert clock ticks to seconds appropriately. However, the correct number might be: 100, 50, 40, 30, etc. If you run the benchmark without being careful, and, for example, HZ=30 would be right, the system will be reported as twice as fast as it really is. This is not a theoretical problem: I've run into it two or three times where a prospect reported either that we were slower than expected, or some other machine was faster than expected because of this. Remedies: #1: Before doing anything, make sure that the various incarnations of time (/bin/time, csh's time, etc) are correct by running cpu benchmarks that are long enough to be checked by your watch. (Don't laugh: when I was at CT, we once got harrassed by comparison with some 286 box that looked faster because time was compiled wrong). #2: Check the source of any benchmark that defines HZ, and make sure it is set right. #3: When writing a benchmark with internal timing, it is probably good to not only print a computed rate (Whetstones, Dhrystones, etc), but to print the total elapsed time, which can easily be eyeballed against the time(1) output. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
aglew@ccvaxa.UUCP (11/23/87)
..> 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.
rml@hpfcdc.UUCP (11/25/87)
> Remedies:
Another thing that can help is to have the source try to find HZ rather
than define it itself.
All systems conforming to ANSI C or POSIX will define CLK_TCK in
<limits.h>; unfortunately it's hard to check for POSIX conformance
safely because you need to include <unistd.h> to do so, and it may
not exist on non-POSIX systems.
#ifdef __STDC__
#include <limits.h>
#define HZ CLK_TCK
#else
#include <sys/param.h> /* defines HZ in Sys III and Sys V */
#ifndef HZ
#define HZ 60 /* best guess */
#endif
#endif
I suppose this can cause problems on non-ANSI, non-UN*X machines without
<sys/param.h>; more #ifdef'ing could then be appropriate.
Bob Lenk
{ihnp4, hplabs}!hpfcla!rml