[Pool] Off by a second leap second failures

Miroslav Lichvar mlichvar at redhat.com
Thu Jul 16 09:39:22 UTC 2015


On Wed, Jul 15, 2015 at 10:37:10PM -0400, Philip Gladstone wrote:
> Is there an official recommendation on what to do with the leap second bits?
> In particular for implementations that are not based on the standard NTP
> code.

The NTPv4 RFC includes a minimal example code, which simply takes the
leap value from the selected system peer without any sanity checking.
I'd not recommend doing that.

For the safest approach in an NTP client I'd suggest:
- if tracking multiple sources, take leap of 1 (insert) or 2 (delete)
  only when more than half of the sources agree on that value
- if the local clock says it's not June 30 or December 31 (in UTC),
  treat leap of 1 or 2 as 0 (no leap)
- if leap of 1 or 2 is accepted, ignore any measurements made when the
  local clock is closer than few seconds (e.g. five) to the leap
  second, both before and after the leap

For an NTP server:
- report leap of 3 (unsynchronized) to the clients when the local
  clock is in or very close (e.g. half a second) to the ambiguous
  second on the NTP time scale (23:59:60 UTC), the local clock needs
  to be corrected in that interval
- set leap to 0 shortly after the leap second, don't wait for new
  replies from upstream sources

This is how it's implemented in chrony.

-- 
Miroslav Lichvar


More information about the pool mailing list