Re: [chrony-dev] Chrony and leap-second table expiration

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Mon, Dec 04, 2023 at 08:21:07AM -0800, Hal Murray wrote:
> 
> mlichvar@xxxxxxxxxx said:
> >> * If Chrony reads leap-seconds.list should it also look at the
> >> leap second expiration and reject old files?
> > As currently chrony works, there would be no functional difference between
> > rejecting old file and using old file unless someone was interested in
> > replaying old leap seconds. 
> 
> If you know that the data in the file covers "now", you can ignore the 
> leap-pending in NTP packets from servers.

The servers that incorrectly announce a leap second will likely apply
it to their clock and need some time to correct the error. Ignoring
that leap on the clients doesn't change much, they would still follow
the servers' error if they make a majority in the selection (same as
the leap majority). The client would need some logic to temporarily
ignore these servers completely.

IIRC a more common issue was with servers that announce the leap too
late, causing the clients to miss it, e.g. due to ntpd accepting leap
only from samples that pass the clock filter (~2.5 hour delay in worst
case with default maxpoll) and too many servers in the chain, or a
refclock getting the leap announcement only one hour ahead (e.g.
DCF77). Using the right timezone or leapfile helps with that.

For an event that might happen only once or twice again, I would
prefer to not complicate things any further.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.