[ntp:questions] Precision changed after upgrade from ntp 4.2.4p4 to 4.2.6p2

Caecilius nospam at spamless.invalid
Mon May 5 10:29:10 UTC 2014


On Mon, 5 May 2014 09:13:03 GMT, Miroslav Lichvar
<mlichvar at redhat.com> wrote:

>On Sun, May 04, 2014 at 08:29:26PM +0100, Caecilius wrote:
>> After upgrading ntp from 4.2.4p4 to 4.2.6p2 as part of a Linux upgrade
>> from Debian Lenny to Squueze, I've noticed that the precision variable
>> has changed from -20 to -22. So it appears that my clock has now got a
>> better precision. But the hardware is unchanged, and I'm running the
>> same kernel.
>The older ntpd is probably using gettimeofday() which has microsecond
>resolution (-20 in the log scale) and not the nanosecond
>clock_gettime().

Thanks.  That's exactly what's happening.

strace snippets show this for 4.2.6p2:

send(3, "<29>May  5 11:15:28 ntpd[9487]: "..., 86, MSG_NOSIGNAL) = 86
umask(0)                                = 022
umask(022)                              = 0
getuid32()                              = 0
clock_gettime(CLOCK_REALTIME, {1399284928, 331375894}) = 0
rt_sigaction(SIGHUP, {0x8058680, [], 0}, {SIG_DFL, [], 0}, 8) = 0

And this for 4.2.4p4:

send(3, "<29>May  5 11:06:46 ntpd[1724]: n"..., 86, MSG_NOSIGNAL) = 86
umask(0)                                = 022
umask(022)                              = 0
getuid32()                              = 0
gettimeofday({1399284406, 133635}, NULL) = 0
rt_sigaction(SIGHUP, {0x8053aa0, [], 0}, {SIG_DFL}, 8) = 0

It looks like this change means that ntp is better able to know the
precision of the underlying clock.  I find that 4.2.4p4 always reports
-20 on a Linux system, both when it's running on real hardware and
also when it's running in a virtual machine on a windows host.

But 4.2.6p2 will report -22 for linux on real hardware, and -15 on a
vm under windows.



More information about the questions mailing list