Comments about ntpviz
Gary E. Miller
gem at rellim.com
Tue Aug 23 17:28:26 UTC 2016
On Tue, 23 Aug 2016 01:53:35 -0700
Hal Murray <hmurray at megapathdsl.net> wrote:
> I have a script that uses rsync to collect the log files from various
Eric is working on something like that.
> Mostly, I plot 2 days, yesterday and as much of today as is available.
So two graphs, one for today and yesterday? ntpviz can do that.
> There are more kludgy scripts that split <name>-peer into <name>
ntpviz does 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
> pause -1
Yeah, I do see that is handy now and then.
> 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:
Looks like a holiday tree, I find it hard to ficus on the red/green pairs.
> Some of gnuplots colors are hard to see, at least on my setup with my
> eyes. Yellow is the worst case.
Yeah, if you have any specificc suggestions on how ntpviz can fix that.
But please no red/green barber polls...
> If a server is down for a while, the long straight line linking over
> that gap looks ugly to me.
Yeah, a down server is ugly. It should be shown ugly.
> 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.)
Yup, I'm working on autoscaling. A lot more to do. I'm thinking of
just clipping the outliers ( < 0.5%, > 99.5% ) with a text message of
the worst ones
> The round trip time is interesting, especially if you have a
> bufferbloated DLS link.
Yes. Dan Drown had those. They are in the work queue.
> 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 direction.
An interessting idea, but NTPsec needs to focus on core ntpd needs
until those are nailed down.
> 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.
Yeah, been looking at that. Since ntpd is undersampling the PPS it can
be either good, or real bad. I'm tempted to get Eric to fix the bug
first, but maybe I'll need to data so he sees the bug first.
> If you have a busy server, there is interesting stuff in usestats.
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
Size: 473 bytes
Desc: OpenPGP digital signature
More information about the devel