In Chrony (and NTP in general), both the server
and pool
directives are used to define time sources, but they differ in how they are handled and what they imply. Here’s a detailed comparison:
1. server directive
The server
directive is used to specify a single time server that Chrony should synchronize with. When you use this directive, Chrony will try to contact this specific server for time synchronization.
Syntax:
server [hostname or IP address] [options]
- Example:
server time.google.com iburst
Key Characteristics of server
:
- Fixed server: This specifies a single, fixed NTP server (or IP address). Chrony will always attempt to sync with this server.
- More control: It provides more control over which specific time source is used.
- Options: Common options with the
server
directive includeiburst
(for faster synchronization) andprefer
(to make Chrony prefer this server over others).
Common Options for server
:
iburst
: Causes Chrony to send multiple requests initially to the server to get a quicker initial synchronization.prefer
: Instructs Chrony to prefer this server over others if there are multiple time sources.
2. pool directive
The pool
directive is used to specify a pool of time servers that Chrony can choose from. When you use this directive, Chrony will select a server from the pool to synchronize with, and if one server is unavailable, it will try another.
Syntax:
pool [hostname or IP address] [options]
- Example:
pool 2.centos.pool.ntp.org iburst
Key Characteristics of pool
:
- Dynamic pool: This specifies a pool of NTP servers. Chrony will automatically resolve the pool domain name into multiple time servers and choose one for synchronization. The server list changes over time, which helps to avoid using the same server repeatedly, improving fault tolerance.
- Load balancing: Chrony can pick a server from the pool based on availability and quality, distributing load across multiple servers.
- Fallback: If one server in the pool is unreachable or unreliable, Chrony will try others in the pool.
Common Options for pool
:
iburst
: Just like withserver
, this option speeds up the synchronization process.
Note: The pool is resolved into a set of time servers, so pool
is often used for public NTP pools that have multiple servers available.
Key Differences:
Feature | server | pool |
---|---|---|
Type | Specifies a single NTP server. | Specifies a pool (group) of NTP servers. |
Server Count | Fixed to one server. | Dynamic list of servers (multiple). |
Fault Tolerance | If the specified server is unavailable, Chrony will not be able to sync. | If one server in the pool fails, Chrony tries another. |
Use Case | When you need to specify a specific, known server. | When you want to use a set of servers for better redundancy and load balancing. |
Domain Resolution | Requires the exact hostname or IP address of the server. | Resolves a domain name to a list of multiple servers (e.g., pool.ntp.org ). |
Example Use Case:
-
Using
server
: If you want to sync with a specific server, such as a corporate NTP server or a trusted public time server, you would useserver
:server time.nist.gov iburst
-
Using
pool
: If you want Chrony to automatically select from a pool of public NTP servers for better reliability and load balancing, you would usepool
:pool 0.centos.pool.ntp.org iburst
In summary, use server
when you need to synchronize with a specific time source and use pool
when you want to allow Chrony to pick the best available time server from a pool of servers.