0

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.

Improve this question
5
  • 1
    Why not just change the internal NTP servers to use a single (the same) time source?
    – Ƭᴇcʜιᴇ007
    Commented Dec 16, 2015 at 21:45
  • @Ƭᴇcʜιᴇ007 what if that source becomes unavailable (e.g. the server goes down or a network partition happens?)
    – 2rs2ts
    Commented Dec 16, 2015 at 21:53
  • IME NTP server addresses named with "pool" usually represent multiple NTP servers (that are sync'd), in case one isn't available...
    – Ƭᴇcʜιᴇ007
    Commented Dec 16, 2015 at 22:13
  • @Ƭᴇcʜιᴇ007 noted... what if I used prefer instead anyway? It makes me uneasy just putting one server there.
    – 2rs2ts
    Commented Dec 16, 2015 at 22:22
  • The problem you see is known as "clock hopping", and that's tricky to solve. Even with peering it's not guaranteed that the local servers will "prefer" the peer over the remote servers. Even worse (I had it once). The "local server cloud" may drift away from the true time while trusting each other, until they hit the "stratum 16 limit" and re-sync from external, causing a clock jump. It all depends on the details. Eventually we invested in a local GPS time reference (Meinberg M300, no longer sold).
    – U. Windl
    Commented Oct 15, 2023 at 22:10

1 Answer 1

Reset to default
0

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.

Improve this answer
1
  • I think it's a matter of preference: If it's important that the local servers agree on some common time (not necessarily the correct time), then local peering is the way to go; however if it's most important that a maximum number of servers has the correct time, rely of time references (external or local).
    – U. Windl
    Commented Oct 15, 2023 at 22:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .