[ntpwg] Further to the timestamping issue

[TSG]

----- Original Message ----- 
From: "Rob Seaman" <seaman at noao.edu>
To: "David L. Mills" <mills at udel.edu>
Cc: "NTP Working Group" <ntpwg at lists.ntp.org>
Sent: Wednesday, June 18, 2008 4:14 PM
Subject: Re: [ntpwg] Further to the timestamping issue


> 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.

Not if its used in proper auditing of IT operations. Leap Seconds are a 
nightmare for logging systems because they require special handling and 
integration across an entire entitie's operations.

>
>> 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
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg