[ntpwg] Further to the timestamping issue

Rob Seaman seaman at noao.edu
Thu Jun 19 00:14:18 UTC 2008


Hi Dave,

> Bob,
>
> I don't understand what you mean by "current behavior"; the currennt
> behavior is documented on the ntpd page in the online documentation.

I think there was some confusion here with my words and a quote from  
PHK.  My fundamental point is that UTC permits much more flexible leap  
second scheduling than has been demonstrated to date.  NTP might have  
to adapt to this in the future.

> Earlier this year I reworked the code to handle appointment errors as
> you describe. However, you might be using an older version. There was
> some discussion on this list at that time; you might find it in the
> archives.

I found a message as you describe from June of 2007.  We're running  
modern code - ignoring legacy hosts :-)

> Briefly put, a leap appointment is made from the NIST leapseconds file
> or imported from a server using an autokey extension field. When the
> clock is set, a counter is set as the seconds to the leap, if there is
> one. The NIST file expires and must be retrieved from time to time and
> appointments remade if necessary. In principle, you could make an
> appointment in July to take effect in December and then go offline  
> until
> then.

Ok.  With the multi-leap-second lookahead scenario I was discussing,  
this would have to be robust against several intervening intercalations.

> The WWV and WWVB leap warnings apply at the end of the current  
> month. If
> an appointment has not been made from either the NIST file or autokey
> and a majority of peer leap warning bits are set, a leap appointment  
> is
> made for the end of the month.  If less than 23 hours remain to the  
> leap,

> the system leap bits are set.  If the clock is stepped or the system
> restarted of less than a majority of peer leap warning bits are ser,  
> the
> appointment is cancelled.

Sounds as reasonable as any other heuristic.

>
> The only requirent is that the clock must be updated during the day
> before the leap in order to arm the kernel.

Ok..  So arming during the preceding day, and the possibility of  
maintaining several future leap second appointments are separate  
actions.  Arming in this sense is reasonable.  Arming six months in  
advance would not be.

Thanks for the clarification.

Rob



More information about the ntpwg mailing list