Leap second Dec 2005

I had 3 machines collecting data over the leap second at the end of 2005.

hgm is a 566 MHz PC running NetBSD 3.0 and a recent ntp-dev.

glypnod is a 566 MHz PC running an old RH 7.2 with a Linux 2.4.16-NANO kernel and ntp 4.2.0@1.1161-r.

shuksan is a 2800 MHz PC running a vanilla Fedora Core 4 system using a Linux 2.6.14 kernel (no PPS support) and a recent ntp-dev.

All 3 machines are connected to a HP Z3801A. hgm and glypnod generally keep good time. shuksan doesn't have PPS support in the kernal so it doesn't do as well.

glypnod also watches several external servers. It got confused when some of them didn't do the leap-dance. I made things worse by trying to work around a non-existant bug by changing the config file and restarting ntpd.

hgm also watches glypnod. It did OK until glypnod got confused.

gettimeofday vs TSC

Markus Kuhn wrote a program to log the time returned by gettimeofday and the value of the TSC counter. The TSC runs off the CPU clock so it doesn't know anything about leap seconds.

hgm stalled the clock for a second starting at 00:00:00.5.
glypnod and shuksan set the clock back 1 second at 23:59:60.
shuksan was observed in 00:00 for one sample before it was set back.

Here are a few samples of the raw data around the interesting times: hgm, glypnod, shuksan.

Here is a graph. The lines are offset slightly so they don't overlap and hide eachother.

GPS clocks

I have 2 NMEA GPS clocks, a GPSClock 200 and a Garmin 18-LVC. Both were setup to transmit only a GPRMC message each second. I wrote a hack to log each line and the time it arrived. I copied NTP's clockstats format. The data was collected on hgm.

As documented, the Garmin 18-LVC transmitted a duplicate second at 00:00:00. The sample with a half second offset corresponds to hgm being half way through the flat second in the graph above. The GPSClock 200 had a duplicate second at 23:59:51. Raw data: Garmin, GPSClock 200.

Here is a graph. Note the X axis is gettimeofday time so a second in the middle is scrunched together.

Statistics from ntpd/loopstats

Here are graphs from ntp's loopstats files. Looks like it took about 4 hours for the leap transient to die out.

Here are the same graphs zoomed in:

GPS clock position accuracy

As long as I was collecting data from NMEA GPS clocks for the leap second, I plotted the position they reported. Both units are located indoors, next to eachother on top of a window in my junk room.

The signal quality at that location is marginal. The blue ticks along the bottom are samples where the unit reported that it didn't have a good answer. The Garmin had 0.7% bad samples. The GPSClock 200 had 3.7% bad samples.

The origin was calibrated by eye.