Yo Hal! On Wed, 03 Aug 2016 03:13:47 -0700 Hal Murray <[email protected]> wrote:
> [email protected] said: > > 1. On startup chronyd checks the time stamp on the drift file. > > if the timestamp > sysclock, the sysclock is set to the > > timestamp > We have more important things to do. A few lines of code, faster to code than to argue about it. Better yet, steal tthe chronyd code for it. > The OS should be doing that sort of thing, probably using the root > directory. Why stop with the drift file? Should we check the log > files too? We can't trust the OS to do the rightt thing about time. The OS trusts ntpd to do tthe right thing, but it does not. > It's the sort of code that is hard to test and likely to have subtle > problems. Really? Just 'touch /var/log/ntppstats/driftfile' to a time in the future, start nttpd, and then check the system time. > I think it's a good item to put on the what-do-customers-want list. I assure you Rasi uuers really want this. The lack of an RTC causes real problems. Every time I reboot a RasPi I curse ntpd's poor startup behavior. Almost enough to go back to chronyd. > > 2. ntpd stores the frequency ppm offset in the driftfile. > > chronyd stores the frequency ppm offset and the 'skew' > > (estimated accuracy of the existing frequency value). > > > I can see that saving the 'skew' is a nice touch, but I suspect > > much the good chronyd startup behavior is explained elsewhere. > > I'm not sure that ntpd has a parameter equivalent to skew. I think this is what ntpd calls 'RMS Jitter'. I'm not clear on the ntpd internals, but I do know it has methods for clock selection, and they fail badly on startup. ntpd does not need to exactly mirror what chronyd does. But it clearly needs better start up behavior, and since chronyd starts up muuch better than ntpd that is a good place to start looking. > Again, I vote that we don't do anything now. The current startup > stuff is broken. There is no point in working on things like this > until we understand and fix the current problems. Clearly chronyd understands the problem, so looking at that code is ppart of the path to unuderstanding and fixing the problem. > [email protected] said: > > In a related topic, it would be nice (maybe an option) for ntpd to > > hold off logging the initial aweful data until after the -g option > > has set the system clock. And a bit longer, so the wonky startup > > data is masked. > > But that is when you really really want the logging. Sometimes, but then it takes a week for my graphs to be readable again... > I might agree to put it someplace other than the normal place. Works for me, or maybe a switch. Or maybe fix the startup problems. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 [email protected] Tel:+1 541 382 8588
pgpYVgQOhWGDO.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
