ntpq, pool

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> Thanks.  That's a big help.

You're very welcome - I wanted it to be. If it helps get maintaining
ntpq off my plate I will feel amply rewarded.

I have to start load-shedding more; it's not good for either the
project's sustainability or mine to keep carrying the whole codebase
on my back.

> [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.

I have no doubt whatsoever that you are correct about this.  I had forgotten
the details of how old records are identified.  It's on the Mode 6 page.

> > 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.

Yes, that's right.

Note that one thing that has changed since I wrote that long description.
I'll do a followup post on this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>