ntpq: cruft/doc

[Hal Murray]

gem at rellim.com said:
>> If you were starting over, what would you do?  I think there are two
>> parts to that question.  One is the on-wire API.
> I think we are stuck with that part.  RFC's right? 

There is nothing that says we can't add new stuff.

I've been happy with the shift from mode 7 (binary) to mode 6 (text).


> Maybe with an optional csv output so it can be used in a tool chain. 
Can't most tools that take CSV also use white space for a separator?


> The first thing I would do is auto scale the output.  Hardly anyone
> remembers the output of 'ntpq -p' is all in milli seconds.  Even less often
> is millis seconds the best range.  I like how chronyc does the auto ranging.

One problem with auto scaling is that you have to print the units and that eats space on a line that is already tight.

I think it's nice if the columns line up.  The only time that I remember recently when the current stuff didn't work is that you can't see what's going on when the offset is less than a microsecond.


> Recently here someone was complaining that to look at 'rv' data in ntpq you
> had to first go find out the association ID of a peer (with associations),
> even though you already had the IP or refclock number. 

It shouldn't be hard to fix that.  Just make the rv stuff on the server check the argument and if it looks like an IP address do a scan to find the right slot.

There is some flag you can pass to the DNS lookup stuff that tells it to do numerical only.  I don't know if that takes things like "1234567".  If it does, we'll have to test for the whole argument being a valid number or add a flag to say the rest is an IP address.




-- 
These are my opinions.  I hate spam.