ntpq, pool

[Hal Murray]

The traffic on the pool took a big jump recently.  There were a couple of 
comments on the pool list, but nothing past "lots of traffic".

Understanding what's going on is the top of my list.

A couple of interesting counters were lost in the recent (month or 2 ago) 
work on the packet processing.

I think the mru list doesn't count mode 6 packets.  Fixing that is probably 
important in being able to monitor DDoS activity or probes.



How much of the old structure of ntpq did you preserve?

Can you say anything about how the python version of ntpq works that isn't 
obvious from looking at the code?  I'm looking for the big picture?  The 
stuff that's obvious after you know it but hard to put together if you don't 
know what you are looking for because it is spread over many screens.

How does the MRU stuff work?  I think I saw some debugging printout 
indicating that it got back a clump of packets for each request.  If it 
misses one, will it use the data up to the gap?

Is there any documentation on the packet format?  I saw some ".." in an ASCII 
packet dump.  That was a CR/LF in the hex part.  It looked like each slot was 
multiple lines.  What marks the end of a slot and/or start of a new one?

How does the retransmission logic work?

I want to add a bunch of counters.  Where should they go?

What should I have asked?

-----------

I got this from an old ntpq looking at a busy server.

  Ctrl-C will stop MRU retrieval and display partial results.
  116 (0 updates) Giving up after 8 restarts from the beginning.
  With high-traffic NTP servers, this can occur if the
  MRU list is limited to less than about 16 seconds' of
  entries.  See the 'mru' ntp.conf directive to adjust.

I think that's trying to tell me that things are getting updated faster than 
they are getting retrieved.  What will your new code do in that case?


-- 
These are my opinions.  I hate spam.