Yo Hal!
On Sat, 17 Dec 2016 15:17:05 -0800
Hal Murray wrote:
> g...@rellim.com said:
> >> I assume that's a typo. The counter has to be in ntpq
> >> rather than ntpd. ntpd doesn't store any state for clients.
> > My experiments with the lastest ntpmon contradict your statement.
> > ntpd does
g...@rellim.com said:
>> I assume that's a typo. The counter has to be in ntpq
>> rather than ntpd. ntpd doesn't store any state for clients.
> My experiments with the lastest ntpmon contradict your statement.
> ntpd does seem to be keeping the number of requests in the mrulist between
> ntpmon r
Yo Hal!
> > 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 st
Hal Murray :
> 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
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 a
Hal Murray :
> The traffic on the pool took a big jump recently. There were a couple of
> comments on the pool list, but nothing past "lots of traffic".
>
> Understanding what's going on is the top of my list.
If it matters, I agree with that allocation of your time.
NTPsec won't be hurt if it
The traffic on the pool took a big jump recently. There were a couple of
comments on the pool list, but nothing past "lots of traffic".
Understanding what's going on is the top of my list.
A couple of interesting counters were lost in the recent (month or 2 ago)
work on the packet processing.
