Re: [gpsd-dev] Mysteriously vanishing bugs don't make me happy

[Gary E. Miller]

Yo Eric!

On Mon, 4 Nov 2013 15:46:19 -0500
"Eric S. Raymond" <address@hidden> wrote:

> Gary E. Miller <address@hidden>:
> > FYI, after many days of running chronyd my clock stability is now
> > down to +/- 400 nSec.  Yes, nSec, not uSec, but it takes a while to
> > get there.
> 
> That reminds me.  I was doing a bit of cleanup on the PPS code -
> teaching it to use the new struct timedrift_to

I can find nothing on timedrift_t.  Not in current git, not in my
system headers.  Please let us avoid reinventing the wheel.

> and pushing nanosecond
> precision as close to the code for shipping time hints as possible -

And I have been doing the reverse. nSec are the future, stamp out uSec
where we can.  Push nsec everywhere, nt at the last instant.  Can we not
go off in two competing directions?

> and I ran across a couple of things that looked odd.

Yes, but can you please tread carefully so we do not lose another week?
It takes me longer to find your bugs than to do it myself.

> What seems off about this is that (I think) you've mentioned chronyd
> taking nanosecond-scale corrections before, yet the TSOTV steps
> precision down to microseconds. Is this correct?

Yes, it is correct.  The correction is in nSec, the time to be corrected
is in uSec.  It makes no sense, but that is their documented interface and
it works quite well.

> Yes, I realize this doesn't look quite like you might remember.  It
> used to take a struct timeval actual argument; I changed that, and
> added the stepdown, to (a) emulate the previous behavior exactly, but
> (b) consistently pass our around our internal time representations in
> timespecs, up-converting from timevals at the places where they're
> generated and down-converting to timevals only when that is explicitly
> needed.  That is less confusing.

Yes, and I already explained to you that was what I was going to do
before the recent unpleasantness.

> My point is, I wanted to check with you about whether that TSOTV
> really belongs there; if so, we're only shipping microsecond
> precision to chrony.  If not, perhaps it should be replaced by a
> structure assignment?

It is correct.  That interface is defined in the refclock_sock.c from
the chrony distro.  You can see that file here:

http://git.tuxfamily.org/chrony/chrony.git/?p=chrony/chrony.git;a=tree

> The other thing is this code in ntpshm.c:
> This is the opposite way around from the way offsets are computed
> elsewhere, e.g near ppsthread.c:438.  Is this actually right?

Yes, it is right.  The code for today is working.

> I'm thinking I might wrote a macro or inline function to replace your
> timediff_kpps() macro and this calculation and a couple of other
> places where it's done ad-hoc.

I'm confused why people want to replace single instances of code with
a macro.  If you can find more tha one place it is used fine, but just
replacing a single instance is pointless.

> Having N different implementations
> floating around with subtly different scaling is just begging for
> trouble. One - with scaling made explicit at each call point - would
> be better.

The problem is that we get time serveral different ways and we have to
give time in several different ways.  So things are done n-different
ways because there are n unique equations to solve.  You just can not
make things orthongal.  Worse yet we need the last decimal point of
accuracy even going to the point of rounding, so the order of operations
is very important in non-obvious ways.

Best to get the code stable and let me get on with the previously
discussed goal of moving everything to a timespec as soon as possible
and keeping iot there as long as possible.

So, if you insist on making life more difficult for me by doing this
yourself please do this small step by small step.  The first step is to
convert all the incoming times to nSec, then do all the math in nSec.

BUT, until you can actually test your changes I would ask you to be
extremely careful not to break it, then I can actually spend some time
on the code instead of bugs.

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

signature.asc
Description: PGP signature