Hi Miroslav,
Miroslav Lichvar wrote:
Hi,
I'm wondering how would an ideal support for pools implemented in NTP
clients look like and how should it be configured for pool.ntp.org to
allow vendors to use it in their default configuration.
The current practice seems to be that three or four servers are
specified in the client's configuration file by the {0,1,2,3}* names,
the client resolves the names on start, adds only one source for each
name and sticks to the addresses until it's restarted.
The obvious problem is that the servers can be removed from the pool
at any time or be unreachable for other reasons. Until the clients are
restarted they are missing time sources which reduces the reliability
of the timekeeping and the servers are still receiving NTP traffic
even if they have stopped the service long time ago.
Correct, and I think that's exactly the reason why the "pool" directive
you mention below has been introduced to be used on the clients
preferably instead of the {0,1,2,3}* names.
Unfortunately I'm not familiar with the implementation details of the
"pool" directive.
Some NTP implementations now have special directives that can be used
to specify a pool of servers and allow replacement of unreachable
sources, but it's not clear to me if they are ready for a large-scale
deployment.
As far as I can see the "pool" directive is already supported in the
current stable version 4.2.6p5:
http://doc.ntp.org/4.2.6p5/confopt.html#server
However, if I understand this posting correctly
http://lists.ntp.org/pipermail/questions/2010-April/026304.html
there have been major improvements in 4.2.7p22, and there even may have
been changes between that version and the current -dev version of ntpd.
Unfortunately the latest stable version is still 4.2.6p5.
Anyway, I think in discussions related to implementation details the
specific version should be mentioned.
Some of the implementation details for 4.2.7p22 are explained in the
Dave Hart's posting the link to which I've mentioned above.
I think his explanation sounds very reasonable from an NTP client's
point of view.
Here are some requirements that I thought would be important to not
waste the resources of the pool.ntp.org project and some questions
on details:
- the number of concurrently used servers is limited
- should it be a fixed configurable limit? per pool name or global?
In his posting Dave Hart mentions the
tos minclock 3 maxclock 6
directive which could be used to configure the limits. However, a quick
test with client running 4.2.7p470 always mobilized exactly 4 pool
associations, so this doesn't seem to work (anymore) as expected, or I
may be missing something.
- can the client use more sources than number of addresses returned
in one DNS query?
- how should the client find IPv6 servers? they are currently returned
only for the 2*pool.ntp.org name (4 IPv4 + 4 IPv6 addresses)
- the client replaces unreachable pool servers with newly resolved
addresses
- should be the initial polling interval for the new server same as
was used by the replaced source to avoid frequent polling when the
sources are replaced frequently? (e.g. when NTP traffic is
blocked)
IMO if a new association is established it should be done always in the
same way, i.e. if "iburst" has been specified it should be used, and
otherwise the default polling interval should be used, no matter if it's
at daemon startup, or when a "server" is added dynamically by
ntpdc/ntpq, or when the "pool" management decides to ad or replace an
association.
- can be sources marked as falsetickers replaced too?
- should the client also check if reachable servers are still in
the pool and replace them if not? any recommendations on that?
How could a client be able to do this? From my understanding it just
gets gets a (more or less) random IP address from the pool's DNS server,
and a reverse lookup of the IP address should yield the "real" hostname
of the server.
If another lookup is done with the DNS pool server a different IP
address is returned.
A possible way to do this which comes to my mind would be to introduce
DNS names like aa.bb.cc.dd.pool.dns.org, so once a client has received
aa.bb.cc.dd as a pool server address it could check if
aa.bb.cc.dd.pool.dns.org still resolves, and if not assume this server
has been removed from the pool.
- the client doesn't make DNS requests too frequently
- should that be based on the DNS TTL (assuming the client can get
that information)?
IMO that would be a good approach.
- should there be a fixed minimum interval? or an exponentially
increasing interval?
I think this depends.
For example there has been a similar case with laptops. When the laptop
(and ntpd) start up and yet there is no internet connection then ntpd is
unable to resolve any host names, or poll any server specified by IP
address. The "legacy" approach was to increase the retry interval
exponentially, but the problem was that when the laptop later got a
network cable plugged in, or a WIFI connection, it could take 30 minutes
or so until ntpd retried to resolve names, or poll specified servers.
This is certainly not what you'd expect.
The workaround was to listen on the routing socket and retry
*immediately* when a new interface has appeared.
So also in this case we might need to distinguish in which case we
retry. If DNS works correctly (i.e. a pool DNS server can be contacted,
then this could be done before the TTL interval expires, so this can be
somewhat be controlled by the pool operators. Isn't this somehow similar
to DHCP, where AFAIK clients usually contact the DHCP server to refresh
their lease after half the lease time has expired?
In case of (e.g.) a laptop where the internet connection is
(temporarily) broken a DNS lookup could be retried immediately if more
then the TTL (or half of it) has been expired at the time the internet
connection comes back.
What do you think?
Since most of these points are more related to how NTP clients
should/could behave vs. how this is actually implemented maybe a good
location to discuss this would be the NTP hackers list.
And yes, I know unfortunately that list is actually pretty quiet since
currently there are only very few active developers. :-(
Martin
--
Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: [email protected]
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
