hmurray at megapathdsl.net
Sat Dec 17 11:39:33 UTC 2016
Thanks. That's a big help.
> 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.
> 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.
More information about the devel