Hal Murray <hmur...@megapathdsl.net>:
>
> > I didn't "add" a damn thing. I restored the pivot computation that was
> > there before it was mistakenly removed. You can compare the Classic version
> > to check this; there are some superficial differences due to the l_fp and
> > macro cleanups but the logic is the same.
>
> > Mills's solution was to map the timestamp to whichever of these aleph-0
> > possibilities is closest in time to a pivot. Then, if the time intended by
> > the sender was within a half-cycle of the pivot, all is good. That's what
> > this code is doing.
>
> OK, I think I'm catching on.
>
> That code you restored is crap. It takes an offset, converts it to a l_fp,
> gets the system time in l_fp, adds them together, then converts it back to a
> system time. Due to the small range of an l_fp, that convert back step needs
> a pivot time.
Hm. I need to stare at that code some more. I'm beginning to think the pivot
is the right idea implemented in a slightly wrong place. Maybe it ought to be
applied to in-packet timestamps as soon as they arrive?
> That pivot will catch starting up in 2039 on systems without RTC.
>
> Before your recent restore, step_systime did a pivot around "now". That
> works correctly once it gets started.
>
> I've said several times that we depend on the current time to be reasonable.
Where, specifically? Because if so, that is a serious bug that needs
to be fixed. Let's keep our eye on the ball, here. This is a
time-synchronization daemon - we have to deal cleanly with the case where
the system clock is garbage at startup.
> I see two ways to handle the no-RTC case.
>
> One is to run some other program before starting ntpd. It could use the
> build date or file system or whatever to set the system time to a reasonable
> value. My straw man for a file would be the leap seconds file. That's
> assuming it won't get updated when the system has a bogus time and/or the
> update process will preserve the time stamps. (We need to handle the
> no-leap-second file case too.)
>
> The other would be to but a sanity check early during startup of ntpd. If
> the system time is less than the build date, bump it up.
>
> Either way could also check for time unreasonably far into the future.
Simpler: The last-modification time of /etc. But that could foo up if
/etc is ever modified at boot time before ntpd can sync the clock.
Anyway, now I think we're moving in a constructive direction.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
