Time to slow down and be more careful

[Eric S. Raymond]

Hal Murray <hmurray at 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.