At one point long past (well, actually on 2/10/95), Jonathan Stone said:
>I've increased the clock rate to get more accurate timing of packet
>traces.  A 5k/200 running NetBSD can get real work done at a ~ 2ms RTC
>tick interval.  It never finishes booting at ~1 ms RTC tick interval.
>Which leads me to conjecture that there's a real problem with
>interrupt latency.

Umm, what is "~" in those times, and what exactly did you do to handle
the interrupts?  I assume you switch the clock interrupt generation
time on the RTC to 512 and 1024 interrupts/sec, and therefore the
tilde means that they're 1000/512 ms, and 1000/1024 ms, respectively?

In particular, if you set ``hz'' to 1024, and ``tick'' to 976, and
just handled the clock interrupts normally, you'll have run into a
couple of problems:
	(1) hardclock() has no mechanism to deal with the situation
		where (hz * tick) != 1000000; your clock will drift
		by 576us/second if hz = 1024.
	(2) hzto() gets a div by zero if ``tick'' is less than 1000.
		do you know how well divide by zero exception handling
		works in the pmax kernel?  i.e. if this isn't causing
		a fault, you might get some "strange" result.

I just noticed these problems, bumping the alpha port up to its
"natural" clock rate of 1024Hz.  I'm going to put fixes into the
master source tree as soon as i get them stable in my private source
tree.  8-)


chris