[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