Wonky NTP startup and the incremental-configuration problem

[Gary E. Miller]

Yo Eric!

On Thu,  9 Jun 2016 16:02:28 -0400 (EDT)
esr at thyrsus.com (Eric S. Raymond) wrote:

> There are two major questions here:
> 
> 1. Why is convergence from a standing start so slow?

Two issues, I'll be vague as I don't know better:

	a. restarting perturbs the system, sometimes badly.
           Not bad enough to have security implications, but
           milliSconds instead of microSeconds.

	b. The PLL converges slowly.

> 2. If there is a fundamental reason for the slowness, shouldn't it
>    be possible to dump some kind of state that would allow ntpd
>    to reread it and resume from a running start? The key question
>    is whether we can identify that state.

Looking at a. and b. from above:

        a. the '-g' startup algorithm is acting perversely.  Ntpd just
           grabs the first time it gets and jams the system clock to that
           time.

        b. chronyd just saves the drift, and the drift error.  I'd be happy
           if NTPsec was comparable to chronyd.

> Not having anaylzed the code, but having stared at a lot of ntpd 
> restarts lately

Here is how I have been doing it:
	# killall ntpd
	# ntpd -N -g; watch ntpq -p

Then put your NMEA refclock at the top of the ntp.conf and watch the
'fun'.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160609/a1346b7f/attachment.bin>