[LEAPSECS] Leap seconds ain't broken, but most implementations are broken

[Tony Finch]

Martin Burnicki <martin.burnicki at burnicki.net> wrote:
> Tony Finch wrote:
> >
> > Even though NTP can represent current UTC correctly, it often gets leap
> > seconds wrong. It does not give confidence that we will be able to
> > reduce bugs by teaching more code about leap seconds, when NTP cares
> > about time and gets it wrong, and most code cares much less.
>
> I think this you statement isn't quite fair.

Probably :-) But I think there are ways to make software more easy to
operate correctly.

For example, it used to be the case that you had to explicitly configure
DNS software with the addresses of the root name servers. Nowadays, the
root hints are compiled in and maintained as part of the usual software
update mechanism, so the operator has one less thing to worry about.

Maybe a similar scheme would work for leap second files, except that NTP
servers tend to need much less care and feeding than DNS servers.

> IMO this is similar to ntpd. If it's not provided with an updated leap
> second file then it may have no idea that a leap second is approaching.
> If a faulty GPS receiver passes a leap second warning to ntpd, should
> ntpd not trust the GPS receiver since it knows there are some broken
> receivers out there?

At this point you can insert another copy of my unfair complaint, but with
GPS instead of NTP :-)

> Current versions of ntpd accept a leap second file if it has been
> configured, and the file hasn't expired. If no leap second file can be
> used then a leap second announcement from a refclock is used.

I wonder if it would be better to set the leap indicator bits to NOSYNC if
the configured leap seconds file has expired.

> This tries to make operation as safe as possible, but this doesn't even
> help in any case. Imagine your NTP daemon has a valid leap second file,
> handles the leap second correctly, and also passes the leap second
> warning to its clients.
>
> If this daemon's time sources (GPS receiver, or upstream NTP server(s))
> don't insert the leap second at the same time then our daemon will
> observe a sudden 1 s offset after the leap second, and even though it
> has itself handled the leap second correctly, it will step the time a
> few minutes later to the wrong time provided by its reference time
> source(s).

Shouldn't it treat incorrect upstreams as false tickers? Can't it drop
them from its list of candidate servers when it realises they got the leap
second wrong or they will get it wrong?

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Dogger, Fisher, German Bight: North 6 to gale 8, veering east or northeast 5
or 6. Rough or very rough becoming moderate or rough. Showers. Mainly good.