Re: PSA: Clock drift and pkgin

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

On Thu, 21 Dec 2023, Jan-Benedict Glaw wrote:

> >  It's the normal procedure when `ntpd' cannot cope with the drift and the 
> > sync drops.  It then adjusts system tick duration and tries to resync from 
> > scratch.  Reachability will cycle through 1, 3, 7, 17, 37, 77, 177, to 377 
> > octal then.  This also means `ntpd' was still in sync two days ago, though 
> > my samples didn't actually catch it (at 1024 poll rate I'd have to wait 
> > long).
> 
> The "377" is an octal representation of a (shifted) bitlist showing
> the most recent 8 time requests for that peer. As you wrote, you
> synced (ntpdate?) that box about a week ago, so I would have expected
> (as the two oldest `peers` stats are waaay after that) that it, since
> then, always reached its peers. But the non-377 values tell that ntpd
> thinks it didn't reach that peer at those times.

 No, when `ntpd' resyncs it restarts from 0, dropping the earlier status.

> >  Well, 1024 is already the maximum AFAIK.
> 
> Eh, that was expressed misleadingly :(  I ment: It recognized trouble
> keeping time, why didn't it increase poll rate (ie. _reducing_ the
> poll _interval_ from its maximum of 1024 seconds)?

 I don't know.  I think it shouldn't have gone beyond 64 in the first 
place in these circumstances.

  Maciej