Subject: Proposed changes to cc_microset().
To: None <tech-kern@NetBSD.org>
From: Frederick Bruckman <fredb@immanent.net>
List: tech-kern
Date: 07/05/2004 11:00:49
Please let me draw your attention to the following:

  ftp://ftp.netbsd.org/pub/NetBSD/misc/fredb/cc_microset.diff

The main idea, is that, though there will be unpredictble and
unavoidable delays in executing cc_microtime() and cc_microset(), the
latency in cc_microset() needn't be a factor, if we only average out
over a longer interval. Additionally, even though the comments in
cc_micotime() promise to interpolate between ticks, it's really
interpolating between *seconds*, which, I believe, loses accuracy.

So, the point of the patch, is, to call cc_microset() more frequently,
to update the base time for cc_microtime(), while actually doing the
frequency calibration less frequently (1/10 second and 10 seconds,
respectively).

I chose 1/10 second for the shorter interval, because all the port's
"Hz" are divisible by 10.

The 10 seconds is arbitrary, but it seems adequate on at least one
i386 box to let the calculated frequency vary smoothly. This is
important, because we're using the results from one period to make the
cc_microtime() calculation in the next, and it makes no sense to do
that if the numbers vary randomly from one period to the next.

The burden of calling cc_microset() more frequently is offset, to some
extent, by the fact that it does less on all but 1 in 100 calls. Is
that acceptable? Note that the slowest ports don't even have a cycle
counter, and so will never call cc_microset().

A bonus is that we can monitor (and reject) large burps more easily.
The current code only rejects misses by 0.5 seconds or larger, but the
"ntpd" daemon typically steps time by as little as 0.128 seconds. A
put the tighter constraint in after seeing this in the log:

 cc_info: CPU 0: computed frequency = 9235698347/-1054033355 = -8.-762244 Mz

Although it was at boot-up and was corrected 2 seconds later, it can't
be be good.

The patch is for i386 only, but it's easy to see what needs to be
changed in ".../cpu.h" on the other ports.

Does anyone see a problem with the patch, or with the basic idea?

Another thing -- after building with CC_VERBOSE, "gdb" can't actually
set cc_verbose to "0" to turn it off. ("gdb" dumps core.) Can anyone
tell me what I'm doing wrong?

Frederick