r1 - 2005-10-31 - 14:56:50 - MauroFiaccoYou are here: NTP >  Support Web > ConfiguringNTP > ConfiguringRefclocks > ConfiguringPPSWithUnsynchronisedRubidiumSource
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.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.

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 ConfiguringPPSWithUnsynchronisedRubidiumSourceDev for discussion of this topic.

Bad topic ConfiguringPPSWithUnsynchronisedRubidiumSource

In the specific case of the author, a high quality Rubidium frequency source was employed by RF engineers as a stable 10MHz signal for improving stability of various RF equipment. In order to provide my PCs with a stable PPS signal, we built a simple counter using standard TTL logic (4 of 74HC390) and amplified the signal for using as input to the serial port.

The result is a very stable PPS signal, however each pulse is not synchronised and there is no indication of which second it represents. Follows is a description on how to use this PPS signal for creating a stable and accurate NTP server.

It was decided to employ a PC running a standard freeBSD 5.4. The kernel was recompiled (see the excellent freeBSD handbook at URL: https://www.freebsd.org/) with the following option:

option       PPS_SYNC
As the PPS signal is received on the serial port, the following link was made:
ln -s /dev/cuaa0 /dev/pps

The NTP code was ported using

-- MauroFiacco - 31 Oct 2005

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: 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-2021 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