Re: PSA: Clock drift and pkgin

["Maciej W. Rozycki" <macro%orcam.me.uk@localhost>]

On Fri, 15 Dec 2023, Johnny Billquist wrote:

> > > 983136 is pretty close to 1000000. However, without looking at the code,
> > > isn't
> > > that the diagnostics timecounter? Now used for anything really related to
> > > time
> > > keeping, but just for some other information, like sampling the state of
> > > the
> > > cpu and so on?
> > 
> >   It's just a free-running counter, as good as any.  The KA46 has no ICR.
> 
> Sortof. ICR and NICR are not required to exist. A machine is allowed to have a
> subset implementation of ICCS, only capable of generating an interrupt every
> 10 ms with no further control. Which is still the normal clock used as a
> source for time in the OS, if I'm not completely confused.

 As long as the ICR is used (or no high-resolution timer is available at 
all) using timer interrupt as the system clock source is the correct 
approach.  The thing is the ICR is synchronous to the timer interrupt, and 
moreover it is not a free-running counter as it's reinitialised every time 
an interrupt is produced.  So using the counter of interrupt ticks as the 
high-order bits of the timekeeping timer is the only way you can produce a 
monotonic counter.

 The drawback is that if you ever lose even a single timer interrupt, then 
you lose track of the wall clock too.

> So in the end, what we have is that for most machines, we're getting a higher
> resolution clock based on ICR. We basically have the clock tick, which gives
> something at 10 ms steps, and then we add in what ICR is at the moment. For
> CPUs that don't have an ICR, the clock will just be at the 10 ms resolution
> and that's it.
> With the exception of the VAX_BTYP_46, which uses another source, that is.

 And we do want to use such another source where no ICR is available as 
10ms resolution is pretty horrible for the purpose of timekeeping.  In 
that case the other source is not synchronous to the timer interrupt and 
therefore the OS ought not use the timer interrupt as the system clock 
source.  Instead it should use the approach I outlined previously, that is 
use the high-precision timer as the system clock source and only use the 
timer interrupt to keep track of timer overflows.

 Apart from providing correct time (which will not be the case in this 
scenario if you try to treat the counter of timer interrupts as the 
high-order bits of the timekeeping timer), the advantage of this approach 
is that as long as at least one timer interrupt has been handled between 
high-precision timer overflows no track loss of the wall clock will happen 
(of course we're not supposed to lose timer interrupts anyway, but the 
consequences of missing a preemptive context switch are certainly less 
severe in a non-RTOS than getting out of sync with time).

 The KA46 hardware configuration is analogous to the KN03/3MAX+ machine, 
where the source of the timer interrupt is the DS1287 RTC chip and the 
high-precision timer is located in the TURBOchannel bridge chip.  This is 
handled as "turbochannel_counter" in sys/arch/pmax/pmax/dec_3maxplus.c, 
and the KA46 variant ought to work essentially the same.  It is actually 
the 3MAX+ machine that David L. Mills used to implement his NTP framework.

 NB I disagree that 983136Hz is pretty close to 1000000Hz.  The frequency 
difference implies a ~1 second drift per 1 minute, which I find pretty 
horrible by any measure.

  Maciej