[ntp:hackers] smearing the leap second

Hal Murray 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
> ensures), 

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 
for ages.

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 mailing list