Yo Eric! On Thu, 9 Jun 2016 16:02:28 -0400 (EDT) e...@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
g...@rellim.com Tel:+1 541 382 8588
pgpSSzhT92kWw.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
