3

I have a linux machine on a network where the machine only has access to exactly one NTP server. After the time synchronization the status looks like this:

[root@test ~]# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 <ip address>    <ip address>     3 u    8   64   17    1.397    2.510   1.954
*LOCAL(0)        .LOCL.          10 l    6   64   17    0.000    0.000   0.001

My problem here is that even though the remote NTP server has way lower stratum and a decent jitter value, ntpd always picks the local clock as the time source, and in time its clock gets late. The situation remains the same, even after one day, so it's not about me not waiting enough for things to come together.

Questions:

  • is it possible to get reliable time synchronization with only one NTP server on the network? (my guess is no)
  • can I force ntpd somehow to prefer the NTP server over the local clock in this situation?
2
  • The statistics you provide are shortly (256 seconds) after start of ntpd. You must wait significantly longer (at least for 5 polling intervals) until ntpd really starts to tune your clock. Also, recent versions of ntpd seems to treat the local clock differently, so this issue may no longer exist today.
    – U. Windl
    Feb 9, 2022 at 9:35
  • As obviously one server can be wrong and "a man with two clocks never knows what time it is", you should configure at least three servers to get a "majority" of agreeing servers. With just one server most of the NTP algorithms do not work. In case on server fails, you may even want to configure at least four servers, but today one typically configures a "pool".
    – U. Windl
    Feb 9, 2022 at 9:58

2 Answers 2

3

As Pawel has said, remove the local clock line in your ntp.conf. In fact, remove everything, pretty much. If you have a working, sync'ed NTP source on your local network that's willing to act as a server, then clients really only need one line in their ntp.conf, which should read

server ntp.intranet.example.com

or, for fastest syncing,

server ntp.intranet.example.com burst

(the latter puts more load on the server at service start time, but since it's your server, you can say "i permit that", if you want faster syncing at ntpd start time).

Don't forget to put ntp.intranet.example.com in /etc/ntp/step-tickers, or wherever your distro keeps that file, so the clocks of clients can be hard-synced at startup time.

3

Yes, reliable synchronisation to a single clock source is possible. It's not reliable, because you have no redundancy, but that's the only problem.

In your place I would just remove the local time source. On my machines I usually just use external ntpd servers.

You need the local clock only if you need to provide service to clients (think: ntpd server for your internal network) when you have no connection to internet and cannot sync to other servers.

1
  • Can't one keep the local time source and just append a prefer on the external one to make it the prefered one? (i.e. have a line like this: server ip.of.external.time.server prefer in ntp.conf). That way we cover the case that "you need to provide service to clients"
    – ndemou
    Dec 27, 2014 at 22:32

You must log in to answer this question.

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