A leap second was inserted into the last minute of 2008. This page contains some information recorded around the leap second. I also recorded some information over the 2005 Leap Second.
I have a Rugby Radio wired to the DCD pin on a serial port, so I can record if the signal is on or off. Each minute of the signal begins with a 0.5 second on/0.5 second off period. The following graph shows the beginning of each minute around the start of the year.
Note that the minutes before the new year began 61, 121 and 181 seconds before the new year, indicating that the last minute had an extra second. The full minute of each signal can be seen here.
Note that the next minute marker is visible at the right hand side of the graph (at second 61) for all the signals but the third from the bottom. Unfortunately, I managed to miss the signal during the extra second, because my script was too eager to drop duplicate data!
With Ian Dowse's help, we also reproduced Juan Domenech Fernandez's homebrew SDR setup. Using this, I had a go at recording 10 minutes of 896kSPS radio around the leap second.
This seems to have worked OK. To make a start, I've AM demodulated the Rugby (MSF) signal (10MB) and the German DCF signal (10MB). This isn't a very sensible thing to do, as the signal shouldn't be audible when demodulated in this way. However, listen for the buzzing that goes on and off once a second, and that's the signal. The new year begins about 5m29.1s in.
Things are a little clearer in this spectrogram. The red line on the far left is a combination of the Rugby signal and something else. Just below the first tick marking 5m29s, this line gets thinner for about half a second - the top of this thin period is the minute marker for the start of the new year. Follow across to see BBC 4 broadcast Big Ben at 198kHz and the spoken count down on RTE at 252kHz.
If anyone is interested, I have the full ~1GB wav file. Drop me a note if you want it.
NTP warns of impending leap seconds using two bits: 00 means no leap second, 01 means we are adding a leap second, 10 means we are removing a leap second and 11 means the server is unsynchronised.
The NTP project maintains a list of public time servers at stratum 1 and stratum 2. I also made a list of servers included in various NTP Pool servers. Some of these servers will respond when asked for the value of the leap bits. The following is a graph of the proportion of (responding) NTP servers with various values of the leap bits. The vertical line shows when the leap second should have been inserted.
We see that the proportion of stratum 1 servers increased at the start of the month and then again in the last few day or so of the month. The proportion of stratum 2 or pool servers advertising the leap is higher. There's a drop in the number immediately after the leap and it's still falling a few days into January. The next graph shows what's happening in the days around the leap.
The points on the line are actually after the leap (measurements were usually taken between five past and twenty past the hour). For reference, the number of servers responding was roughly constant throughout the measurements and is shown below.
Our Linux machines' kernels logged a message indication the insertion of a leap seconds.
Dec 31 23:59:59 graham kernel: Clock: inserting leap second 23:59:60 UTC Dec 31 23:59:59 stokes kernel: Clock: inserting leap second 23:59:60 UTCOn some older FreeBSD 4.11 machines, we got some "microtime went backwards" messages. These are usually harmless and indicate that accounting though something funny happened.
Dec 31 23:59:59 bell /kernel: microuptime() went backwards (9092743.386339 -> 9092742.416307) Dec 31 23:59:59 bell /kernel: microuptime() went backwards (9092743.386339 -> 9092742.418603) Dec 31 23:59:59 bell /kernel: microuptime() went backwards (9092743.386339 -> 9092742.446321) Dec 31 23:59:59 bell /kernel: microuptime() went backwards (9092743.386339 -> 9092742.447052)
The load on our NTP server (in packets per minute) looked like this.
The extra load starting on Tuesday is just the extra monitoring involved in producing the NTP peer plots below. The extra load starting around midnight we're not sure about. One of our local peers in the NTP pool saw a busy end of year too.
There are some graphs of what a number of our NTP peers did. The behavior was similar to 2005, where I wrote some brief explanation of the sort of thing that we saw.
DVB does transmit some timing information, but timestamps only come to one second precision, and usually seem to be late anyway. None the less, I had a go at recording the timing packets that arrived when a DVB-S card was tuned to BBC 1 NI and when a DVB-T card was tuned to RTE 1. During the measurements, ntp indicated that the machine recording was within tens of ms of UTC.
The BBC send two timing packets roughly twice a minute. The exact time seems to wander within the second the packet is received. The red and green points show the difference between the received timestamp (only includes 1s accuracy) and the timestamp of the machine (to ms accuracy). We can see that they jump about every 500s, which just represents them slipping over a second boundary. There's also one bad looking data point.
While there is a jump almost at midnight, it looks like part of the regular behaviour. The blue and purple lines show rough upper and lower bounds derived by looking at two packets that arrive with the same timestamp. It's easy enough to imagine a line running between the blue and purple, which doesn't have zero slope/offset, but doesn't have any kinks.
A longer term look at the offsets looks like this. This possibly indicates that something funny is happening actually for about 30000s before the leap.
RTE send timing information more frequently - two packets every second and sometimes more frequently. Again, the red and green show the raw offsets, and the blue and purple show upper and lower bounds.
This time it seems fairly certain that there was a step in offset at the leap. The bounds immediately before don't overlap with the bounds afterwards. The weird looking behaviour afterwards is actually a change in the spacing between the packets, which can be seen at other times too.
Over a long time scale, the offsets for RTE look like this. The jump in the offsets is quite clear over the leap, and things seem to return to normal over the following hours.