Time to slow down and be more careful

Gary E. Miller gem at rellim.com
Tue Apr 18 05:51:05 UTC 2017


Yo Eric!

On Tue, 18 Apr 2017 00:52:51 -0400
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Hal Murray <hmurray at megapathdsl.net>:
> >   
> > >> I changed things so that there is never a conversion from l_fp
> > >> to full time. There is a subtract done on the l_fp side.  The
> > >> clock offset in l_fp is converted to an offset in seconds.  I
> > >> think it's a double.  That eventually turns into a clock
> > >> adjustment.  There is no explicit pivot.  There is an implicit
> > >> pivot of the current time.  
> >   
> > > I'm actually not sure which code you're talking about here, and I
> > > think it's important that I should.   
> > 
> > You added some pivot code to step_systime in libntp/systime.c
> > I don't understand why.  
> 
> 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.

OK, my mistake, you re-added the broken pivot code.

> > The argument is a time step as a double.  That comes from packets
> > exchanged with a server using l_fp.  That's at most 31 bits plus
> > sign, relative to the current system time.  That's the biggest step
> > you can take.  You can step across epoch boundaries.  You can't
> > step over whole epochs.  
> 
> Maximum step size isn't the problem.

Agreed, just one of them.

> The problem, which is invisible now but won't be in the future, is
> that any given l_fp can represent a countable infinity of timestamps
> separated from each other by the 136-year cycle lengths.  Which one it
> *actually* represents depends on the base epoch of the sending ntpd,
> which we don't know.

I guess you have not read my comments, and Hal's comments, to the bug where
we both show, in different ways, why the pivot is just a bug.

Please read that, ponder, and return here.

Or, if you prefer, make the changes I have suggested, also presented in
the bug, so I can write the tests that prove things one or the other.

Can we please get out of the bike shed loop  and just prove something?

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/20170417/772947be/attachment.bin>


More information about the devel mailing list