Yo Eric! On Tue, 18 Apr 2017 00:52:51 -0400 "Eric S. Raymond" <e...@thyrsus.com> wrote:
> Hal Murray <hmur...@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
g...@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
pgp5i_U0T_n0H.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
