NTPD Overview

NTPD is a program that provides time as a service.  Time is input to NTPD from a GPS, the local system clock, or an external NTP server.  NTPD adjusts the system clock and hardware clock to match the external time source.  The program ranks GPS as the top priority source.

This program can be used in conjunction with the GPS (if this capability is included in your device) to provide accurate times for the device or a network attached to the device via Internet Protocol. If GPS or an external NTP server is not available, NTP continues using the local time. NTP is the network time protocol. Refer to the figure called NTPD using GPS Time.

GPSD communicates with NTPD via shared memory to provide the GPS time. If the GPS cannot acquire a satellite fix (possibly the system is indoors, or has no antenna)  NTPD never starts and the default configuration continues where it uses local time.  The NTPD server is delayed to prevent NTP from serving an incorrect time.

If there is a GPS fix,  NTPD starts and creates a virtual local time service for the GPS at and the PPS at   GPSD first sets the system clock to the GPS time and then the NTPD one shot time update (ntpd -gq) guarantees smooth operation when NTPD first starts as a daemon. Then, NTPD does subsequent and periodic minor adjustments of the local time (both hardware and system clock) to synchronize it with the GPS time. NPTD normally avoids huge corrections or adjustments to the system clock.

By default, the GPS receiver is configured in /etc/ntp.conf with the value of true.  This prevents NTPD from eliminating the GPS from consideration as a falseticker.

If NTP detects too many anomalies between the GPS and the system clock, the GPS may be ignored by NTP if the “true” flag is not set.  The falseticker flag may be set if the GPS antenna signal strength is poor, or the CPU on the device is overloaded, causing poor interrupt servicing.  If the GPS is a falseticker, leap seconds from the GPS will be ignored, and the system clock will not be kept in sync with the GPS.

Relationship to GPSD

GPSD has code to interpret uBlox binary strings. This is less CPU intensive than using the ASCII NMEA strings.

NOTE: Do not start NTPD before the GPS has acquired a fix. NTPD immediately uses the GPS if the system time is less than a second from the GPS time. If the GPS time is not close to the system time (a second or more off), NTPD labels the GPS a falseticker and does not use the GPS for setting the system time.

The hardware clock on the device is not of sufficient accuracy to use it alone to set the system time and then expect NTPD to switch to the GPS later. Instead, GPS must acquire a fix, next the system time sets to the GPS, and then NTPD can start.

If the GPS antenna is inadequate or cannot detect a signal and the device is configured to use the GPS for the NTPD timebase, NTPD may never start.

NTP configuration file

This configuration file /etc/ntp.conf is used to configure ntp and has several functions including it defines clock sources, and it restricts access to the clock from other systems on the network. The file also specifies the minimum and maximum poll times of clock sources.

The uBlox GPS server is at address and the uBlox PPS server is at address

To collect statistics,

  1. Create the directory /var/log/ntpstats with owner ntp and group ntp.
  2. Uncomment the statistics, statdir, and filegen lines and restart ntpd to start recording statistics.

For more information on ntpd: NTPD Documentation

Restarting after changing the configuration

To restart after changing the configuration file, enter the following command:

mtcdt: /etc/init.d/ntpd restart

Verification with NTPQ

Waiting till GPS fix

Wait until after the GPS has a 3D fix and the system is configured to set the system clock from the GPS. If you do so, the following results display:


mtcdt: ntpq -p
remote           refid           st t    when   poll   reach       delay   offset     jitter
*SHM(0)          .GPS.            0  l    42     64      1         0.000    3.525      0.004
 SHM(2)          .PPS.            0  l    42     64      1         0.000    2.821      0.004
 LOCAL(0)        LOCL.           14  l   106     64      2         0.000    0.000      0.004

After several minutes NTP should switch to using the PPS:


mtcdt: ntpq -p
  remote           refid    st  t when       poll  reach      delay   offset    jitter
   +SHM(0)          .GPS.    0  l    7       64      3        0.000    3.734    0.209
   *SHM(2)          .PPS.    0  l    7       64      3        0.000    2.858    0.037
  LOCAL(0)         .LOCL.   14  l  135       64      4        0.000    0.000    0.004

* = this source is being used for the clock.
+ = this source is is an alternative clock.
x = this source is not used for clock (i.e. the system has a problem with it).

SHM indicates that shared memory is being used to synchronize the clock. refid shows the type of clock source either GPS, PPS or local.

Jitter is the measured variation in the clock relative to the system clock. The offset is the offset from the system clock. If you do not see this after ten minutes or so, check your antenna connection. You can view the reception of each satellite with gpsmon.

t is the type of source like local, unicast, multicast and broadcast. l is local. Delay, offset, and jitter are expressed in milliseconds. Reach is in bits. When and poll are in seconds. St is strata which evaluates the accuracy of the time source on a scale of 0-16 where 0 is the best (such as an atomic clock) and 16 is the worst (such as a local hardware clock).

NTP started before GPS fix

Do not start NTP before the GPS has a fix. In this case, the system clock is set by the hardware clock. If you do so, the following results display:


mtcdt: ntpq -p
remote           refid      st   t     when      poll    reach   delay     offset  jitter
xSHM(0)          .GPS.       0   l      40        64      377    0.000    1495.346  2.620
xSHM(2)          .PPS.       0   l      38        64      377    0.000    1498.024  0.005
*LOCAL(0)       .LOCL.      14   l      39        64        1    0.000       0.000  0.004

Because the GPS time is 1.5 seconds from the system clock, the system marks the GPS as a falseticker and NTP prefers the local clock. The asterisk next to LOCAL indicates that NTPD is using the local clock, which is not optimal.


This file enables ntpd at boot time and controls the relationship between ntpd and gpsd.


# The GPSD_* parameters in this file are ignored
# if the uBlox GPS is not present.

# Require a GPS lock/fix before starting NTP
# This is needed if we are not using NTP servers.
# NTP will not work with the GPS if  the GPS is not
# locked before starting.
# See /etc/default/gpsd for the states required.

# Number of seconds between testing for a GPS
# lock prior to calling ntpd.

# Since the HW Clock could be off by a second or
# so, our GPS might get marked as a false ticker
# if we do not set the system clock to the GPS
# first.  The current correct way to do this
# according to the ntp doc is ntpd -gq -c conffile
# which must be done before ntpd is started.
# conffile should exclude the local clock, so it is
# ignored while doing the initial sync.
# ntpd -gq apparently does not work with the GPS
# when tested with the clock more than one day off
# and no ntpd.  The gps shared memory is never polled.

# If there is a uBlox GPS present, the time is
# read from the GPS to initialize the system time
# before NTP is started.


If NTP time synchronization is based on a GPS, GPSD_REQUIRED causes NTPD to wait until GPSD determines that the GPS has a lock. If there is no antenna, NTPD may never start when this flag is set.

GPSD_WAIT_TIME specifies a delay between testing to see if the GPS is ready.

NTPD should not start before the system clock is close to UTC. SET_SYSTEM_CLOCK ensures that the system clock is correct before starting NTP. NTP will not adjust the system clock if it is too far from UTC time.