On Wed, Jul 4, 2012 at 6:11 PM, Leonid Isaev <lisaev@xxxxxxxxxxxx> wrote: > On Wed, 04 Jul 2012 22:06:27 +0100 > Mauro Santos <registo.mailling@xxxxxxxxx> 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
