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.8p13
was released on 07 March 2019. It addresses 1 medium-severity security issue in ntpd, and provides 17 non-security bugfixes and 1 other improvements over 4.2.8p12.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
See ConfiguringJupiterRefclocksDev for discussion of this topic.
6.1.8. Configuring Jupiter Refclock with linux
This driver is only valid for Jupiter GPS Modules that support the Rockwell/Conexant/Navman binary interface (up to the model 12 modules). The newer models seem to have switched to the
SiRF / NMEA protocols.
I have a working setup with linux-2.4.21-NANO and a Jupiter GPS receiver.
Here is the orginal
Refclock Jupiter documentation.
These notes are for these versions. They assume you have already patched the kernel with PPSkit, compiled and installed a working NANO-kernel.
- linux-2.4.21.tar.gz
- PPSkit-2.1.4.tar.gz
- ntp-stable-2.4.0a-20040617.tar.gz
To enable kernel PPS disipline you need edit one line in refclock_jupiter.c. See diff below
@@ -232,5 +232,5 @@
#ifdef HAVE_PPSAPI
instance->assert = 1;
- instance->hardpps = 0;
+ instance->hardpps = 1; // Enable kernel PPS dicipline
/*
* Start the PPSAPI interface if it is there. Default to use
Note that there seems to be a patch floating around that fixes the
hardpps
issue.
NTP builds
refclock_jupiter
by default, if the necessary bits are found.
Jupiter specific lines from my ntp.conf
# Jupiter binary mode
server 127.127.31.0 prefer #
fudge 127.127.31.0 time1 0.00 #
fudge 127.127.31.0 flag3 1 # I use the nonstandard edge on the PPS signal
With the 62euro kit from
GPSKIT, I get quite good
performance.
# ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
+ntp1.sth.netnod .PPS. 1 u 40 512 377 12.084 0.442 0.337
+ntp2.sth.netnod .PPS. 1 u 47 512 377 12.006 0.415 0.299
-ntp1.mmo.netnod .PPS. 1 u 67 512 377 20.919 -0.222 0.264
-ntp2.mmo.netnod .PPS. 1 u 44 512 377 20.808 -0.263 0.217
+ntp1.sp.se .PPS. 1 u 32 512 377 17.369 0.084 0.199
+ntp2.sp.se .PPS. 1 u 43 512 377 17.131 0.002 0.263
*GPS_JUPITER(0) .GPS. 0 l 14 64 377 0.000 0.000 0.001
# ntptime
ntp_gettime() returns code 0 (OK)
time c4a80538.8eb6f164 Tue, Jul 20 2004 22:55:20.557, (.557479878),
maximum error 2934 us, estimated error 0 us, TAI offset -1073743080
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset -0.023 us, frequency 37.670 ppm, interval 32 s,
maximum error 2934 us, estimated error 0 us,
status 0x2107 (PLL,PPSFREQ,PPSTIME,PPSSIGNAL,NANO),
time constant 7, precision 1.788 us, tolerance 496 ppm,
pps frequency 37.670 ppm, stability 0.144 ppm, jitter 0.405 us,
intervals 1751, jitter exceeded 3449, stability exceeded 44, errors 21.
In the output from 'ntptime' you can look at the status line. When everything
has settled down the status should look like it does in the above output.
It is also possible to have a Jupiter GPS receiver output NMEA messages.
However, this is not recommended, since the receiver outputs NMEA when everything else is done. They can be either 1+ seconds late or 2+ seconds late (it can vary based on time / day). Since there is no way the NMEA message can reliably tell what second a PPS edge belongs to, this GPS receiver is unusable for precision timing in NMEA mode.
--
BjornGabrielsson - 20 Jul 2004
Related Topics: JupiterRefclockUsers