Time to slow down and be more careful

[Gary E. Miller]

Yo Eric!

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

> Gary E. Miller <gem at rellim.com>:
> > 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.  
> 
> Right.  You have two things wrong.  Mills's correction is not a bug,

It is not a bug, but doing it there is a bug.  Follow along while
I do the math:

sys_steptime() to takes these inputs:

	sys_residual - double seconds, a time offset range +/- 1us

                       no l_fp or 1JAN1900 in sight.

        step - double seconds, range usually +/1 1ms, 1us or 1ns.
               never larger than 'gate', but for arguement assume
               it could be as large as 1Jan2200 - 1Jan1970

	       no l_fp or 1JAN1900 in sight.

        system clock - timespec(64) (except on some 32 bit binarites.)
               Range 1Jan1970 to well past 1Jan2200.  We can easilary add
               or subtract 100s of years to current timestamp with no problems,
               as long as we stay past 1Jan1970.

	       no l_fp or 1JAN1900 in sight.

All sys_steptime() does is add all three up to get the desired
system time to step to.  The time to step to must be a timespec(64) to
send to the syscall.  no l_fp or 1JAN1900 in sight.

So, where so you see any 1Jan1900 term or pivot in there?
	       no l_fp or 1JAN1900 in sight.

Please be specific, not invoking deities.

> He thinks the implementation is crap, and I begin to think he's 
> right about that

We all agree there.

> - in which case the correct thing to do is fix it.

We all agree there.

> 
> > Can we please get out of the bike shed loop  and just prove
> > something?  
> 
> We are not in a bike shed - the cycle correction is required for
> RFC5905 conformance and we will be *roasted* if we fuck it up.

Correct, we have to get it right, but this is the WRONG place.  See
above.

>  You
> continue to not understand the whole problem, or to think it can be
> dismissed for various reasons such as being too far in the future.

I have provided my analysis above, including times far in the future.

What step is wrong?

> Hal doesn't have it quite right either, but he's getting there.  Once
> he has understood that we have to minimize our exposure to a bad
> system clock at startup, and that Mills's pivot algorithm was a
> weirdly clever way to attempt that even if the implementation isn't
> yet quite right, he'll be fully up to speed.

Clever right, wrong place.  If you still disagree, show me which statement
in my math above is incorrect.

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/20170418/77699b08/attachment.bin>