Yo Udo! On Wed, 27 Mar 2019 17:39:10 +0100 Udo van den Heuvel via devel <devel@ntpsec.org> wrote:
> Why would ntpsec after a reboot move the pll to values at the edge of
> what I am graphing using mrtg?
I'd love to have someone take a hard look at ntpd startup behavior.
Lot's of odd things going on then.
> Before the reboot the pll values were closer to 0.
Before the reboot the PLL in ntpd and the PLL in the kernel are nicely
settled out and converged. After a reboot all state is lost (except the
drift in the drift file). Plus the RTC was probably not accurate, so
the system time is now off.
ntpd has to pull the system time to the correct value, causing the
ntpd and kernel PLLs to get pulled off center. When the system
time is about back to the right place, then the PLLs need to be
adjusted back to the right place.
Then add in that the jitter computation in ntpd sprays noise all
over. So it takes a while to get back to stable.
The problem is that the optimal process to do the initial convergence is
not the same as the process to hold the system steady. But ntpd only
has the one, hold steady, as its algorithm. Plus the -g thing.
This problem comes up all the time with oscillators run by time-nuts.
Their solution is simple: keep everything stable (temp, humidity,
voltage) and never reboot.
Maybe ntpd could save more state before a reboot.
Maybe ntpd could use a different algorithm on reboot.
Maybe ntpd could calculate jitter better.
Maybe ntpd could... ?
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@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
pgp_XTtSk9ldh.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
