Eric S. Raymond
esr at thyrsus.com
Sat Dec 17 12:29:18 UTC 2016
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
> 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>
More information about the devel