ntpviz - Don't plot a line during data absence

[Gary E. Miller]

Yo Achim!

On Sun, 23 Oct 2016 21:07:57 +0200
Achim Gratz <Stromeko at nexgo.de> wrote:

> Gary E. Miller writes:
> > We already discussed this.  The load on a RasPi distorts the timing
> > so badly that it shows up on the ntpizv plots.  The Heisenberg
> > Uncertainty Principle in action: Mmasuring distorts the thing being
> > measured.  
> 
> The load itself actually doesn't distort the timing.  It warms up the
> processor and RAM and finally the XO, however, and _that_ changes the
> timing.

Ah, sorry.  I disgree with your analysys.  Check out the temp graph on the
page to see that temps are unrelated.  On other hosts I've measured up
to 6 temps (cpu, disk, room, cpu, north brodge, etc.) and found zero
correlation.

The problem is that a loaded CPU takes longer to repond to an
interrupt.

>  Also, the Heisenberg uncertainty principle is about the
> attainable precision of measurement of complementary pairs of
> variables, not about the disturbance of the system being measured by
> the act of measurement.

You have a common misunderstanding.  I guess your college professor will
have to call up and complain to mine.  I'll let my A in that class speak
for itself.  But I'll not go off shearing that Yak with you.

> For the rasPi 2B that I have here, I've logged the PPS arrival times
> together with the CPU temperature for two weeks now.

Two weeks, I have temps going back seveal months now.

> After I've
> closed the box it's in, which made things much more stable and about
> 4K warmer overall, the loop values can be predicted by a kernel
> density filtered CPU temp measurement quite nicely and I end up with
> almost exactly linear 200ppb/K response over the 4K temperature range
> of the last week.

I also see the effect you speak of.  That is on my graphs, but only
loosely related to the spikes.  They correlate, but are lagged.  That
is, the CPU load is cause to both the temp and frequency.  The load come
first, then the freq spike, then a smaller temp spike.  The temp is the
dependent variable on load spikes, not the independent variable.

Feel free to post your graphs here, after you are runnning ntpviz in a
crontab too.  But since you are not running ntpviz on your ntpd host we
are not even talking about the same experiment.

> > Look at the spikes in the red line on the first graph here:
> >
> >     https://pi4.rellim.com/day/
> >
> > Each one of those is ntpviz running.  When ntpvis runs faster
> > (finishes in less time) the spikes get smaller.  The spikes used to
> > me much, much, bigger.  
> 
> Sorry, but you're doing that wrong.  Pull the data from the machine
> with rsync (using -rsh=ssh) and process it offline.

Wrong?  Just different.  Pretty hard to build a standalone NTP server
when you need two servers.  I'm runnning so many test ntpd servers that
is not a practical solution.

Plus, it providea a nice standard load.  It keeps visibility on the
real problem: that ntpd is too load sensitive.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20161023/4bfe56e0/attachment.bin>