Apparent protocol-machine bug, new top priority

[Gary E. Miller]

Yo Fred!

On Mon, 25 Sep 2017 19:26:02 -0700 (PDT)
Fred Wright via devel <devel at ntpsec.org> wrote:

> On Mon, 25 Sep 2017, Gary E. Miller via devel wrote:
> > On Mon, 25 Sep 2017 16:55:30 -0700 (PDT)
> > Fred Wright via devel <devel at ntpsec.org> wrote:
> >  
> > > PPS(2) is the counter-capture PPS source, and is the primary
> > > timing reference.  
> >
> > Can you explain a bit more about this source?  How does this differ
> > from the KPPS or PPS(TIOCMIWAIT) sources?  
> 
> It's a different kind of KPPS, using the pps-gmtimer driver (with some
> experimental improvements of my own) rather than the usual pps-gpio
> driver.

Cool.  I hope you get it upstreamed.

> > Your SHM(1), on both your hosts, seem to not be very good.
> It's KPPS via the usual pps-gpio.  It's not a "modem-control" PPS at
> all.
> I don't do anything to reduce the variability since that's not the
> real timing reference, anyway, and it's not the main issue here.

But it does call into question your other measurements.  How can I trust
the hard measurements when the easy one look marginal.

> Some of that may be in the receiver itself.  The *cape* vendor only
> claims +/-200ns, even though the *chipset* vendor claims +/-60ns IIRC.

And you were seeing over 10 micro seconds Standard Deviation...

> > What do you think ntpviz should do better?  Just convert
> > 127.127.22.C to PPS(X) ?  That would be ann easy patch.  
> 
> Basically, yes,

I just pushed a patch for ntpviz.


> but note that ntpq has the same issue when pointed at
> classic ntpd.

Nothing I can do about Classic NTP.

>  The mapping table should really be in one of the common
> libraries so that ntpq and ntpviz can share it.

ntpq does no mapping.  It just uses the mapping that ntpd sent it over
mode 6.

> And it should have
> the complete list so that it can cover everything that classic ntpd
> supports.

I added PPS and NMEA, but I have no idea what abbreviations to use for
the others.

> > Well, your much poorer than normal SHM(1) Standard Deviation casts
> > doubt on your QED.  
> 
> Except that the SD is still way less than the mean.

Yes, but when something is not right, you have to discount the parts that
look correct.

It would be interesting to add a fudge to the SHM(1).

> Having a really tight grouping of shots five feet to the right of the
> target doesn't make you a good marksman. :-)

Really?  I was taught to get your grouping right first, then work
on moving the center of your cluster.

> > > > Uh, that is not my experience.  And I have more control over my
> > > > temperature than I have over my interrupt latency.  
> > >
> > > See above.  And note that you can at least make the latency (as
> > > well as the variation in latency) as small as possible by running
> > > the CPU as fast as possible, rather than slowing it down for
> > > "thermal stability".  
> >
> > I always run my ntpd's with the perfomance governor.  So not an
> > issue for me.  
> 
> Though apparently Achim runs his slower, hence the comment.

Now we are conflating two things.  Thermal effects and latency.  I
do not find them cross-correlated.

> > Prolly several reasons why my SHM(1) seems to have 40x less jitter
> > than yours.  
> 
> Perhaps, but I'll bet you're still more than 10 microseconds off
> without having any way to see it.

I'd like to see the results of that bet.  Get your driver upstreamed,
and working, I'd like to try it.

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/20170925/5938a7ba/attachment.bin>