[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