r4 - 2006-03-26 - 03:57:41 - HarlanStennYou are here: NTP >  Support Web > ConfiguringNTP > ConfiguringRefclocks > ConfiguringPPSWithPARSERefclocks
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.

ntp-4.2.8p10 was released on 21 March 2017. It addresses 6 medium- and 5 low-severity security issues, 4 informational security topics, 15 bugfixes, and contains other improvements over 4.2.8p9.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
REFACTOR See ConfiguringPPSWithPARSERefclocksDev for discussion of this topic.

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

6.1.14.1. 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.]

6.1.14.2. 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

6.1.14.3. 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 work directory that config.h does define HAVE_TIMEPPS_H, 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)

6.1.14.4. 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
server 127.127.22.0 
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

BEWARE - 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 158.152.1.204    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.

Note: 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

-- DavidHutchinson - 10 Jan 2005

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r4 < r3 < r2 < r1 | More topic actions
 
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback