[ntp:questions] Leap Second testing
hart at ntp.org
Wed May 9 15:43:06 UTC 2012
On Wed, May 9, 2012 at 3:12 PM, Phil Fisher <Phil.Fisher at ipaccess.com> wrote:
> Once this was done, then ntptime indicates that it has been set even if the current status shows it is not. In my opinion this is at best fallacious if not a bug. If the Leap indicator is cleared then I would not expect it to be remembered somewhere else why bother clearing it and providing the facilities to clear it.
It's not clear to me why the discrepancy can exist on Linux or if it
can be seen in any other implementations of the precision kernel
extensions for NTP.
> Therefore my testing scenario will have to ensure that LI has not been set at any point. I assume from your comments both in response to this post and earlier ones that LI can only be propagated by an upstream NTP server (assuming here that the client is not a stratum 1 server of course) to the downstream client on the day that a Leap Second should be implemented (and by day I understand this to be the UTC day which could be a whole can of worms in itself when people think of local time and when this can occur).
There is no ambiguity about when a leap insert can happen. It happens
between the last day of a UTC quarter and the first day of the
following quarter. In practice, it's always been between the last day
of a half-year and the following half-year, but the specs allow for
April 1 and October 1 as well. Local time plays no part in scheduling
the insertion. ntpd enforces the end-of-quarter requirement. Your
testing shows Linux ntp_adjtime is willing to schedule and execute a
leap insertion any day of the year.
> If this is correct, then using ntptime -r once can check that a LI has not already been seen (since that will show a return status of 1 (INS) while the status will show as 17 (0x0011) (PLL,INS) typically. If we try to cancel it then the results will show return status of 1 (INS) but the status as 1 (PLL). It will be important for me to detect this (even if the consensus of NTP gurus is it would not occur and is not a problem) since I might need to take action that stops the possibility of the Linux kernel bug occurring.
> I think it might well be important in real world scenarios where an incorrect deployment may have triggered an incorrect LI to downstream clients. There should be a way to clear this (and ntptime -s clearly allows this) but not completely hence leading to an incorrect adding of a leap second and possibly in older Linux kernels a system crash when logging the leap second event.
If you were testing on a server while it was used by production
clients, you could well induce them to schedule a leap insertion, and
based on your results, even if that decision were reversed before
midnight UTC, I bet the insertion would proceed (as their kernels
would not deschedule the insertion when status bit 0x10 is cleared by
ntpd). It would be interesting to hear if the latest Linux kernels
have a similarly sticky notion of a pending leap insertion.
More information about the questions