NTPD
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 127.127.28.0 and the PPS at 127.127.28.2. 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 127.127.28.0 and the uBlox PPS server is at address 172.127.28.2.
To collect statistics,
- Create the directory /var/log/ntpstats with owner ntp and group ntp.
- 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.
/etc/default/ntpd
This file enables ntpd at boot time and controls the relationship between ntpd and gpsd.
NTPD_ENABLED=1 # 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. GPSD_REQUIRED=1 # Number of seconds between testing for a GPS # lock prior to calling ntpd. GPSD_WAIT_TIME=120 # 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. SET_SYSTEM_CLOCK=1
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.
Turn off GPSD and Use NTP with LoRa 2.1 (MTDCTIP-PHP)
GPSD does not work with LoRa 2.1, which has GPS built into the LoRa cards. Use NTP instead.
1. To do this, edit the file /etc/ntp.conf by adding the # symbol to comment out lines involving the GPSD server IP address 127.127.28.*
# GPS Serial data reference (NTP0) # This sets the GPS 50 milliseconds slower than the PPS. #server 127.127.28.0 true #fudge 127.127.28.0 time1 0.050 refid GPS # GPS PPS reference (NTP2) #server 127.127.28.2 prefer true #fudge 127.127.28.2 time1 0.000 refid PPS
2. Configure NTP to use a network server or pool of ntp servers. In this example, we set a single server IP address. Add the following new line to the file above the commented section and save:
server 192.168.2.249 iburst
3. After these changes are made, restart the ntp server using this command:
$ sudo /etc/init.d/ntpd restart
4. Verify the ntp server is connected. Enter the command:
$ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *192.168.2.249 204.9.54.119 2 u 23 64 377 0.363 3.500 2.584 LOCAL(0) .LOCL. 14 l 494 32 0 0.000 0.000 0.000
The times in the last three columns are in milliseconds. The * indicates the preferred server.
For more information see:
http://doc.ntp.org/4.2.8p9/confopt.html
and for systems with Internet access:
http://www.pool.ntp.org/en/use.html