Wonky NTP startup and the incremental-configuration problem

[Mark Atwood]

It looks like there is no obviously good route forward.

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?

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.

..m



On Thu, Jun 9, 2016 at 1:27 PM Gary E. Miller <gem at rellim.com> wrote:

> 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
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160609/6e074150/attachment.html>