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 include iburst (for faster synchronization) and prefer (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 with server, 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:

Featureserverpool
TypeSpecifies a single NTP server.Specifies a pool (group) of NTP servers.
Server CountFixed to one server.Dynamic list of servers (multiple).
Fault ToleranceIf the specified server is unavailable, Chrony will not be able to sync.If one server in the pool fails, Chrony tries another.
Use CaseWhen you need to specify a specific, known server.When you want to use a set of servers for better redundancy and load balancing.
Domain ResolutionRequires 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:

  1. 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 use server:

    server time.nist.gov iburst
  2. Using pool: If you want Chrony to automatically select from a pool of public NTP servers for better reliability and load balancing, you would use pool:

    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.