1

Objective

I had locally isolated hosts. I'd like them all have the same time. One takes role of the time server, other syncs with it as clients.

All machines has sporadic uptime. They are powered rarely. So they could gain significant offset. Entire hosts set should become synced within minutes after setting the server local time manually.

To confirm reliability I had tested the ntp hosts connection by setting great manual adjusts (several hours) and measured how fast clients synced.

ntpd - ntpd case

I tried use ntpd for clients as well the server. ntpd take very long time to adjust clock. Moreover it refuses to rewind time by couple of hours.

If it could be fixed, I prefer to use ntpd as client. So I'm looking for configuration options to hint ntpd for being eager at accepting network clock updates.

But if there is no way to employ ntpd, ntpdate alternative is still acceptable.

ntpd - ntpdate case

ntpdate perfectly updates clock without hesitation. I put it in a cron task and got rough but working solution. Unfortunately the first impression was wrong. After several tests I noticed that the ntpdate client started refusing the server. For some reasons server decided to return stratum 16. I explicitly put fudge 127.127.1.0 stratum 8 into the ntp.conf on the sever side to avoid this exact behaviour. But ntpdate -v -d output shows "stratum 16" transmitted from the server.

So I see two ways. Either compel the ntpd server return stratum 9 regardless of local time jumping or force the ntpdate client to accept any server, even if it has stratum 16.

I tried to google either way but found nothing. Could anyone suggest suitable configuration options?

2 Answers 2

2

Use one ntpd time server for all. All everyday rebooted PC can synchronize their clocks at start by ntpdate command. Clocks on other servers can be synchronized by ntpd service because it adjusts time softly.

For main ntpd time server use:

server 127.127.1.0 prefer
fudge 127.127.1.0 stratum 2
driftfile /var/lib/ntp/ntp.drift
restrict default nomodify notrust
restrict 127.0.0.0/8
disable auth
logfile /var/log/ntp.log
9
  • I have the same configuration. But the ntpd (from Ubuntu 16.04) ignores fudge 127.127.1.0 stratum 2 option sometims. Debug shows that the ntpd server sends stratum 16 for some unknown to me reason
    – ayvango
    Mar 23, 2018 at 18:52
  • Do you have only one server declaration in ntpd. conf file? Mar 23, 2018 at 18:54
  • yes. I removed all other servers and pools. And server resides in a network isolation.
    – ayvango
    Mar 23, 2018 at 18:55
  • Server is physical or virtual? Mar 23, 2018 at 18:57
  • Physical. It would be used in a place without internet
    – ayvango
    Mar 23, 2018 at 18:59
2

My main suggestion: Don't do this. Try to change your requirements or constraints so that you can have an always-on system which can be a time source, or so that your systems are not isolated and can get time from the global NTP pool, or both.

You can get low-power NTP servers with GPS receivers quite cheaply nowadays. If you like to DIY, BeagleBones and Raspberry Pis can be made into NTP servers for under US$100, or if you want something off-the-shelf, try a LeoNTP.

Next suggestion: if ntpd takes a long time to update the clock, you probably need to check your configuration:

  1. Make sure you are using the -G command-line flag; -g is the default on some Linux distributions, but it won't make large backwards steps.
  2. Ensure all of your servers/pools are configured with iburst.
  3. Use tinker step 0.5 and tinker panic 0 to maximise ntpd's ability to fix large offsets.
  4. Make sure your drift file is writable by ntpd and is getting saved correctly when it shuts down.

Third suggestion (which I would prefer over ntpdate): try chrony - it has explicit support for occasionally-connected clients (like laptops which are suspended regularly). The chrony.conf(5) man page has all the details about this. If you're using a distribution where chrony is the default (CentOS/Red Hat, and Ubuntu after 18.04 is released), this would probably be my second suggestion.

Last suggestion: if ntpdate is reporting a server as stratum 16, it means there's something wrong with that server. Try posting the configuration of the server, and the output of ntpq -np and ntpq -nc rv so that we can help diagnose it.

4
  • The configuration is irrelevant. After restarting it begin serve proper stratum. So it is not a configuration issue but a runitme behaviour. Changing local clock frequently made ntpd believe in failure. I read documentation about tinker step it is about slewing not about ignoring large steps. But it says that there is 900s threshold for discarding large steps. Is it possible to change that threshold?
    – ayvango
    Mar 28, 2018 at 9:41
  • example: setting local time one year back made server return stratum 16 for many hours
    – ayvango
    Mar 28, 2018 at 12:05
  • @ayvango: I don't know which documentation you're reading, but doc.ntp.org/current-stable/miscopt.html#tinker and doc.ntp.org/current-stable/clock.html#step make it very clear that tinker step is about stepping, not slewing. You also probably want tinker panic 0 to ensure ntpd stays running no matter what.
    – Paul Gear
    Mar 29, 2018 at 0:06
  • The configuration is not irrelevant; if it's serving bad time (stratum 16) and a restart with the same configuration causes it to serve good time, that means that the configuration is not enabling it to keep serving good time consistently. The config items I've suggested should help this (although they can't guarantee it).
    – Paul Gear
    Mar 29, 2018 at 0:09

You must log in to answer this question.

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