Csh confusion: #define HZ 100?

nomdenet%tp3 at rand-unix nomdenet%tp3 at rand-unix
Wed Dec 5 07:32:24 AEST 1984



>From  karl (Karl Kleinpaste):

> We have been doing some major  hacking on csh     . . .          it was
> discovered that that the symbol HZ, defined in sh.local.h, is #defined
> as 100. Now, obviously, HZ is the ac line frequency; why would it  ever
> be 100? (Has Berkeley got some really strange power requirements?)


From: Mike O'Brien <obrien at CSNET-SH>

>         To the best of my knowledge, 4.2 runs the "line clock" at 100 Hz
> instead of 60 Hz, probably so that the millisecond timer system calls
> actually have a prayer of coming up with an answer.  Probably also to
> provide finer granularity to the scheduler at the expense of higher
> overhead, but that's a guess so no flames, please!



   Just this last week I had occasion to burrow into 4.2's innards to check
how the UNIX clock is handled.  I learned HOW it's done, but nothing about
WHY.

   "HZ" is another anachronism, another name made misleading due to hardware
& software changes and kept for compatibility within kernel source files.
PDP-11s have only a clock that interrupts 50 or 60 times per second depending
on the power-line frequency, but VAXes have interval timers with microsecond
precision.  Up through at least 4.1, HZ did define the power-line frequency,
the VAX interval timer being made to count an appropriate value (either 16,667
or 20,000 microseconds) before interrupting.  In 4.2 BSD, HZ is now just the
number of clock "ticks", or interrupts from the interval timer, per second,
and is #defined as 100.  (I don't know when the change was made, whether in
4.1a, 4.1c, or 4.2).


   4.n Unix on VAXes uses the interval timer.  The value in the Interval Count
Register is incremented once per microsecond with at least 0.01% accuracy
(which is almost nine times worse than an ordinary digital watch!).  The ICR
is automatically loaded from the Next Interval Count Register upon a carry out
from bit 31 (overflow) which also interrupts at IPL 24 if the interrupt is
enabled.  The NICR may be reloaded at any time, and its value is retained
after reloading the ICR.  An Interval Clock Control/Status Register functions
in typical DEC manner, with error, interrupt, interrupt-enable, and run bits.
(All this is paraphrased from the 1982-83 VAX Hardware Handbook, and holds
for 730s, 750s, & 780s).


   So much for the hardware.  In kernel-source file conf/param.c is the defi-
nition of HZ and the allocation & initialization of "hz":

	#define HZ 100
	int     hz = HZ;

This file is included by config in every kernel directory as part of file
param.c (e.g., in GENERIC/param.c).
   At boot time the clock is started by a call to strtrtclock in vax/clock.c.
Here's the complete routine:

	startrtclock()
	{

		mtpr(NICR, -1000000/hz);
		mtpr(ICCS, ICCS_RUN+ICCS_IE+ICCS_TRANS+ICCS_INT+ICCS_ERR);
	}

This loads the NICR with -10000 (it's never reloaded), loads the ICR, begins
incrementing, and enables interrrupts.  In sys/kern_clock.c is the interrupt
routine, hardclock().  There's some "glue" between the hardware interrupt
and this routine in vax/locore.s, viz.:

	SCBVEC(hardclock):
		PUSHR
		mtpr $ICCS_RUN|ICCS_IE|ICCS_INT|ICCS_ERR,$ICCS
		pushl 4+6*4(sp); pushl 4+6*4(sp);
		calls $2,_hardclock                     # hardclock(pc,psl)
		.
		.
		.
		POPR;
		incl    _cnt+V_INTR             ## temp so not to break vmstat -= HZ
		rei

The mtpr instruction clears the interrupt.  Config includes vax/locore.s in
every kernel directory as part of file locore.c (e.g., in GENERIC/locore.c).



					       A. R. White
					       The Rand Corporation
					       1700 Main Street
					       Santa Monica, California
					       90406
					       (213) 393-0411, x7997

					       ARPA:  tp3!nomdenet @ Rand-UNIX
					       UUCP:  ... randvax!tp3!nomdenet



More information about the Comp.unix.wizards mailing list