Re: PSA: Clock drift and pkgin

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

On Mon, 18 Dec 2023, Johnny Billquist wrote:

> >   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.
> 
> Yes. But (and) the thing is - the ICCS is *always* available. And is always
> used.
> But when we don't have the ICR, the value from reading out the clock becomes
> tricky. Because we are still using ICCS as the source of clock interrupts that
> drive the system wall clock. But then we don't have ICR as a source of
> information on how long time have passed since the last clock interrupt.

 Which is exactly why I keep writing we ought not be doing this (if we do) 
and should rely solely on the high-resolution timer for timekeeping.

> For the KA46 (and *only* the KA46), we are using some other mechanism, which I
> haven't really dug into, to get some higher precision time when reading out
> time. But let's ignore that platform for the moment. We have people with
> various machines, and simulations, which have the time problem. And most are
> not KA46. As far as I see, KA46 is merely the 4000/60.

 Conversely what I have been concerned with is incorrect operation with 
actual hardware, and then this specific one.

 As it has been mentioned in the discussion already getting timekeeping 
right in simulation is tricky.  It is best handled by referring to the 
host system clock where feasible, e.g. any hardware counters are best 
evaluated at access time only and calculated based on the host clock and 
the rate they are expected to change.

> >   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.
> 
> I should point out that even when we don't have the ICR register, we are
> running with a 10ms precision clock as far as interrupts are concerned. And
> that is where the system clock source comes from.

 No question as to using the ICCS for timer interrupts, but I maintain 
that where a separate high-resolution timer is available, it is the 
high-resolution timer that ought to be used for the system clock.  And I 
suspect it is already the case as AFAICT our clock handling subsystem is 
generic across ports (as it ought to be too).

 Yes, I realise timer interrupts have their use beyond just scheduling 
(e.g. handling interval timer triggers, poll(2) timeouts, etc.), but none 
of this stuff is supposed to rely on exact timing.

> >   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.
> 
> The DS1287 should never be a source of any precision time as far as I know. It
> has a resolution of 1s. It's usually used as the calendar chip, from which you
> set the wall clock on boot, but otherwise never usually bother with.
> 
> Yes, it can generate interrupts as well, with a fairly high frequency, but I
> can't see a way of reading out any high precision time from it.

 For some machines, such as the KN01/PMAX or KN02/3MAX, the DS1287 chip is 
the only timer interrupt source, and the resolution it can be programmed 
to is up to 8192Hz/122us, much better than bare ICCS without ICR, though 
with these slow machines 128Hz/7.812ms is typically used (for Alpha boxes 
1024Hz/977us seems more suitable, for more fine-grained task scheduling 
while still not wasting proportionally as much time in interrupt handling 
overhead).  I've spent a lot of time working with these devices.

 The use of the DS1287 chip specifically does not matter though: I merely 
used it as an example with a machine where the source of timer interrupts 
is different from any high-precision timer, which is analogous to the KA46 
and actually quite a common situation across computer architectures and we 
have to deal with it.

  Maciej