[LEAPSECS] JD & MJD, UT1 & UTC

[John Sauter]

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_Sauter at systemeyescomputerstore.com)

-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20170104/91acbf46/attachment.pgp>