Query on NTP current time source

Question

I have a query regarding ntpd options and the ntpq command.

I have set up a local NTP Server in Ubuntu 14.04 PC and NTP Client is a custom development platform based on Renesas RZ/G1H.

I have started NTP on my NTP Server and ntpd is running on then NTP Client.

• Currently, my NTP Client is synced with NTP Server. I ran ntpq to confirm that:

  remote          refid       st t      when    poll    reach      delay      offset     jitter
  *192.168.4.98   LOCAL(0)    11 u      -      64        1         0.282     -0.008      0.029
  LOCAL(0)       .LOCL.       14 l      -      64        0         0.000      0.000      0.000
  

  As you can see, 192.168.4.98 is my NTP Server and current time source(*) is displayed on that.

• I have changed the date on the NTP Server (Ubuntu PC) using the date command.

• Then I was running ntpq continuously on the NTP Client side to monitor the change. At one point, the asterisk was not displayed. Below is the output of ntpq:

  remote          refid       st t      when    poll    reach      delay      offset     jitter
  192.168.4.98    LOCAL(0)    11 u      -      64        1         0.282     -0.008      0.029
  LOCAL(0)       .LOCL.       14 l      -      64        0         0.000      0.000      0.000
  

• Then after about 5 mins, asterisk got displayed next to LOCAL(0) like this:

  remote          refid       st t      when    poll    reach      delay      offset     jitter
  192.168.4.98    LOCAL(0)    11 u      -      64        1         0.282     -0.008      0.029
  *LOCAL(0)       .LOCL.      14 l      -      64        0         0.000      0.000      0.000
  

• Then after about 10 minutes, the asterisk was back on 192.168.4.98 which indicates that Client is started to sync with the NTP Server.

Why did the asterisk show next to LOCAL(0) in between, before it went back to the NTP Server IP address?

Answer 1

Your examples are not quite accurate ntpq output, and all appear to be exactly the same apart from the * tally code, which suggests they are edited from the same query rather than actual examples from the time when these things happened. So I can only assume what happened based on your description of the process.

The general answer to your question is: NTP will stop using a source if it has reason to believe it is serving incorrect time.

When you changed the date on your NTP server (presumably by more than 1 second), your NTP client would have noticed this as a large jump in time on the part of the NTP server. So the source 192.168.4.98 had changed a lot, while the LOCAL(0) source on the client had changed by a more predictable amount. So ntpd on your client would have marked 192.168.4.98 as bad, then taken a short while to decide on a new source and selected LOCAL(0). After the NTP server had been serving stable time for a while, the client would have switched back, since the LOCAL(0) source was not synchronized to anything, and 192.168.4.98 was a lower stratum.

Your overall configuration is poor and you're doing a number of things which are against best practice:

1. Using the deprecated LOCAL driver rather than getting time from a good reference clock
2. Using only one time source

NTP is not designed to operate in isolation. Eventually, all time must come from an authoritative stratum 0 source. Most people get their time from the NTP pool, which uses a selection of different sources (but often GPS). By using the LOCAL driver, you are at the mercy of however badly your local clock oscillator works (spoiler: usually pretty badly).

You can probably get roughly the behaviour you want for testing by removing the LOCAL driver from your NTP client. But don't do this if you care about time accuracy. Have a read of the NTP Best Current Practices, the NTP documentation, or my blog series to learn more about good NTP configuration.