lfpinit() signed or unsigned?

[Gary E. Miller]

Yo Hal!

On Fri, 10 Mar 2017 14:07:52 -0800
Hal Murray <hmurray at megapathdsl.net> wrote:

> gem at rellim.com said:
> >> There is nothing to normalize in a l_fp  All bit patterns are
> >> valid.  
> > Sort of.  The header notes imply the integral and fractional part
> > may be signed or unsigned.  Separately.  I have not confirmed if
> > the code use that.  
> 
> The whole point of l_fp is so you can do 64 bit arithmetic.  There is
> no sign bit in the fractional part.  It piggybacks on the sign of the
> high half.

Yes, but the overhead of timespec arithmetic is small, and pretty
soon I don';t think we will do any arithmetic in l_fp.

> > Actually, there may be a better way.  NTP defines an Epoch on the
> > wire. I do not know when it is sent.  We are currently in NTP Epoch
> > 0. In 2036 it goes to NTP Epoch 1.  If we can grab that field off
> > the wire we are good.   
> 
> It's not on the wire.  At least not in the main packet format.  I
> don't think it is in mode 6.  Yet.

I am also baffled.  The RFC defines NTP Date Format, but then never uses
it anywhere....

> >> I think the build date of the code will be a good start.  
> > Which breaks regression tests.  We tried that on gpsd and the
> > results were, to be kind, loud.   
> 
> Please say more.  I don't remember that scene.

When gpsd ws compiled to assume all dates before compile date, then all
the gpsd regressions, which are captures of earlier GPS output failed.

There is a way out.  POSIX zero (1 Jan 1970) is NTP 2,208,988,800.  So
any NTP before 2,208,988,800 is actually epoch 1, after 8 Feb 2036.

I don't think anyone possibly uses NTP timestamps for pre 1970.

> > Semms I believed someone that misread the RFC.  NTP Time is based on
> > 1Jan1990, but when using the Epoch it can uniquely define any time
> > backwards or forward.   
> 
> s/1990/1900/

Right.

> It's the same problem as the GPS 1024 week.

That does NOT make me feel better...  GPS Week rollover is always
a problem.

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/20170310/9e2188a9/attachment.bin>