Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Update HowTo on using the pool #218

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Update HowTo on using the pool #218

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6f8398c
Update HowTo to on using the pool
penguinpee May 23, 2022
03859ca
Whitespace (space vs. tabs)
penguinpee May 23, 2022
ef6d93f
Squashed commit of the following:
penguinpee May 27, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
78 changes: 52 additions & 26 deletions docs/ntppool/en/use.html
View file
Open in desktop
Expand Up @@ -11,25 +11,51 @@ <h3 id="use">How do I use pool.ntp.org?</h3>

<p>
The 0, 1, 2 and 3.pool.ntp.org names point to a random set of servers that will
change every hour. Make sure your computer's clock is set to something
change every couple of minutes. Make sure your computer's clock is set to something
sensible (within a few minutes of the 'true' time) - you could use <code>ntpdate
pool.ntp.org</code>, or you could just use the <code>date</code> command and set it
2.pool.ntp.org</code>, or you could just use the <code>date</code> command and set it
to your wristwatch. Start ntpd, and after some time (this could take as long as
half an hour!), <code>ntpq -pn</code> should output something like:
</p>

[% INCLUDE "ntppool/use/sample-ntpq.html" %]
[% INCLUDE "ntppool/use/sample-pool-ntpq.html" %]

<p>
The IP addresses will be different, because you've been assigned random
timeservers. The essential thing is that one of the lines starts with an
asterisk (<code>*</code>), this means your computer gets the time from the internet
- you'll never have to worry about it again!
</p>
<p>On more recent Linux operating systems, time setting has been delegated to
<code>systemd</code>. You can use <code>timedatectl</code> to set the time:
</p>

[% INCLUDE "ntppool/use/sample-timedatectl.html" %]

<p>
On some Linux distributions <a href="https://chrony.tuxfamily.org/"><code>chronyd</code></a>
has replaced <code>ntpd</code> as the default NTP client (and server). With respect
to the time source configuration it uses the same syntax as <code>ntpd</code>,
so you can use the example above, leaving out the <code>tos maxclock</codecode> line.
Usually, the shipped configuration comes with a sensible default using the distribution's
vendor pool and doesn't need any adjusting at all.
For checking on the synchronization status, use <code>chronyc -n sources</code>.
The output is similar to <code>ntpq</code> including the asterisk designating
the current time source.
</p>
<p> On older systems, <code>ntpd</code> may not support the pool configuration described
above. The following should work with legacy <code>ntpd</code> versions:
</p>

[% INCLUDE "ntppool/use/sample-ntpq.html" %]

