Re: [PATCH 1/1] ntp: advertise correct TAI offset during leap second
From: John Stultz
Date: Mon Apr 30 2012 - 15:49:26 EST
On 04/27/2012 11:17 PM, Richard Cochran wrote:
On Fri, Apr 27, 2012 at 03:23:17PM -0700, John Stultz wrote:
On 04/26/2012 05:11 AM, Richard Cochran wrote:
When repeating a UTC time value during a leap second (when the UTC
time should be 23:59:60), the TAI timescale should not stop. The kernel
NTP code increments the TAI offset one second too late. This patch fixes
the issue by incrementing the offset during the leap second itself.
Signed-off-by: Richard Cochran<richardcochran@xxxxxxxxx>
This looks good to me. Although, have you actually tested against an
ntp client that sets the tai offset to make sure you're not
duplicating any ADJ_TAI adjustment it might make?
No, I cooked up my own test program that uses the adjtimex interface
directly. I really am not very familiar with the ntp.org software.
Wait a minute. If user space manages this variable, then shouldn't the
kernel leave it alone?
Right. That's why I'm asking. I actually haven't spent much time looking
at how the tai value provided via adjtimex is handled, and I want to
make sure its ok if we modify it from the kernel.
This David Mills paper [1] gives a leap second example that does it
the "other" way from Linux (see Figure 4), repeating the new epoch
rather than the leap second. It may well be that ntp.org servers do
behave that way. However, the NIST file claims that this way is
unusual.
So, you have a good question. But, if ntp.org uses the NIST second
method, shouldn't Linux do the same?
Not sure I'm following here. In Linux 23:59:60 is represented as
23:59:59 + TIME_OOP. Could you expand on what in particular is
inconsistent here?
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/