ntpq meets log files

Hal Murray hmurray at megapathdsl.net
Mon Mar 8 22:28:33 UTC 2021

I'm poking around in ntp_control because I want to add the CPU time that ntpd 
has used for some tests I'm trying to run.

We have our share of crufty code, but this is the stuff that annoys me the 
most.  What should be simple turns into a pain in the ass.


We have several log files that record statistics hourly.  After they write out 
a line, they clear the counters.  ntpq can't ask for the totals since restart 
- the data is gone.

James has recently fixed part of that.  ntpq sysstats now prints 2 columns.

I'd like to open this area up for discussion.

I'd like the counters behind all log files to keep the totals too.  There are 
2 ways to implement that.  One is for the active counters to be the totals.  
The hourly logic would maintain a second copy that holds the value to be 
subtracted from the totals to get the this-hour values.  The other is for the 
active counters to hold the this-hour values.  To get the totals you would add 
the values from the second copy.  I think I prefer the active counters to hold 
the totals but I have not strong preferences.

We need to keep in mind how to make this work in a multi threaded environment.

It would be neat to have 2 more columns - packets per second.  I don't know if 
that will fit.

I'd like to have a ntpq command for each log file.  I like the 2 column 
approach.  Currently, the slots in each column have a separate name.  We could 
compress that by returning something like:
that is 2 values for one name.

ntpq could save a copy of the data so it could print the since-xxx values.

We could get last-day values by saving 24 copies of the last hour data.

There is at least one comment in ntpq.py saying, roughy, this table should be 
in ntpd so that we don't have to edit here too when something changes.  "rv 0" 
returns a subset of a big table marked "default".  We could easily add more 
flags, one for each log file.

There is a slight complication.  We need the name that comes back with a 
variable to be a meaningful description.


What's the best way to clean up this mess?  We discussed this before, but I 
don't remember any consensus, or anybody stepping up to do their favorite way.

The current approach needs 3 (I think) tables.  One to define a set of tags, 
one to translate the name of each variable to a tag, and the 3rd to print out 
the data for that tag.

I propose we dump the tags and put everything for each slot into struct.  What does it need?
  name that ntpq uses to ask for this slot
  pointer to value to be printed
  routine to print it

We can setup macros to build the struct.

Does that make sense?

These are my opinions.  I hate spam.

More information about the devel mailing list