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 ConfiguringJupiterRefclocksDev 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.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.
To enable kernel PPS disipline you need edit one line in refclock_jupiter.c. See diff below
@@ -232,5 +232,5 @@
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
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
# 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
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.
- 20 Jul 2004
Related Topics: JupiterRefclockUsers