NTP stratum-1 on Ubuntu 14.04LTS

Some (incomplete) notes on setting up a stratum-1 NTP server on Ubuntu 14.04LTS

To handle the upcoming leap-second we want a leapfile, from: http://www.ietf.org/timezones/data/leap-seconds.list

The path of the leapfile goes into /etc/ntp.conf
leapfile /etc/leap-seconds.list
But Ubuntu uses apparmor, so we must grant permission for the ntp service to read this file in /etc/apparmor.d/usr.sbin.ntpd by adding:
/etc/leap-seconds.list r,
To make apparmor parse and apply the new rules we do:
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.ntpd
when the ntp service starts it is useful to look at /var/log/syslog where ntp will complain if it doesn't have permission to read the leapfile or if it is badly formatted.

Now let's edit the default options for the ntp service in /etc/default/ntp by adding:
NTPD_OPTS='-gN'
(-N runs ntpd at highest priority, -g makes it more robust agaist large time offsets, see man ntpd)

To get time in NMEA-format and a pulse-per-second (PPS) from gpsd we add two shared-memory (type 28) refclock drivers to /etc/ntp.conf

# GPS Serial data reference
server 127.127.28.0 maxpoll 3
fudge 127.127.28.0 time1 -0.230 refid GPS

# GPS PPS reference
server 127.127.28.1 prefer maxpoll 2
fudge 127.127.28.1 refid PPS

(the time1 adjustment number needs to be calibrated somehow..).

Finally we let ntp distribute time to the outside world by adding this line to /etc/ntp.conf (this is usually at the end of the file).
restrict default noquery

Now let's set up gpsd. The service configuration file is /etc/default/gpsd, and as suggested in the file we edit it with the utility:
sudo dpkg-reconfigure gpsd
The options that worked for me are device /dev/ttyS0 and options -n (don't wait for clients to connect). After running the utility /etc/default/gpsd should look something like:

START_DEAMON="true"
GPSD_OPTIONS="-n"
DEVICES="/dev/ttyS0"
USBAUTO="false"
GPSD_SOCKET="/var/run/gpsd.sock"

You can verify that gpsd is working with cgps, xgps, or gpsmon.

This should result in Ubuntu automagically starting gpsd and ntpd in the correct order at bootup, and ntpq -p should show something along the lines of:
Screenshot - 06262015 - 10:18:31 AM

If you want to manually restart (or just start or stop) the services, required e.g. after any changes are made to /etc/ntp.conf, it is done with
sudo service ntp restart
sudo service gpsd restart

CONT vs RCON mode on the 53230A frequency counter

This is a follow-up to my earlier notes on the 53230A noise floor.

Naively I did the initial frequency-counting tests using READ?, which is wrong both because it produces data with dead-time and because the consensus for what is meant by Allan deviation assumes pi-counting.

Driven by marketing, no doubt, the 53230A employs internal averaging (something akin to lambda-counting) both with the simple READ? command and the continuous CONT mode mentioned in the manual. Amazingly you have to use the undocumented RCON mode to get pi-counting which will produce correct Allan deviations.

Here is a plot. The opportunity for making errors (with pi- vs. lamda-counting, and gap-free data) is less in time-interval mode, and I have indicated the 12 ps RMS noise floor (1.8e-11/tau in terms of Allan deviation) with a black dashed line. In RCON mode the noise floor has the same 1/tau dependence and I get about 3e-11/tau. If however you simply use the built-in settings of the counter with READ? or CONT you get a noise floor of about 2e-12/sqrt(tau) due to the internal averaging going on behind the scenes.

RCON_vs_CONT

For a paper that explains pi- and lambda-counting see Dawkins2007 (fulltext PDF on ReaserchGate). Enrico Rubiola also has notes on counters.

Datafiles and script for ADEV and figure: 2015-06-18_rcon_cont.zip

Itärastit Paloheinä

Last itärastit event for this spring. See you again in August.

Probably also last orienteering practice before Louna-Jukola next weekend.

2015-06-06_itr_paloheina_qr

#2 found the correct ditch but passed close by the flag before turning around to find it. +2 min.

#9 ran too far along the road and passed close to #4 before turning towards the control.

#15 nothing much wrong but still a bad split. straighter through the green apparently is faster.