[ntp:hackers] smearing the leap second
hmurray at megapathdsl.net
Sun Jul 12 03:58:39 UTC 2015
imp at bsdimp.com said:
>> Getting TAI using the tai_offset via adjtimex() isn't trivial, at least if
>> you expect your code to do the right thing when running over a leap second.
>> You have to do something like:
>> read tai_offset
>> read time in UTC
>> read tai_offset again
>> If the tai_offsets differ, you were reading the clock close to the leap
>> second. Try again.
> Actually, that's not entirely correct. There's a lock that ensures that
> things from ntpd are adjusted atomically in FreeBSD. So the TAI time scale
> can be implemented with the adjustment since the adjustment doesn't change
> until the leap leaps and sets UTC back a second. So long as that operation
> is atomic wrt updating tai_offset (which I believe the locks there today
I was assuming that clock_gettime(CLOCK_TAI) would do the right thing.
The case I was trying to cover was when there wasn't a single call to get
TAI. With two separate calls to get UTC and tai_offset, the simple approach
gets the wrong answer if the leap happens in between the two calls. Yes,
that's a very small window.
> But there's been little call for a CLOCK_TAI in FreeBSD. And ntpd
> doesn't (or at least old versions didn't) set tai_offset, so it would be
> a lie most of the time anyway.
ntpd sets up tai_offset if it has a leap file. (It may also work via
autokey, but I don't know if anybody uses that.) That code has been around
I agree that it's not a simple out-of-the-box solution, at least for any
distros I'm familiar with, but it can be made to work with a small amount of
care. The current release includes an update-leap script. You would need to
set that up as a cron job and add a leap-file to your ntp.conf
These are my opinions. I hate spam.
More information about the hackers