Re: ✘drift file

[Mark Atwood]

If we make this change, framing it as "it's how chronyd has been doing it
for the past N years" makes it a much easier sell.

Especially if we can make the file format the same.

What principled objections would the hardcore time nerds have?   We do have
to keep their needs firmly in mind.

..m

On Mon, Aug 1, 2016 at 7:40 PM Gary E. Miller <gem at rellim.com> wrote:

> Yo All!
>
> Eric asked me to write up why I thought the chrony drift file handling
> is better than NTPsec's handling.
>
> 1.  On startup chronyd checks the time stamp on the drift file.
>     if the timestamp > sysclock, the sysclock is set to the timestamp
>
>     This is a nice sanity check on the system clock.
>
> 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).
>
>     Knowing the 'skew' at startup allows chrony to better reject bad
>     reclock input.
>
> I can see that saving the 'skew' is a nice touch, but I suspect much the
> good chronyd startup behavior is explained elsewhere.
>
> 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.
>
> 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/20160802/9acd0e2c/attachment.html>