Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update HowTo on using the pool #218
base: main
Are you sure you want to change the base?
Update HowTo on using the pool #218
Changes from all commits
6f8398c
03859ca
ef6d93f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with your current setup is that it excludes any servers in the 0, 1, and 3 DNS records. In underserved zones, this won't be a problem, but in zones with sufficient capacity, the results returned in 0, 1, and 3 should be a discrete set of servers from 2. So using
maxsources
is the only way to be correct for all cases:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand it, the split of servers between 0, 1, 2, 3 is randomly changing over time. Even if 2 has fewer than four servers, the client should get four different addresses after few minutes. Of course, it would be better to use the non-numbered zone if it included both IPv4 and IPv6 servers.
This is effectively almost identical to
server 0.pool.ntp.org iburst
. The only difference is in the initial selection of servers when some are not responding, e.g. 0 had some IPv6 servers and they were preferred by the client's DNS resolver, but IPv6 connectivity was broken. Probably not worth the change, as long as only 2 has IPv6 servers.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @mlichvar, using
pool
directive withmaxsources 1
effectively turns it into aserver
directive.I'm not familiar with the pool distribution logic. But seeing that major distributions ship NTP configurations only using 2.vendor.pool.ntp.org I don't see any immediate issue following suite. Besides these changes are somewhat masking the underlying issue documented in #176, which still needs to be solved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is using
pool
withmaxsources 1
equivalent toserver
? If a pool host stops responding, it will be removed and a DNS lookup re-triggered for a new one. If a host configured withserver
stops responding, it will just be ignored and no attempt will be made to rectify the situation. I still maintain that all pools should be included, not just2
. @abh has suggested previously that the special case of2.pool.ntp.org
with respect to IPv6 will be changing in the future, so better to include all of the pools.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The server will be replaced even if specified as
server
. I'd prefer a singlepool
to make the configuration simpler and reduce the number of DNS requests. Ifpool.ntp.org
included IPv6 addresses, that would be the best choice. Until that happens, it is2.pool.ntp.org
. It can provide only a quarter of IPv4 addresses at a time, but this assignment into 0,1,2,3 is randomly changing over time, so the client can get any address from the whole set.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, once that happened, it be easy to adjust the documentation again. But until that happens, we should stick with
2.pool.ntp.org
in support of IPv6. PR #176 is nearing its third anniversary 🎂 but still waiting for a resolution 😞.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That may be true for chrony, but it is not the case for the ntpd reference implementation. ntpd will never discard a configured "server 0.pool.ntp.org" unless it includes the "preempt" option to the server directive. Every association spun up by the pool directive has "preempt" automatically added. So with ntpd, "pool"-spun associations will be dropped if they do not contribute to the time solution for about 10 polls, while "server" associations are only eligible to be dropped with "preempt" specified. Pool associations will be replaced automatically, while "server ... preempt" associations are not replaced after they're dropped, making it undesirable in practice. I suspect NTPsec hasn't changed that behavior since it forked from the reference implementation 4.2.8 version.
I'd love to get clarification on how chrony behaves with "server ", "server preempt" (if it has the preempt option), and "pool ".
Thanks,
Dave Hart
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I respectfully disagree. IMHO configurations suggested by the pool project are likely to live on long after the pool project changes those suggestions. With that in mind, I think the pool project suggestion should be a single pool pool.ntp.org iburst which allows the pool project to decide when to start serving IPv6 addresses more widely, rather than suggesting people use 2.pool.ntp.org's current IPv6 peculiarity. There could be a note that IPv6-only systems should use 2.pool.ntp.org instead for now, but my preference would be to see the primary suggestion remain the unnumbered pool.ntp.org/vendor.pool.ntp.org.
It's also important to note that with the reference implementation (and possibly NTPsec), restrict ... nopeer restriction can prevent pool associations from working. If restrict default ... nopeer is used, it's critical to also have a similar restrict source directive that does not include nopeer. A restrict source directive causes every association that is spun up (including from server and pool) to get a host-specific automatic restriction which overrides any other restrictions that would otherwise apply to the association's remote address. This was put in place to allow users of the pool directive to be able to target restrictions at pool server IPs which are not known at configuration time. If this is confusing, just fire away and I'll be happy to explain further.
I strongly feel the suggested configuration should include only one pool directive. As noted previously, each additional pool directive requires a corresponding increase in tos maxclock for ntpd, complicating the suggested configuration. It also triggers additional relatively useless DNS queries, at least for ntpd users. ntpd with a single pool pool.ntp.org iburst synchronizes as fast as the currently suggested 4 server #.pool.ntp.org iburst directives because the implementation immediately does a DNS lookup of the pool hostname and holds on to all IPs returned and spins an association with the first IP address. As soon as that server's response is received, another pool association is spun one second later with the next IP address as long as tos masclock hasn't been exceeded, If the list IP addresses from the DNS query is exhausted, another DNS query is triggered immediately, and when that DNS response comes in, another pool association is spun up a second later. The net result is up to the lesser of maxclock - 1 and the number of usable pool IPs found for pool.ntp.org (currently 4 for IPv4) are spun up within seconds. With pool.ntp.org using 150 second DNS TTL, more servers will be spun up within 4 default 64s pool prototype association cycles.
I have milder feelings about suggesting a higher tos minclock configuration for ntpd users, but I think it should be considered. Currently, as the docs say, "for legacy purposes" the default is tos minsane 1 but it should really be a larger number that is less than tos minclock (which defaults to 3).
Putting it all together, this is my take on a suggested ntp.conf for ntpd pool use:
=== ntp.conf ===
driftfile /etc/ntp.drift
=== ntp.conf ===
This is also a reasonable configuration for a non-refclock pool server, perhaps with slightly different tos knob-twisting:
That makes a good pool server which will naturally gravitate to higher-quality sources and is a bit more paranoid about getting consensus between sources before considering itself synched and therefore serving time to clients and adjusting the local clock. You might want to throw in a hardwired server if you like a particular stratum-1 server that you can reach with low jitter.
Cheers,
Dave Hart
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Chrony's server statement has no 'preempt' option. Pool and server behave the same. Chrony expects pools to resolve to multiple addresses and you can specify how many addresses chrony will use from any given pool.
https://chrony.tuxfamily.org/doc/4.3/chrony.conf.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is about changing the configuration examples on the website. That can easily be adjusted if the pool layout changes and all pools start announcing IPv6 servers. Most distributions do the right thing and ship their own vendor configuration, which, most notably, quite often contains
pool 2.vendor.pool.ntp.org ...
.So, the issue with IPv4 limitations of 3/4 of the pool is widely known and worked around. It's time to fix it and enable IPv6 on all pools. Until then the documentation should be updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There needs to be only one pool directive. With
chronyd
4 specified pools would result in 16 used servers. Withntpd
, at least with some versions, I think it would decrease the number of servers as there is a dummy source added for each pool and I suspect it would increase the DNS traffic unnecessarily.For
ntpd
, there should betos maxclock 5
setting to limit the number of used servers to 4.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. And
pool pool.ntp.org iburst
would be a great choice, if it weren't for the fact that it has no AAAA-record. Hence, I proposepool 2.pool.ntp.org iburst
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right. Unless
maxsources
is used,chronyd
will use 4 servers per pool. Smart. 🕶️Setting
tos maxclock 5
is correct if declaring a single pool. According to the documentation ofntpsec
(a fork ofntpd
) using only a singlepool
declaration has some limitations. That limitation being that associations are slower to be established, I infer from the comments in the sample configuration.I haven't used
ntpd
recently, but inchronyd
having a single pool declared, gets you in sync within a minute.I'm fine with changing the configuration snippet for
ntpd
to:I left out the
driftfile
directive. It's distribution specific and I believe taken care of by most distribution's default configuration.For
chronyd
we need a remark then, thattos maxclock
is not needed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mlichvar is the number 4 determined by chrony or is it based on the number of addresses returned from a single DNS query of pool.ntp.org? If it's chrony, is that hardcoded or a configurable default value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's configurable using
maxsources
in connection withpool
. Default value is 4 and max value is 16.