ntpq mrulist, #547

Hal Murray hmurray at megapathdsl.net
Mon Oct 7 22:52:01 UTC 2019

I'm getting ready to work on this.  It might help if some other eyes took a 
look at the code.

Here is what I think is supposed to happen.

ntpd keeps a list of hosts that have sent it traffic.  It's a doubly linked 
list, sorted by time of last packet arrived from that IP Address.  There is 
also a hash table so it can find a slot without a linear search.

During the early parts of the receive packet processing, the hash table is 
used to find the slot.  If the slot doesn't exist, a new one is allocated or 
an old one is recycled.  If the slot is found, it is removed from it's current 
position and inserted at the front of the list.  The counter is bumped and the 
time, mode, version, and remote port number are saved.

You can see the list with ntpq -c mru
You can see the allocation statistics with ntpq -c monstats
(They aren't very interesting unless you look at a busy server.)

Collecting the list is a bit tricky since the answer may not fit in a single 
packet.  The answers are sent oldest first.  If multiple packets are needed, a 
continuing request contains an array of where to start IP Address and 
time-stamp from the last successful reply.

One glitch is that slots that have already been sent may get updated while 
ntpq is collecting and moved to the head of the list where ntpq will see it 
again.  ntpq sorts the list and drops duplicates.

When processing a continuation request, ntpd uses the hash table to find the 
slot, then checks the time stamp.  If the time stamp matches, ntpq continues 
with the next slot on the list.  If it doesn't match, ntpd tries the next pair 
from the continuation request.

On a busy server, slots can get updated faster than ntpq can read them.  If 
that happens, ntpq will not be able to finish collecting samples.

ntpq has a "direct" mode that doesn't sort the answers, just writes things 
out.  That avoids the memory requirements to hold the whole answer (and 

There is an option to only send slots with more than N packets so you can look 
for the piggy users without collecting the whole thing.

There may be bugs in the above description as well as in the code.

There is another quirk in this area.  If a probe (and retries) times out, it 
bails with an error message without printing what it has collected.

These are my opinions.  I hate spam.

More information about the devel mailing list