Pivoting

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> gem at rellim.com said:
> > I'd have ntpd reject any time prior to EPOCH. 
> 
> How do you decide whether to reject it or pivot it into the future?

This is indeed a problem, and it's fundamental whenever you're trying to
work with devices that have time conters that can roll over within their
expected lifespan.  It's foolish to pretend that *any* workaround will
never have perverse consequences.

> >> Allow the user to specify the pivot time and/or life time, either
> >> at build time or at run time or both.
> > EPOCH is used for NMEA, so that is covered at build time.
> > I could see adding an option to specify the EPOCH at run time too.
> 
> My build time comment was mostly for life time.  I was assuming that EPOCH 
> would be used for pivoting.
> 
> I know about three pivots to consider.  One is GPS 10 bits for weeks with a 
> 20 year step size.  Another is 2 digit year numbers with a 100 year step 
> size.  The third is 32 bits of seconds in NTP packets with a 136 year step 
> size.  Are there any others I've overlooked?
> 
> If we want our software to last more than 20 years while talking to crappy 
> GPS receivers, we need a way to update the pivot date at run time.  (I'm 
> using "last" to mean without rebuilding.)
> 
> If we want our software to reject bogus time, we have to balance the tradeoff 
> between long life and good filtering.  Run time parameters will allow the 
> user to choose.

As I think more about this, I become more nervous about these
prospective "run-time parameters".  They seem like asking for trouble -
not easy to explain, easy to misconfigure.

> > As mentioend earlier, PDP-8s still run.  That is late 1960's.  Call it 50
> > years. 
> 
> It would be interesting to see what those setups are actually doing and if 
> they have documentation for something as obscure as NTP.
> 
> There is a lot of lab gear running embedded software.  I wonder how much of 
> it will be running at its 25th or 50th birthday.  I have a pre-software scope 
> that's over 35 years old.
> 
> 
> The combination of long life and crappy GPS seems obscure enough that I'm 
> willing to document it as a limitation.  It's the kind of code that Eric 
> would love to rip out if he found it a year ago.

You're right enough about *that*.  What kept my hands off it was
defensive conservatism - I've managed to not fuck us up while removing
almost 75% of the C code by being extremely careful about messing with
things I didn't understand.

As I remarked in my last mail, I'm coming around to the view that trying
to work around old crappy GPSes is a swamp that we're best out of.  There
are no right answers, just differently wrong ones - what you get to choose
is the distribution of your failure cases.

> The documentation issue gets interesting.  A feature isn't any good if you 
> can't figure out how to use it.  I wonder if the web will solve that problem. 
>  Will NTPsec still be online 20 years from now?  Will we maintain online 
> versions of 20 year old releases?

I think we have to plan for a longer than 20-year lifetime; after all the code
is about 20 years old now.

> Would anybody notice a warning message from a program that's been running for 
> 19 years?

That is imponderable. But I think we have to emit whatever messages
will give future admins the most useful information *assuming* they
pay attention.

-- 
		<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.