Comments about ntpviz

[Hal Murray]

The part I forgot to mention is that if I was going to do something to make 
my setup better, I would try to make a wrapper to drive gnuplot - a little 
window off to the side so I could poke Next rather than typing return at the 
gnuplot command window.  The main thing I want is a way to backup a few 
graphs.  The second step would be a simple way to adjust vertical and/or 
horizontal scaling (aka zoom in/out) to cover the cases where I didn't 
anticipate I would want one and/or didn't get it right.

---------

> So two graphs, one for today and yesterday?  ntpviz can do that.

No, one graph, 48 hours wide, yesterday on the left and today on the right.  
The part of today that hasn't happened yet (or hasn't been copied over to the 
local system) is empty.

Remember, I'm using pre-edited gnuplot commands.  There is no place in my 
work flow to tell gnuplot how wide the graph should be.

I often set the graph to be 8 extra hours wide so the key has a place to go 
without trashing part of the graph I might be interested in.


[Need two different scales.]
>>   set yscale [xx:xx]; replot
>>   pause -1
> Yeah, I do see that is handy now and then. 

It happens enough for me that I did something about it.


> Looks like a holiday tree, I find it hard to ficus on the red/green pairs.

The usual nasty case is boundaries between between red/blue areas.  Your eye 
has lots of chromatic aberration.  It can't focus on different colors at the 
same time.  Red and blue are the farthest apart.


[using crappy colors]
> Yeah, if you have any specificc suggestions on how ntpviz can fix that. But
> please no red/green barber polls... 

The only fix I know about is to manually pick the set of colors you are 
willing to use and then tell gnuplot which color to use for each chunk of 
data.  If you let it assign things automatically, it will rotate through all 
of them and that includes the crappy ones.  Yellow is 5 so you get 4 decent 
ones without any effort.  Somewhere around 4 different data sets many graphs 
get too busy so this is only a problem occasionally.  I have one plot where 
lots of lines work well.  It's the temperature for various machines and 
places in the room.  They don't overlap much all track well so you can see 
any interesting differences.

> Yeah, a down server is ugly.  It should be shown ugly.

I have some systems that are normally off to save power.  For me, the gap is 
enough to attract my attention.

I had one setup where the script to start ntpd appended 2 blank lines to all 
the stats files.  gnuplot treats that as a request to not draw the line 
connecting the points on either side.


> 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 

I want to be able to see the outliers.  At least optionally default on.

I think you will have troubles trying to automate that.  It will get mixed up 
with scaling.


>> If you have a busy server, there is interesting stuff in usestats.
> Such as?

The reason I added it was to get the memory usage.

sysstats has packet counts.  I think usestats has wakeup counts so you should 
be able to figure out how many packets arrived while you were already working 
on something.

There is lots of room for improvement in this area.  I thin it's all on the 
geeky end.


[rawstats/round trip time]
> An interessting idea, but NTPsec needs to focus on core ntpd needs until
> those are nailed down.

The round trip time is important if you are trying to understand what 
happened to a server out on the big bad internet.  It's probably less 
interesting for debugging your local LAN.  It might be helpful if you are 
using WiFi.

A reasonably common quirk is that the offset of a server will jump, say 10 
ms.  If the round trip time jumps at the same time, the problem is most 
likely a routing shift rather than a glitch at the remote server.


> 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. 

Response in a new thread.



-- 
These are my opinions.  I hate spam.