| |||||||||||||
Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2)Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2)Posted Jul 2, 2012 20:18 UTC (Mon) by chip (subscriber, #8258)In reply to: Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) by jhhaller Parent article: Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2)
Should ntp not use a gradual clock skew instead of simply slamming the time to its new value?
(Log in to post comments)
Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) Posted Jul 2, 2012 20:36 UTC (Mon) by Thue (subscriber, #14277) [Link]
In any sane standard, the clock (and NTP) should be using TAI ( http://en.wikipedia.org/wiki/International_Atomic_Time ). The same way as the computer's clock doesn't include time zones, it shouldn't include leap seconds.
Time zone and leap second offsets should be added in user space programs, the same way I assume time zones currently are.
Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) Posted Jul 2, 2012 20:45 UTC (Mon) by chip (subscriber, #8258) [Link]
I don't disagree, but that's beside the point IMO. Sometimes clock drift happens. When ntp is called on to fix that drift -- whether due to stupid standards or everyday imprecision -- shouldn't it use the system calls that are designed for adjusting the system clock's fundamental speed, instead of just saying "ok your time is different NOW!" ?
Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) Posted Jul 2, 2012 21:08 UTC (Mon) by Thue (subscriber, #14277) [Link]
Of course we would still need NTP if the system clock was set to TAI, and of course the same gradual clock adjust as now should be used. The use of NTP is ortogonal to the UTC vs TAI as system clock argument.
Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) Posted Jul 2, 2012 21:40 UTC (Mon) by chip (subscriber, #8258) [Link]
Er, "the same gradual clock adjust as now" isn't so gradual, is it? Else this bug wouldn't have hit?
Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) Posted Jul 2, 2012 22:05 UTC (Mon) by Thue (subscriber, #14277) [Link]
The current clock implementation is only non-gradual at leap seconds.
gradual clock adjust Posted Jul 2, 2012 23:11 UTC (Mon) by pflugstad (subscriber, #224) [Link]
FWIW, using NTP to gradually account for a leap second is what Google decided to do:
<http://googleblog.blogspot.com/2011/09/time-technology-an...>
Note that they don't explicitly say over what time window they adjust the time, but my impression from the above article is that it's done over a few hours, not over an entire day.
Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) Posted Jul 3, 2012 14:19 UTC (Tue) by Tobu (subscriber, #24111) [Link] NTP merely informs the kernel (using adjtimex) that a leap second is being inserted. The kernel implementation makes an internal timestamp jump, but that's because the kernel counts using POSIX timestamps, which is an implementation decision. If the kernel's internal timekeeping used TAI, the kernel would cross-reference the adjtimex notification with some sort of leap seconds table, which it would use whenever it needs to come up with a POSIX timestamp (for much of its ABI including protocols, filesystem formats, and system calls). NTP is agnostic about how the kernel clock is run.
|
|||||||||||||