| |||||||||||||
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:45 UTC (Mon) by chip (subscriber, #8258)In reply to: Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2) by Thue Parent article: Re: [PATCH 0/2][RFC] Potential fix for leapsecond caused futex issue (v2)
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!" ?
(Log in to post comments)
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.
|
|||||||||||||