[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gpsd-dev
Subject:    Re: [gpsd-dev] Print offset in ntpshmmon?
From:       "Gary E. Miller" <gem () rellim ! com>
Date:       2015-04-30 18:08:31
Message-ID: 20150430110831.4e5fa59c () rellim ! com
[Download RAW message or body]

Yo Miroslav!

On Thu, 30 Apr 2015 17:27:40 +0200
Miroslav Lichvar <mlichvar@redhat.com> wrote:

> On Tue, Apr 28, 2015 at 11:59:06AM -0700, Gary E. Miller wrote:
> > > > > > -                    offset = (float(record[3]) -
> > > > > > float(record[4]))
> > > > > > +                    offset = float(record[4])
> > > > > 
> > > > > Both are pretty bad....
> > > > 
> > > > You're the expert.  Please fix it.
> 
> > I have expected for some time that we would need to move to some
> > sort of arbitrary precision math, like decimal.Decimal or gmp. 
> 
> You can also keep the timestamps in nanoseconds, using long integers.

How long is a python long?  32 bit longs are not big enough.  64 bit
longs will not be big enough in 2038.  Google '2038  NTP'.

ntpd already calculates to better than nanoSec, so any change should
be equal or better.

> But would be pystripchart able to display the data without losing
> precision?

Sure, the offset is the residue of the preccision.

> 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.

Nope.  The calcuation is being done in double and the nanoSec are lost.

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

[prev in list] [next in list] [prev in thread] [next in thread]