Subject: clock interrupt frequencies
To: None <firstname.lastname@example.org>
From: Chris G Demetriou <Chris_G_Demetriou@LAGAVULIN.PDL.CS.CMU.EDU>
Date: 02/27/1995 03:23:03
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
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