✘adj_systeim()

[Eric S. Raymond]

Gary E. Miller <gem at rellim.com>:
> Yo All!
> 
> I have been tracking a loss of precision error and found something I
> dislike.  Eric thinks I must be mistaken, so I need a tie breaker.
> 
> First in ntpd/ntp_loopfitler.c:
> 
> adj_host_clock() is called once a second to correct the sysclock.
> 
> It calls adj_systime() with the offset to fix, as a double.
> 
> I see no other path to adjust the system clock, unless HAVE_KERNEL_PLL
> is defined and direct to kernel PPS is used.  Something I have never
> done, but is common on BSDs.

Your assumption is mistaken. HAVE_KERNEL_PLL is the *normal* path on
Linux systems (and most other modern Unixes as well).  As a comment
notes:

	 * This code segment works when clock adjustments are made using
	 * precision time kernel support and the ntp_adjtime() system
	 * call. This support is available in Solaris 2.6 and later,
	 * Digital Unix 4.0 and later, FreeBSD, Linux and specially
	 * modified kernels for HP-UX 9 and Ultrix 4. In the case of the
	 * DECstation 5000/240 and Alpha AXP, additional kernel
	 * modifications provide a true microsecond clock and nanosecond
	 * clock, respectively.

This path goes through ntp_adjtime_ns(), which supports nanosecond precision
if the platform-specific ntp_adjtime() call does; not all variants do.

> Moving to libntp/systime.c:
> 
> adj_systime() converts the offset to a timeval, which is in micro seconds.
> 
> Then adj_systeim() calls adjtime(3) indirectly.  adjtime(3) is also
> in micro seconds.
> 
> I added print statements so I know that is the path my systems are taking.
> 
> I can find no other possible path, other than the KERNEL_PLL which takes
> special configuration.
> 
> Did I miss something?  Taht would explain why people have a hard time
> gett much better than micro second stability.

Yes, if you can only adjust at microsecond precision that is all you're
going to get. Fortunately this is not the normal case. The code you've
been looking at is - in effect - a fallback path used only on systems
that don't implement ntp_adjtime().  One of the BSDs - I forget which -
is like this.

> Another bit of weirdness, adj_system() always calls adjtime(3) directly.
> But it only does so by indirection by way of ladjtime parameter.
>
> Since it always calls adjtime the indirection is pointless.

No, there's a reason for it, though I've half-forgotten the details.
I think it's got something to do with avoiding an ugly cohesion
between code that knows about struct timex and code that doesn't.  You
*will* find out the hard way if you try to refactor to take out the
"unnecessary" indirection.

> My next step is to try to figure out how to use STA_OFFSET mode in 
> nanoseconds with ntp_adjtime_ns().

Yeah, that's going to put you on a hiding to nowhere.  The whole
reason for the hairball you've just mis-analyzed is that ntp_adjtime()
is not available everywhere.  You might want to read devel/tour.txt; I
actually explained this crap there.  The specific section you want is
"System call interface and the PLL"

No offense, but it's kind of funny to watch you blundering around
making some of the same mistakes I did 18 months ago.  Especially
because you're not actually being stupid (or at least no more stupid
than I was); grokking this architecture and the heap of
poorly-documented APIs it rests on is *genuinely hard*.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170312/d1a83caf/attachment.bin>