Csh confusion: #define HZ 100?
Guy Harris
guy at rlgvax.UUCP
Sat Dec 8 15:06:22 AEST 1984
> One of the reasons for having HZ defined in csh is the "time" command.
> It's build into csh, and it doesn't call /bin/time. Quantities of CPU time
> are available in ticks of cpu time, not seconds, and HZ is needed as a
> conversion factor.
Except that in 4.2, quantities of CPU time are available from the "old"
system calls ("times", etc.) in ticks of 60ths of a second (not in any
units based on the system clock - always 60ths of a second) and are available
from the "new" system calls in *very* nominal units of microseconds. As
such, under 4.2 no user-mode program need know the system clock frequency
in order to interpret values from system calls (which isn't a bad idea,
considering there's no way to get the clock frequency on "standard" UNIX
systems except by pulling in the system include file giving HZ; not too
good an idea if you want the same binaries to run in the US and in Europe
on a machine whose system clock runs off the line frequency...).
> There is no particular reason why the system clock has to run at the same
> speed as the power line frequency. Any reasonably stable clock of an
> appropriate frequency would do, and a HZ value of 100 makes a lot of math
> easier for the humans to deal with.
True, except humans don't have to deal with the math most of the time; that's
what computers are for. 100 seems to be an inappropriate frequency, as
you spend too much time servicing clock interrupts. (One could imagine
a UNIX system which didn't run the system clock at any set frequency, but
just set it to interrupt when the next "interesting" event happened, like
quantum expiration, a "callout" timeout coming due, etc..)
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy
More information about the Comp.unix.wizards
mailing list