Pivoting

[Gary E. Miller]

Yo Hal!

On Sun, 23 Apr 2017 03:20:48 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:

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

If you know unambiguously the time is past then you can reject.
Otherwise pivot.

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

Incomplete assumption, BUILD_EPOCH is also used to disambihuate century
for 2 digit years in NMEA and some other drivers.  As was __DATE__
previously.

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

Some GPS use 13 bit weeks.

For completeness, there is still the 2038 pivot for time32_t in use
by some 32 bit OS.

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

Fair enough.  I keep suggesting being able to override BUILD_EPOCH
in ntp.conf.  hen leave the problem to others how to get that set right.

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

Choose to shoot himself in the foot too.  But gotta take that risk.

> I have a pre-software scope that's over 35 years old.

Ditto here.  Just one?

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

Doc is a good start.

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

As I've previously said, I have friend running 20 year binaries of NTP
classic.

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

Prolly not...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170423/c676f4b7/attachment.bin>