Will NTP peering help my servers' relative drift?

Question

I have a series of internal NTP servers; every other machine on my network is configured to talk to these servers like so:

# ntp.conf for client machines
server 0.ntp.internal iburst
server 1.ntp.internal iburst
server 2.ntp.internal iburst

Meanwhile these internal NTP servers are configured to talk to Amazon's NTP servers like so:

# ntp.conf for the internal NTP servers
server 0.amazon.pool.ntp.org iburst
server 1.amazon.pool.ntp.org iburst
server 2.amazon.pool.ntp.org iburst
server 3.amazon.pool.ntp.org iburst

The problem I've found is that my NTP servers will choose different AWS NTP servers from each other as their authoritative source, and my client machines will also choose different internal NTP servers from each other as their authoritative source, resulting in some clock drift over time. Basically, I'd like the internal NTP servers to be as consistent with each other as possible, so that, by proxy, my client machines will not be too inconsistent with each other.

I've been reading about NTP peering but I'm getting massively mixed messages about what it actually does and whether it will help reduce the clock drift problem. The thing I am seeing most often is that setting a server as a peer will allow ntpd to treat the peer as a potential time source, but it doesn't make the two servers try to converge their clocks together; however I've seen sources saying to the contrary. I also have seen sources saying that if you peer servers together, you shouldn't let them all have the same list of servers, which makes no sense to me. I don't know what to think.

So... will adding this section to my internal NTP servers' ntp.conf help to get their clocks closer to each other?

# adding to ntp.conf for 0.ntp.internal
peer 1.ntp.internal
peer 2.ntp.internal
# adding to ntp.conf for 1.ntp.internal
peer 0.ntp.internal
peer 2.ntp.internal
# adding to ntp.conf for 2.ntp.internal
peer 1.ntp.internal
peer 2.ntp.internal

By the way, I can't peer the client machines as they are transient, so even if peering is the solution, it can only be done with my internal NTP servers.

Answer 1

Generally you want an odd number of servers and/or peers. The NTP server choice algorithm is complex, and I haven't found good documentation on it.

Some of the factors that are considered include:

• The server's stratum. Lower strata are preferred.
• The server's stability. Servers with more stable data are preferred.
• How well the server's time agrees with other servers.

These are a few rules I use when configuring NTP:

• Peer all internal servers so that they are aware of each other, and can choose to each other as server. In my experience peers tend to be included in the selected server pool.
• Use one or three external server on each internal server.
• If using internal clocks, fudge the stratum to 8 or higher. Use different fudge values for each server.
• Optionally, prefer one server if multiple equally reliable servers are available.

If the clocks are drifting apart there is an issue with your configuration. It has been my experience that running NTP on a virtual server can cause instability.

Peering clients to the server is unlikely to work. The client's stratum will normally be one higher than the server so weighted less heavily.