On 2/9/2015 5:49 AM, Miroslav Lichvar wrote:
The -x option disables the kernel discipline, so the kernel is not told about pending leap seconds and its up to ntpd to do whatever is needed. Older ntpd versions (before 4.2.6) didn't handle leap second in the daemon loop and -x could be used to avoid the backward step in the Unix time scale and possibly upset the applications running on the system.
One wonders why NTP doesn't simply follow its own RFC 5905, which clearly states:
"A timescale is a frame of reference where time is expressed as the value of a monotonically increasing binary counter with an indefinite number of bits... In the date and timestamp formats, the prime epoch, or base date of era 0, is 0 h 1 January 1900 UTC, when all bits are zero. It should be noted that strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity, even if all knowledge of historic leap seconds has been lost. Dates are relative to the prime epoch; values greater than zero represent times after that date; values less than zero represent times before it. Note that the Era Offset field of the date format and the Seconds field of the timestamp format have the same interpretation."
A couple of points on the above. The statement regarding knowledge of historic leap seconds is nonsensical - there were none prior to 1972 to loose knowledge of, the length of the second varied to match the heavens. the NTP protocol requires no knowledge of leap seconds, other than a pending one for purposes of announcing it. The RFC makes no mention of NTP timestamps being discontinuous around leap seconds, in fact it states that timestamps are to be "monotonically increasing." It doesn't naively and incorrectly define a day as having exactly 86400 seconds, as POSIX does. (It does, however, give incorrect and self-contradictory timestamps for the dates 1Jan1972 and 31Dec1999).
Since RFC 5905 defines NTP timestamps in terms of monotonically increasing seconds since 1900, NTP (the implementation) should do exactly that. Instead, the implementation of NTP is incorrect in that it mimics POSIX by both assuming fixed length days and counting time discontinuously and non-monotonically in violation of the RFC.
Mills offers the following explanation (https://www.eecis.udel.edu/~mills/leap.html), which contradicts the RFC:
"The NTP and POSIX timescales are based on the UTC timescale, but not always coincident with it. The origin of the NTP timescale, the prime epoch, is 0h 1 January 1900, while the prime epoch of the POSIX timescale is 0h 1 January 1970. Both timescales reckon in standard (SI) seconds since the prime epoch... The insertion of leap seconds in UTC and subsequently into NTP..." A table is also included showing the non-monotonic discontinuity in NTP (implementation) timestamps.
Since the RFC says NTP is supposed to be counting seconds since 1900, there should be no "insertion of leap seconds in UTC and subsequently into NTP." NTP should simply keep right on ticking as stated in the RFC. The announcement of pending leap seconds is appropriate for a time dissemination service, but the conversion of NTP timestamps to UTC, accommodating leap seconds, is necessarily an OS function.
_______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
