Re: [gpsd-dev] Print offset in ntpshmmon?

[Gary E. Miller]

Yo Hal!

On Thu, 30 Apr 2015 10:21:16 -0700
Hal Murray <address@hidden> wrote:

> 
> address@hidden said:
> > Offset is normally close to zero. I think printing the offset in
> > ntpshmmon as a double and parsing it as a float in ntpshmviz would
> > be fine. 
> 
> I can't think of any case where offsets as floats would cause
> problems. doubles might be better.

I am working on a program that shows the problem.  Look at
test_timespec (in gpsd) and run it with the -v option.

Here is a good overview:

http://stackoverflow.com/questions/5098558/float-vs-double-precision

floats only have 7 decimal digit precision.  So if you are starting up, 
and have an initial offset of a few seconds then the microSec's of
the offset get munged.

This is important in clock testing where you are monitoring a PPS but
not steering on it.

> The problem is the timestamps.  To get an offset by subtracting two 
> timestamps, you need to do that subtraction before the conversion to
> floating point.

Yes, sort of.  A timestamp with nanosecs is a 62 bit number.  A float   
is only 24 bits and a double only 53.                                   

So if you convert two timespecs to doubles, and subtract you are not
quite to microSec precision.  Not good enough for PPS.

Worse, if you are on a 32 bit integer, and you subtract the seconds,
multiply by 1e9, the add in the nanoSec difference then you overflow if
the seconds are off by more than a few.

I am working on codeing an xample to show this for test_timespec.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588