Yo Fred! On Mon, 25 Sep 2017 19:26:02 -0700 (PDT) Fred Wright via devel <[email protected]> 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 <[email protected]> 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 [email protected] Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin
pgp6L8w2nHYGD.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
