ntpmon should be more usable now

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > I don't know how to read the damned output.  I have barely
> > any idea what those columns mean.  I can't tell descending
> > from ascending from middle-outwards! 
> 
> It's what you want if you are trying to figure out who is using your server.

*blink*

Thank you. Just that one sentence was amazingly helpful, actually.  A lot
of previously disconnected facts fell into place when I read it.

/me adds that sentence to the mrulist 

> A couple of examples from a handy server.
> 
> lstint avgint rstr r m v  count rport remote address
> ===================================================
> 489277  20422  180 . 3 4     74   123 dhcp-103
> 492043  13366  180 . 3 4    125   123 dhcp-102
> 1210927     33  180 . 4 4  31564   123 tim
> 
> The count column is the total packets.  I think it includes both replies from 
> servers as well as requests from servers in case you have too systems looking 
> at each other.  I don't think it includes ntpq queries.

I think I need to widen that lstint column...done.

Aha.  While working on that I figured out the reason for the spurious
negative lstint values.  They're supposed to be made by subtracting
the last transmission time passed up from now.  In ntpq I initialize a
new PeerSummary instance for each other mrulist; int ntpmon I initialize one
such object and re-use it.  You guessed it, stale timestamp.

> The first/lstint column is the time since the last packet.  The second/avgint 
> column is the average time between requests.
> 
> The rstr column is the restriction bits that apply to that IP Address.  The m 
> and v columns are the mode and version from the last packet.  The above shows 
> 2 clients and 1 server.
> 
> The rport is the remote/source port from the last packet.  The remote address 
> should be obvious.

I more or less knew these things from studying the code for the Mode 6
protocol, actually. What I was missing was any clue about what they

> The mru section will take forever on any busy server.  I think the default 
> memory limit matches the old 600 slot default.
> 
> It will probably screwup a nice clean API, but if you want to display the 
> most recent slots, you can do something like:
>   read the whole collection.  They come back sorted by lstint - most recent 
> last.
>   remember the IP Addresses of several slots just below the ones you print.
>   Next time, rather than read the whole thing, start with the IP Addresses 
> you saved.
>   display the new data and update the saved IP Addresses...

Simpler (I think): add a parameter to the reqest method saying "Just give me 
enough records to get the last N most recent entries".

> If you want to play, you can add keyboard commands to fiddle the sort order.  
> Oldest first should be easy.  Just read as many as fit.  Sorting by other 
> columns will be hard.
> 
> I'd like a q for quit.

So write it, already.  The Python curses API is well-documented, and
dead-simple if you've ever used the C version. And at 142 LOC ntpmon
isn't a high mountain to climb.

(Happens I wrote a lot of the Python ncurses code, and a lot of the
ncurses C library beneath it too.)

I'd like to hack on this, but my priorities now have to be (a) ripping out
the interface-scanning hair, and (b) simplifying and fixing some
broken stuff in the waf recipe.  I can take some time out for ntpmon
because it's so trivial to modify, but I need to focus.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>