Yo Eric! On Sat, 22 Oct 2016 09:21:59 -0400 "Eric S. Raymond" <e...@thyrsus.com> wrote:
> Hal Murray <hmur...@megapathdsl.net>:
> > >> I assume that using a pipe or socket rather than SHM would fix
> > >> that.
> >
> > > Probably, but then we run unto buffering jitter again.
> >
> > Are we on the same wavelength yet? Have we agreed that latency is
> > not critical? If so, why is jitter important?
>
> It is possible that I am confused.
Now we agree. :-)
> What ntpd gets from a clock source is a series of pairs asserting
> "at system time X I believe it was UTC time Y".
Yes.
> Are you telling me there is no value in minimizing the time from X to
> when the sample triggers a correction, and the variation in that time?
Yes. ntpd sits on the data, by default, for 32 seconds average, and 64
seconds max. The big ntpd loop only goes around every second. A few
micro seconds is not releavnt. Long term tests on GPSD-JSON confirm this.
> Basic servocontrol theory tells me that control lag is the enemy of
> precision and tends to produce whiplash effects. Does that not apply
> here?
With all the averaging, filtering and polling, the transit time from
delta generation to ntpd input is way less then 3 orders of magnitude
less than the ntpd control loop cycle (one second). Then when
ntpd averages the deltas over 64 seconds all immmediacy is lost.
But don't believe me, or my long term GPSD-experiments, set up your own.
Not hard.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
pgp1PmhgBrp9Z.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
