ntpq, pool

[Hal Murray]

Thanks.  That's a big help.


[mru retransmissions]
> Each span request except the first is supposed to include identifications of
> late MRU entries from the previous span.  If the daemon can't match those
> from the MRU records it's holding in core, that means some of the records
> that existed at the time of the last request have been thrown out of core to
> make room for newer ones without exceeding the configured limit on MRU
> memory usage. 

I expect it's slightly more complicated than that.  The "match" has to 
include both the IP Address and the last-time.

If the slot doesn't exist, it has been recycled and so have all the older 
slots.

If the slot exists but the last-time doesn't match, the slot has new data and 
has been bumped from where you want to restart up to the top so you want to 
restart from the next oldest slot.  The slot will eventually get returned 
again so the receiver has to process duplicates.

There are two cases for duplicates: updates and start-overs.  The updates 
will have the same first-time.  The start-overs represent the case where the 
slot got recycled for use by another IP Address and then a new slot was 
created for the target Address.



> ntpd tracks the number of times it has to do this restart.  If that number
> exceeds 8, it figures that it's never going to get everything to you before
> stuff ages out, ...

I assume that's a typo.  The counter has to be in ntpq rather than ntpd.  
ntpd doesn't store any state for clients.



-- 
These are my opinions.  I hate spam.