[ntp:hackers] NTPv4 Brian Version
Brian Utterback
Brian.Utterback at Sun.COM
Tue Aug 9 09:48:21 UTC 2005
Very close to what I am looking for Dave. The problem you are seeing is
due to the caching in nscd. However, the default cache for hosts is
something like 5 minutes, so if you did have what you suggested,
(i.e. configure all addresses returned) and the period for revisiting is
longer than the cache time, then you would be okay anyway.
My only concern at this point would be the "revisit". I think that you
need a longer term criteria for judgement than just looking at the data
in the billboard. A fairly short term network glitch could cause you to
lose your best server. That is the purpose of the rank variable, to
provide a longer term memory over ntpd's own thoughts on what is the
best server.
And, of course, this doesn't help an admin choose between non-preempt
servers, although the admin might be able to use the preempt feature.
So, if you have such a long term criteria in mind, then set rank to
that. If not, then might I suggest using rank as I have it proposed? And
again, is there any downside? "rank business", ha.
David L. Mills wrote:
> Folks,
>
> The rank business scared me, as I had very different plans. Try the
> ntp-dev version with new server subcommand preempt
>
>
> server host1 iburst preempt
> server host2 iburst preempt
> server host3 iburst preempt
> server host4 iburst preempt
> server host5 iburst preempt
> server host6 iburst preempt
> ...
> tos floor 2 ceiling 3 minclock 3 maxclock 4
>
> It will mobilize all the servers listed, then proceed to cast off all
> but the best four servers at stratum 2, then trim those to the final cut
> 3. The four servers stay around, so the final cut can be retrimmed. This
> is what I think Brian wants, but doesn't require manual intervention.
>
> Now, if an asynchronous resolver or equivalent was available, the loser
> in the above step would be discarded periodically and replentished from
> the available population. Manycast should work the same way, but it does
> periodically refresh. I haven't tested the new scheme with manycast yet.
> My intent is that the manycast and pool schemes should work much the
> same way, although using different discovery schemes.
>
> For some reason the pool is giving attitude. The resolver returns the
> same server every time asked. The nslookup and dig utilities in Solaris
> apparently return the right stuff, but the ntpd resolver seems stuck.
> None of the region zones work except us and asia. It would be nice that,
> by direction, the entire list returned in one query would be lit up
> rather than callinb many times.
>
> Dave
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers
More information about the hackers
mailing list