driftMime-Version: 1.0

[Gary E. Miller]

Yo Hal!

On Wed, 03 Aug 2016 03:13:47 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:

> gem at rellim.com 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.


> gem at rellim.com 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
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160803/f7a323c6/attachment.bin>