On Wed, 2017-01-04 at 13:40 +0100, Martin Burnicki wrote: > > In the ntpd source code I see a number of places like this: > > #ifdef STA_NANO > clock_offset = ntv.offset / 1e9; > #else /* STA_NANO */ > clock_offset = ntv.offset / 1e6; > #endif /* STA_NANO */ > > So this is interpreted here as nanoseconds or microseconds depending > on > whether STA_NANO is defined *at compile time*. > > IMO this is not an optimal solution. I've seen cases under Linux > where > the timex.h file shipped with the kernel source > (/usr/src/linux/include/linux/timex.h) and used to compile the kernel > defined STA_NANO, while an older copy of timex.h shipped with glibc > (/usr/include/linux/timex.h) did *not* include it. Since the latter > is > used by default when compiling a user space application like ntpd > this > resulted in an ntpd binary which assumed the adjtimex() returns > microseconds, while in fact the kernel deals with nanoseconds. > > So a better solution would be if the the kernel sets the STA_NANO bit > if > it provides nanoseconds, and applications check at runtime if the bit > is > set in the status returned by adjtimex(). >
I did some experimenting with this on Fedora 25, Linux kernel 4.8.15-
300.fc25.x86_64. I found that adjtimex sets STA_NANO and returns
nanoseconds only when NTP has been running for a while.
John Sauter (john_sau...@systemeyescomputerstore.com)
--
PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E
signature.asc
Description: This is a digitally signed message part
_______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
