[arch-general] Leap seconds ntp and chrony?

C Anthony Risinger anthony at xtfx.me
Thu Jul 5 05:10:14 EDT 2012


On Wed, Jul 4, 2012 at 6:11 PM, Leonid Isaev <lisaev at umail.iu.edu> wrote:
> On Wed, 04 Jul 2012 22:06:27 +0100
> Mauro Santos <registo.mailling at gmail.com> wrote:
>>
>> From data I have access to, taken from machines running ntpd, I can say
>> the following about the drift in PPM stored in ntpd's drift file:
>>
>> my laptop: -9.699
>> machine 1: -8.762
>> machine 2: -443.266
>> machine 3: -35.417
>>
>> Machine 1 is the newest and machine 3 is the oldest.
>
> AFAIK comparing RTCs on different machines is meaningless because there seem
> to be no quality handle for RTC. So, RTC may exist or not, but you can't
> choose (and therefore guarantee) to have a good RTC, at least on consumer (not
> server) motherboards. NTPD on the other hand implements a protocol $\equiv$
> standard.
>
> FWIW, my driftfile yields +6.982ppm which I guess is good compared to yours.
>
> Re machine 2 -- I bet your CMOS battery is dying.

per NTP FAQ, as basis for estimate:

http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm#AEN1220

"[...] I'll simply state that 12 PPM correspond to one second per day roughly."

... actual value is (1/86400)*1000000 = 11.574.

-9.375 = local server (never off/moved)
-22.538 = docked laptop (never off/moved)
-65.089 = remote server (linode.com [xen])

so my local clocks run a wee bit hot (and xen clocksource sucks?).
since kerberos clockskew defaults to 300 seconds, i would begin to
perm fail authentication (local -> remote server) after ...

p = ppm, s = sec, d = day

s / ( p / ( p / ( s / d ) ) )
s / ( p * ( ( s / d ) / p ) )
s / ( s / d )
s * ( d / s )
d

skew-sec-max / ( ABS(skew-ppm-var) / skew-ppm-per-sec-per-day )

300 / (( 65 - 9 ) / 12 )

... 62.32 days, or ~2 months [annoying] ... yay for NTP!

... (and also math! if it's correct!) clearly i went a bit overboard,
but it seems like the only thing you can depend on is RTC failing you
0-12 times-per-year, depending on your gear and sensitivity to time
variance.

although, it would be cool if authenticated NTP were more
widespread/ubiquitous -- a la Windows time service [signed packets] --
but since i've never cared much about it i'm probably just not aware
...

-- 

C Anthony


More information about the arch-general mailing list