<p>
Looking up <code>pool.ntp.org</code> (or <code>0.pool.ntp.org</code>,
Looking up <code>2.pool.ntp.org</code> (or <code>0.pool.ntp.org</code>,
<code>1.pool.ntp.org</code>, etc) will usually return IP addresses for servers
in or close to your country. For most users this will give the best results.
in or close to your country. For most users this will give the best results.<br>
<strong>Note:</strong> For historical reasons only <code>2.pool.ntp.org</code> will
return both IPv4 <emphasize>and</emphasize> IPv6 addresses. The other names only
return IPv4 addresses.
</p>

<p>You can also use the <a href="/zone/@">continental zones</a> (For example
Expand All @@ -46,13 +72,13 @@ <h3 id="use">How do I use pool.ntp.org?</h3>
If you're using <b>a recent Windows version</b>, you can use the ntp
client that is built into the system. As administrator enter</p>
<pre class="code">
w32tm /config /syncfromflags:manual /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org"
w32tm /config /syncfromflags:manual /manualpeerlist:"2.pool.ntp.org 3.pool.ntp.org 0.pool.ntp.org 1.pool.ntp.org"
</pre>
<p>
at the command prompt. This will work on Windows 2003 and newer. If you use an
older version of windows you can try</p>
<pre class="code">
net time /setsntp:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org"
net time /setsntp:"2.pool.ntp.org 3.pool.ntp.org 0.pool.ntp.org"
</pre>
<p>
The same can be achieved by, as administrator, right-clicking the clock in the taskbar,
Expand All @@ -73,23 +99,23 @@ <h3 id="use">How do I use pool.ntp.org?</h3>
<div class="block">
<h3 id="notes">Additional Notes</h3>

<p><span class="hook">Consider if the NTP Pool is appropriate
for your use</span>. If business, organization or human life
depends on having correct time or can be harmed by it being
wrong, you shouldn't "just get it off the internet". The NTP
Pool is generally very high quality, but it is a service run
by volunteers in their spare time. Please talk to your
equipment and service vendors about getting local and reliable
service setup for you. See also our <a href="/tos.html">terms
of service</a>.

We recommend time servers from
<a href="http://www.meinbergglobal.com/english/products/ntp-time-server.htm">Meinberg</a>,
but you can also find time servers from
<a href="http://www.endruntechnologies.com/NTP-Servers/gps-cdma-ntp.htm">End Run</a>,
<a href="http://spectracom.com/products-services/precision-timing#anchor-2172">Spectracom</a>
and many others.
</p>
<p><span class="hook">Consider if the NTP Pool is appropriate
for your use</span>. If business, organization or human life
depends on having correct time or can be harmed by it being
wrong, you shouldn't "just get it off the internet". The NTP
Pool is generally very high quality, but it is a service run
by volunteers in their spare time. Please talk to your
equipment and service vendors about getting local and reliable
service setup for you. See also our <a href="/tos.html">terms
of service</a>.

We recommend time servers from
<a href="http://www.meinbergglobal.com/english/products/ntp-time-server.htm">Meinberg</a>,
but you can also find time servers from
<a href="https://endruntechnologies.com/products/ntp-time-servers">End Run</a>,
<a href="https://www.orolia.com/solution/timing-and-synchronization/">Orolia</a>
and many others.
</p>
penguinpee marked this conversation as resolved.
Show resolved Hide resolved

<p><span class="hook">If you have a static IP address and a reasonable Internet connection</span> (bandwidth
is not so important, but it should be stable and not too highly loaded), please
Expand All @@ -114,7 +140,7 @@ <h3 id="notes">Additional Notes</h3>
servers are really file or mail or webservers which just happen to also run ntp.
So don't use more than four time servers in your configuration, and don't play
tricks with <code>burst</code> or <code>minpoll</code> - all you will gain is extra
load on the volunteer time servers.</p>
load on the volunteer time servers.</p>

<p><span class="hook">Make sure that the <i>time zone configuration</i> of your computer is correct</span>.
ntpd itself does not do anything about the time zones, it just uses UTC
Expand All @@ -123,7 +149,7 @@ <h3 id="notes">Additional Notes</h3>
<p><span class="hook">If you are synchronising a network to pool.ntp.org</span>, please set up one of your
computers as a time server and synchronize the other computers to that one.
(you'll have some reading to do - it's not difficult though. And there's always
the <a href="news:comp.protocols.time.ntp">comp.protocols.time.ntp newsgroup</a>.)</p>
the <a href="https://community.ntppool.org/">community</a> to help out.)</p>

<p class="thanks">At this point, I'd like to thank those donating their time and timeservers to
this network.</p>
Expand Down
4 changes: 2 additions & 2 deletions docs/ntppool/use/sample-config.html → docs/ntppool/use/sample-legacy-config.html
View file
Open in desktop
@@ -1,8 +1,8 @@
<pre class="code">
driftfile /var/lib/ntp/ntp.drift

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org
server 0.pool.ntp.org
server 1.pool.ntp.org
penguinpee marked this conversation as resolved.
Show resolved Hide resolved
</pre>
5 changes: 5 additions & 0 deletions docs/ntppool/use/sample-pool-config.html
View file
Open in desktop
@@ -0,0 +1,5 @@
<pre class="code">
pool 2.pool.ntp.org iburst
Copy link

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:

Suggested change
pool 2.pool.ntp.org iburst
pool 0.pool.ntp.org iburst maxsources 1
pool 1.pool.ntp.org iburst maxsources 1
pool 2.pool.ntp.org iburst maxsources 1
pool 3.pool.ntp.org iburst maxsources 1

Copy link
Contributor

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.

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.

pool 0.pool.ntp.org iburst maxsources 1

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.

Copy link
Author

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 with maxsources 1 effectively turns it into a server 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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is using pool with maxsources 1 equivalent to server? If a pool host stops responding, it will be removed and a DNS lookup re-triggered for a new one. If a host configured with server 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 just 2. @abh has suggested previously that the special case of 2.pool.ntp.org with respect to IPv6 will be changing in the future, so better to include all of the pools.

Copy link
Contributor

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 single pool to make the configuration simpler and reduce the number of DNS requests. If pool.ntp.org included IPv6 addresses, that would be the best choice. Until that happens, it is 2.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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@abh has suggested previously that the special case of 2.pool.ntp.org with respect to IPv6 will be changing in the future, so better to include all of the pools.

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 😞.

Copy link

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 single pool to make the configuration simpler and reduce the number of DNS requests. If pool.ntp.org included IPv6 addresses, that would be the best choice. Until that happens, it is 2.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.

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

Copy link

@hart-NTP hart-NTP Nov 20, 2022 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@abh has suggested previously that the special case of 2.pool.ntp.org with respect to IPv6 will be changing in the future, so better to include all of the pools.

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 😞.

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

# Tight restrictions for the public, but loosen them for servers
# we use for time.  Note the lack of nopeer on "restrict source"
# is important, otherwise pool associations will not spin up.
# These restrictions do not allow the public to query via ntpq (noquery)
# or set up event traps used by network monitoring tools to keep tabs
# on remote ntpd instances (notrap). "limited" and "kod" refuse to
# respond to clients that query too often, by default more than once
# every 2 seconds in a burst or more than once per 8 seconds long term.
# Adding kod sends occasional "kiss of death" responses to clients
# exceeding the rate limit, providing no useful time and requesting
# the client to back off their polling interval, which they will if 
# using ntpd and their maxpoll allows.

restrict default nopeer noquery nomodify notrap limited kod
restrict source         noquery nomodify notrap limited kod

# Allow status queries and everything else from localhost and local net.
# If there are hosts used as time sources in the local network, they
# will be subject to the "restrict source" restrictions above, so they
# will not be able to use ntpq with this host.

restrict 127.0.0.1 
restrict ::1
restrict 192.168.0.0 mask 255.255.0.0

# Require at least two sources in reasonable agreement before adjusting
# the clock.  The default minsane is 1 "for legacy purposes."  Lower
# maxclock from the default 10 to a more reasonable number for the pool.
tos minsane 2 maxclock 5

pool pool.ntp.org iburst

=== ntp.conf ===

This is also a reasonable configuration for a non-refclock pool server, perhaps with slightly different tos knob-twisting:

tos minsane 3 minclock 5 maxclock 8

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd love to get clarification on how chrony behaves with "server ", "server preempt" (if it has the preempt option), and "pool ".

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

Copy link
Author

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.

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.


tos maxclock 5
</pre>
Copy link
Contributor

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. With ntpd, 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 be tos maxclock 5 setting to limit the number of used servers to 4.

Copy link

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 propose pool 2.pool.ntp.org iburst.

Copy link
Author

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 of ntpsec (a fork of ntpd) using only a single pool 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 in chronyd having a single pool declared, gets you in sync within a minute.

I'm fine with changing the configuration snippet for ntpd to:

pool 2.pool.ntp.org iburst
tos maxclock 5

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, that tos maxclock is not needed.

Copy link

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.

@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?

Copy link
Author

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 with pool. Default value is 4 and max value is 16.

4 changes: 4 additions & 0 deletions docs/ntppool/use/sample-timedatectl.html
View file
Open in desktop
@@ -0,0 +1,4 @@
<pre class="code">
timedatectl set-timezone "Europe/Kiev"
timedatectl set-time "2012-10-30 18:17:16"
</pre>