Comments about ntpviz
hmurray at megapathdsl.net
Tue Aug 23 08:53:35 UTC 2016
I've been playing with graphs for a long time. Here is a dump of what I've
done and/or some comments about the current ntpviz. Maybe something will be
I have a script that uses rsync to collect the log files from various
Mostly, I plot 2 days, yesterday and as much of today as is available.
I have a script that sets up links from
<name>-loop to <name>/loopstats-<today> and
<name>-loop-1 to <name>/loopstats-<yesterday>
It has a cousin that sets the links up to target and day-before-target.
There are more kludgy scripts that split <name>-peer into <name>
Then I use gnuplot to scan through a batch of graphs. I have a top level
file full of things like:
reset; load "xxx.gp"
where all the xxx.gp are setup by hand. They don't change very often.
Occasionally I have to comment out one of the load/pause pairs because the
system generating the data is broken for all the time in the graph and that
A lot of the graphs I'm interested in need two scales, one that shows
everything and another that ignores the outliers and shows the main stuff.
For those, I add something like:
set yscale [xx:xx]; replot
I have a few graphs that are long running, months. For those, I typically
use different colors on odd/even days, and another pair of colors for
alternate months. Here are a couple of samples:
Some of the long running graphs need pre-processing. I usually cache as much
of that as is convenient.
Some of gnuplots colors are hard to see, at least on my setup with my eyes.
Yellow is the worst case.
Some graphs look better (to my eye) in points mode rather than lines. You
have to be careful to pick a dot that is big enough to see. Test to gnuplot
will show them along the right side. I use the solid ones.
If a server is down for a while, the long straight line linking over that gap
looks ugly to me.
Using microseconds for everything is hard to read for long delays typical of
network links. In bufferbloat cases, I see delays of several seconds. I've
seen delays of 10s of seconds. I can't count all those 0s quickly. I think
milliseconds would be better. (Looks like Gary tweaked things while I was
typing this in.)
The time labels on the X axis are hard to read on 2 day graphs. The hours
that I want are hidden between day and minutes. (I use 0-48, but I don't
have to worry about fractional day offsets.)
You can monitor other servers by using noselect. It sends packets and writes
rawstats and peerstats, then ignores the answer. They show up in ntpq -peers
with a blank in col 1.
The round trip time is interesting, especially if you have a bufferbloated
There is a lot of interesting info in rawstats. Some/much of it gets
filtered out on the way to peerstats. It probably tells you more about your
network than your local ntp server.
If you assume that both your local clock and the server's clock are accurate,
you can get the network transit delay in each direction. If you plot that
you can match steps in the round trip time with steps in a particular
There is interesting data in clockstats, at least for some drivers. One of
the important ones is the count for the PPS driver. It's real interesting if
your PPS pulse isn't wide enough to work all the time.
If you have a busy server, there is interesting stuff in usestats.
These are my opinions. I hate spam.
More information about the devel