NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38. See ConfiguringPPSWithPARSERefclocksDev for discussion of this topic.
ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
6.1.14. Configuring PPS With PARSE Refclocks
There seems to be a slight lack of worked examples of using the PPS facility in ntp, so I'll document my (working) system. (If you aren't happy compiling and patching kernels yet, then this may not be for you - sorry :-) )
Some of this probably applies to other receivers and other Linux variants - please add your experiences
188.8.131.52. The equipment
Receiver is the old Trimble SV6, a GPS which emits TSIP format serial data, and the 1 PPS signal. NTP machine is Gentoo on AMD Athlon, running the 2.6.9 kernel, and ntp 4.2.0. Receiver is interfaced to the RS-232 port, via level translators, with the 1 PPS wired to the DCD input. The receiver must be configured for TSIP output (require s Trimble software under DOS)
[Aside - this is a Trimble designed for navigation, not timekeeping. The TSIP message is variably aligned relative to the second boundaries, the PPS signal is not, hence we use both. Timekeeping Trimbles use a different strategy, the ntp server raises a signal line to the receiver, which timestamps the transition against its local clock, and then reports the timestamp at its leisure.
For best accuracy, use the Trimble DOS software to set the GPS mode to 'static' - maximum position and time filtering for stationary use.]
184.108.40.206. Building the kernel support
To use PPS, you need
- To get the PPS kit - for the 2.6 kernel this is the PPSkit-light. I'm using PPSkit-light-PPSAPI-alpha-1610m-2.6.5.diff.bz2, from ftp.kernel.org
- Apply the patch, (there's one reject, but it edits in easily)
- Switch on PPSAPI in config (under serial devices). There's a debug flag too, but don't leave it on - too much output. I have 8250 and serial_core (and ppsdev) as modules
- Build and install modules
- Assuming your GPS is on /dev/ttySx, then ln -s /dev/refclock-0 and /dev/pps0 to /dev/ttySx
- I know it's naughty, but ntp needs access to a kernel header. Without it, it builds, but PPS silently doesn't work.
ln -s /usr/src/linux/include/linux/timepps.h /usr/include
220.127.116.11. Building NTP
The clocks you need
are PARSE and ATOM, and if you build ntp by hand just use configure to select these. Under Gentoo you don't easily get such fine control over configure, so
USE="parse_clocks" emerge ntp
Check in the resulting
directory that config.h does define
, and you should have an ntpd with the right clocks in it. (You need to set emerge to preserve compilation files for the directory to survive, otherwise run emerge in shell in emacs, and read the configure output there)
18.104.22.168. Configuring NTP
You have two refclocks - this isn't enough! You need three to get a majority decision. (See David Mills' pages on www.ntp.org for the full reasons). I have another machine which gets an ntp feed from the internet over an intermittent ISDN connection. (Without a third clock, you may get PPS to work, especially with time1 set correctly, but any disturbance may cause refclock switching. The third clock doesn't need to be very good)
Here is the server part of ntp.conf
# to break the ambiguity, use server slaved to demon
server 192.168.69.12 iburst
#the gps TSIP feed
server 127.127.8.0 mode 10 prefer iburst
fudge 127.127.8.0 refid TSIP time1 0.042
# the gps PPS
fudge 127.127.22.0 refid PPS0
Notes on ntp.conf
- mode 10 sets TSIP as the parse clock input format. prefer is essential, and tells ntp to use this clock to dis-ambiguate the 1 pps second boundaries
- the time1 parameter will vary by GPS - it tells ntp the average error between each TSIP message and the true time. Not necessary at first, but helps prevent refclock swapping. The ntpd
calibrate command can be used to help find your correct value. Note this value is in seconds, errors in ntpq are in milliseconds, in ntpdc in seconds
- the iburst's are not necessary, I think they speed up initial convergence
- the default in dhcpcd (if you use it) is to overwrite ntp.conf on boot! Make a copy of any working ntp.conf, and add the -N flag to dhcpcd (in /etc/conf.d/net for Gentoo)
What you see when it's working
ntpq -c peers
remote refid st t when poll reach delay offset jitter
xnews.burrowmate 22.214.171.124 3 u 44 64 377 0.269 -13.035 0.026
+GENERIC(0) .TSIP. 0 l 10 64 377 0.000 -4.653 7.059
oPPS(0) .PPS0. 0 l 60 64 377 0.000 -0.126 0.013
The key information is the first char on each line (the 'tally code' in ntpq manpage-speak). oPPS says we're using the PPS, and +GENERIC says the TSIP is the supporting peer. Your third clock may be x or +, x says currently too far from truechiming.
The PPS device is not immediately reachable, on my system it takes a few minutes before PPS 'wakes up'. In this period the system should firstly reset to the TSIP time (if needed), and then lock to it. Watch the PPS reach field (in octal), and you should eventually see 1, 3, 7, ... After a while, ntpd should switch to the PPS, as its jitter should be much lower than the RS-232 serial TSIP messages
With the PPS debug on in the kernel, you get lots of output in syslog. Without it, you still get
check_modem_status: status=0x88, pp=dd0398e0
or similar once per second (at KERN.DEBUG, so your syslog may not record it unless you set it too).
The cv command in ntpq lets you clock variables, used on the TSIP clock you get to see satellites in view, and your location too. Great to confirm the GPS has seen the sky if it has no display (as SV6 does't)
Hope this helps - sorry for ugly formatting - not a qualified wiki driver
- 10 Jan 2005