[ntp:questions] Re: ntp servers reporting leap second erroneously?

Martin Burnicki martin.burnicki at meinberg.de
Wed Oct 26 10:57:48 UTC 2005


Dave,

David L. Mills wrote:
> The NTP daemon has no idea how to handle leapseconds, only to notify the
> kernel that one is to occur. You should ask the kernel how it does that.

I'm sure it wouldn't be too hard to implement leap second handling for
kernels that don't support it natively. While digging through the current
code I saw that large parts of the required code are already there. 

On systems which support KERNEL_PLL the STA_INS or STA_DEL flag in the
status field of the timex structure is set in order to pass the
announcement to the kernel. That piece of code could also be used on
systems without KERNEL_PLL, but the flags had to be stored in a different
variable first since the timex structure would not be defined. E.g.:

  ... (existing kernel PLL support code)
#endif /* KERNEL_PLL */

  leap_flags = 0;   /* new variable usable also on systems w/o kernel PLL
  tstamp = peer->rec.l_ui - JAN_1970;
  tm = gmtime( &tstamp )
  if ( tm != NULL ) {
    /* instead of ntv.status, set leap_flags accordingly */
  }

#ifdef KERNEL_PLL
  ntv.status |= leap_flags;  /* add leap flags to timex structure */
  ... (existing kernel PLL support code)


On systems without kernel PLL support, the leap_flags variable could be
checked in adj_host_clock() which is called once per second and thus is
designated to handle it.

If adj_host_clock() first determined the leap second announcement it would
compute the current_time for the moment of leap second insertion, and if
current_time had reached that value id could apply an additional correction
when using adt_systime().

> As described in the white papers at the NTP project page, one approach
> is to stop the clock at the end of the previous day and start it up
> again one second later. Whatever method you use, you want to slow the
> clock progress down during the second, not speed it up.

Agreed.
 
> The method used in the kernels that have my code is to actually set the
> kernel time variable back one second, but force the clock value returned
> to the caller always to be monotonically increasing, even if at a slow
> rate. There is a diagram and detailed discussion in the white paper.

Without doubt this is the best method to handle an inserted leap second.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list