[ntp:hackers] NTPv4 Brian Version
David L. Mills
mills at udel.edu
Fri Aug 12 02:06:42 UTC 2005
Harlan,
The sys_maxclock parameter specifies the maximum number of preemptable
associations that can be mobilized by either the manycast or pool
discovery schemes. It can be set with the tos command, but defaults to
10. The maximum number of associations, preemptable or not, is now and
has been 50. The floor, ceiling and cohort values can be used to filter
for selected stratum levels. The timeout and demobilization issues are
very tricky and interact with the various modes and error conditions.
The only reasons why I did this now rather than later is that I was
working on the configuration chapter of the book and Brian's message
caused me to review the assumptions.
Your suggestion to "not want to grab as many answers as soon as
possible" can be counterproductive. Once things settle down and the poll
interval climbs to the max, a newcomer with low dispersion and bad time
can be quite disruptive, possibly tossing out the best server at large.
What works better here is to set minclock at 3 and maxclock at 4 or 5.
The manycast and/or pool schemes (both can be used at the same time)
sift only the floor/ceiling statum range, keep the first maxclock found
and, in the pool case, timeout the others.
Experiments here reveal the only really fair thing to do is occasionally
demobilize the lot and start over. Since the server seed is refreshed
about once per day and after that the Autokey protocol must run in order
to generate a new cookie, it seems reasonable to demobilize/start over
at that time. Since preemptable assoications are configured with iburst,
the client is resynchronized in seconds. These issues are not resolvable
by discussion and consensus, they are engineering reality.
As to how what I have been referring to as the asynchronous resolver, my
previous and this message are intended to explain the expected behavior
and I don't favor one resolver scheme over another. I am however
concerned that the expected behavior is not happening now. Upon
reflection, the problem could indeed be in Solaris, as I mentioned the
backroom and campus wires are configured to use NIS. Secondary NIS
servers whimsy and pogo are configured to use DNS if NIS doesn't have
the data. We recently upgraded to Solaris 10 from Solaris 9 and the
problem probably began at the upgrade. I'm not sure what the actual DNS
code is built on, but it is the same code used in our department and
campus Solaris servers. If in fact the problem is misconfigured caches
or something like that, none of our department and campus machines will
be able to use the pool discovery scheme.
Brian, help!
I'm not interested in taking this discussion off list. I want this
discussion to be completely public on the hackers list.
Dave
Harlan Stenn wrote:
> Dave,
>
> sys_maxclock is new, as I recall.
>
> My belief is we simply do not want to grab as many answers as soon as
> possible. If that's what somebody *wants* as a local policy that's fine
> and we should support that.
>
> The mechanism we implement should, IMO, be more flexible and robust.
>
> We need a design for this, and the URL I mention is *a* place to either
> do or track that effort.
>
> I'd also like to consider if converting to eventlib should be part of this
> effort or independent of this effort.
>
> Finally, we need to take a stab at what release version this should be
> targetted for. I plan to start the 4.2.1 countdown within the next 2
> weeks or so, and I suspect this effort will take longer than that.
>
> I would be Happy to have this be in 4.2.2 (or 4.3.0, or whatever), which
> I also plan to release sooner than the 4.2.0 -> 4.2.1 relesae has
> happened.
>
> H
More information about the hackers
mailing list