[ntp:hackers] Leap second list file
gdowd at symmetricom.com
Mon Jan 16 18:34:45 UTC 2012
I echo the vote to delay any changes in propagation of leap second info until after the next leap. There are a variety of systems which have different trigger points (IRIG 10 mins, PTP 12 hours?, GPS, etc.). Also, there is the issue of when the flag gets cleared. I have always had a little heartburn with the reference implementation in this regard. I studied Dave Mill's notes on timescale which, at least originally, showed that the leap second could be differentiated from the prior second by multiplexing the state of the li bits. In my system designs, I incorporated this notion. In the reference implementation, this is not always true.
From: hackers-bounces+gdowd=symmetricom.com at lists.ntp.org [mailto:hackers-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf Of Warner Losh
Sent: Monday, January 16, 2012 9:25 AM
To: Mike S
Cc: hackers at lists.ntp.org
Subject: Re: [ntp:hackers] Leap second list file
On Jan 16, 2012, at 5:03 AM, Mike S wrote:
> On 1/16/2012 3:02 AM, Dave Hart wrote:
>> On Mon, Jan 16, 2012 at 02:30, Danny Mayer<mayer at ntp.org> wrote:
>>> On 1/15/2012 3:17 PM, Warner Losh wrote:
>>>> Also, it is only 'leap second at the end of today' nor 'leap second at end of the month'
>>> No, that's not what it says. See below:
>>> LI Leap Indicator (leap): 2-bit integer warning of an impending leap
>>> second to be inserted or deleted in the last minute of the current
>>> month with values defined in Figure 9.
> Given those two factors, I wonder if ntpd should be
>> changed to indicate pending leap seconds earlier, perhaps after the
>> first hour of the month to guard against accidentally misfiring the
>> change a month early.
> Since the only mention of LI timing in RFC 5905 refers to "current month," I'd think the reference implementation should act accordingly. Waiting until the last day (or last second, for that matter) may be pedantically correct, but since the purpose of the LI flag is to provide advance warning, that warning should be given as far in advance as practical. Since leap seconds can only occur on month boundaries, starting to announce LI shortly after the start of a relevant month is appropriate.
The last time I was looking at the code, it was set to only do leap seconds in June and December. And then only on the last day.
Part of the problem with announcing it too early is due to bugs with other clocks. A hp clock steered to gps used to misfire if the GPS system announced the next leap second before Sept 30th, it would insert a leap second into the info it gave upstream on Sept 30th. I think the existing code was added out of an abundance of caution to ensure that buggy downstream ntpd do the right thing.
Don't know if there are any such buggy systems, but my conservative engineering sense suggests that any change like this be done in July of this year, just in case...
hackers mailing list
hackers at lists.ntp.org
More information about the hackers