[time] more ntpd pool fun
Tue Feb 23 10:51:06 UTC 2010
Date: Tue, 23 Feb 2010 02:48:05 -0800 (PST)
Message-ID: <d7efa3ba-6b72-40f8-b7e0-8aad0799d745 at l12g2000prg.googlegroups.com>
Subject: splash around with ntp-dev in the pool
From: Dave Hart <davehart at gmail.com>
I have a prototype of a couple of new features that should go into ntp-
dev soon which make ntpd a more savvy client of pool.ntp.org. I would
appreciate testing and feedback.
I've mentioned the first part previously to the hackers at lists.ntp.org
and timekeepers at fourty-two.ch lists: A reworked "pool" directive in
ntp.conf which acts as much like manycastclient as I could manage.
Servers come and go automatically according to policy knobs such as
maxclock, floor, and ceiling. A server which is unreachable should be
removed and eventually replaced. A scoring mechanism should trim the
least helpful sources and mix in some new ones over time.
All of this is how manycastclient is implemented today, this is just
an extension of that to a different solicitation mechanism.
manycastclient sends multicast NTP client mode packets and on receipt
of unicast responses, configures a preemptible association. pool now
sends one unicast solicitation at a time, and reacts similarly to
New today is "restrict source ..." which configures a prototype access
control restriction to be applied to all associations which do not
already have a host-specific restriction in place when mobilized.
This means you can now have broadly restrictive "restrict default"
entries which would not work previously with pool sources due to their
unpredictable (and now changing) numeric addresses.
Unrelated to the pool support in ntpd but important if you use a
refclock, there is a fix for a bug introduced in 4.2.7p18 and
identified by Hal Murray: http://bugs.ntp.org/1497
All this and a guarantee it's not official:
Thanks for your time and support,
More information about the pool