✘adj_systeim()

[Gary E. Miller]

Yo Eric!

On Sun, 12 Mar 2017 08:22:04 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> 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).  

I have no system that takes that path.  Are you sure your system is taking
that path?  I added trace statements.  I have HAVE_KERNEL_PLL set but
that path is never taken.

> As a comment notes:

Let's not accept old comments as fact.

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

Yes, but that is the path not taken for me.  That path depends on ntp.conf
settings that are rarely in use.

And take a look, ADJ_OFFSET is never used by any usage of ntp_adjtime_ns()
in the code.  Yet that is the ONLY option to ntp_adjtime() that will 
cause it to ask the kernel to slew by an offset.

> > 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.

Well, it is my case.  Can you confirm that is not the case for you, by
looking at running code?

> > 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.

Having that indirection is unrelated to the timeval/timex issue.  By
the time ladjtime is called the nano seconds are already lost.

My guess is that before adjtime() was widely available that there
were other similar syscalls that could be swapped in instead.

> > 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"

Well, ntp_adjtime() is just an alias for adjtimex() which is in POSIX
1999.  And we limit ourselves to that, right?


> 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*.

I already knew you disagreed, what I am still lacking is proof
of your assertions.  My original thoughts mirrored yours, but I
have proven on my systems that the path you describe is NOT taken
in my cases

I basically put this at the top of adj_systime():

        printf("adj_systime: hello! %.9f\n", now);

Can you run that simple test for me?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170312/04177241/attachment.bin>