<div dir="ltr">It looks like there is no obviously good route forward.<div><br></div><div>My first inclination is to change ntpsec to do what chrony does re saving the drift stats, and once we see that NTPsec can restart converge roughly as well as chrony, we rip out the runtime conf code.  Maybe even use the same filesystem file format as chrony for that data?</div><div><br></div><div>My own experience with the MySQL internals, the F5 3DNS internals, and the Digeo Moxi internals, is that runtime configuration to a running process adds huge amounts of complexity and hair to the code.    I suspect that that is also the case in NTP.    A usually better approach is to make process restart fast and safe, or if the process MUST be long running, make the subsystems isolated and restartable.</div><div><br></div><div>..m</div><div><br></div><div> </div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 9, 2016 at 1:27 PM Gary E. Miller <<a href="mailto:gem@rellim.com">gem@rellim.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yo Eric!<br>
<br>
On Thu,  9 Jun 2016 16:02:28 -0400 (EDT)<br>
<a href="mailto:esr@thyrsus.com" target="_blank">esr@thyrsus.com</a> (Eric S. Raymond) wrote:<br>
<br>
> There are two major questions here:<br>
><br>
> 1. Why is convergence from a standing start so slow?<br>
<br>
Two issues, I'll be vague as I don't know better:<br>
<br>
        a. restarting perturbs the system, sometimes badly.<br>
           Not bad enough to have security implications, but<br>
           milliSconds instead of microSeconds.<br>
<br>
        b. The PLL converges slowly.<br>
<br>
> 2. If there is a fundamental reason for the slowness, shouldn't it<br>
>    be possible to dump some kind of state that would allow ntpd<br>
>    to reread it and resume from a running start? The key question<br>
>    is whether we can identify that state.<br>
<br>
Looking at a. and b. from above:<br>
<br>
        a. the '-g' startup algorithm is acting perversely.  Ntpd just<br>
           grabs the first time it gets and jams the system clock to that<br>
           time.<br>
<br>
        b. chronyd just saves the drift, and the drift error.  I'd be happy<br>
           if NTPsec was comparable to chronyd.<br>
<br>
> Not having anaylzed the code, but having stared at a lot of ntpd<br>
> restarts lately<br>
<br>
Here is how I have been doing it:<br>
        # killall ntpd<br>
        # ntpd -N -g; watch ntpq -p<br>
<br>
Then put your NMEA refclock at the top of the ntp.conf and watch the<br>
'fun'.<br>
<br>
RGDS<br>
GARY<br>
---------------------------------------------------------------------------<br>
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703<br>
        <a href="mailto:gem@rellim.com" target="_blank">gem@rellim.com</a>  Tel:+1 541 382 8588<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a><br>
<a href="http://lists.ntpsec.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ntpsec.org/mailman/listinfo/devel</a></blockquote></div>