A leap second was inserted into the last minute of June 2012. This page contains some information recorded around the leap second. I also recorded some information over the 2005 and 2008 Leap Seconds. I have some more raw data to process, which I will I will add as I finish it.
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.
I still have a working Lown Wave software radio setup, thanks to Ian Dowse and Juan Domenech Fernandez. Using this, I had a go at recording 6 minutes of 896kSPS radio around the leap second. Please contact me for the raw data, if you want it.
Things are quite clear in this spectrogram. The leap second is roughly between t=6s and t=7s on the x-axis. If you zoom in, from bottom to top, you can first see the MSF ("Rugby") signal to 60kHz with each second beginning with an 0.1s off period, and the new minute beginning with a 0.5s off period. Next, a similar signal can be seen at 77.5kHz (DCF signal from Frankfurt). Further up, there are AM radio stations that can be seen broadcasting pips at 162kHz (France Inter), 177kHz (Deutschlandradio), 198kHz (BBC Radio 4), 207kHz (could be Iceland or Germany?) - look for short bars on either side of the frequency. Unfortunately RTE do not broadcast pips at 1AM.
The MSF, DCF and BBC4 signals seem quite well lined up. The others are not particularly closely lined up, and look like being a mix of late and early - I'll have to inspect some other spectrograms to see if they are usually late, early or otherwise. There is a fade in the France Inter carrier just after their long pip, and it looks like it switches to a digital mode about 5s off the edge of the spectrogram.
It should be possible to decode the phase modulated signal on BBC Radio 4 and Inter France so see what time the transmitting station thiks it is.
There is also some "fuzz" around 100kHz, which might be the LORAN signal?
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. For comparison, I also show the same graph for 2008.
Note, that things look better than in 2008 - a smaller number of servers seem to have continuted to advertise the leap after it occured. This maybe due to improvements in the NTP algorithm which decides if the leap bits should be set.
Here's the number of responding servers. The jump in the number of pool server just before the 2012 leap second is me adding some extra pool servers to the list. I've shown 2008 for comparison.
Our Linux machines' kernels logged a message indication the insertion of a leap seconds.
Jul 1 00:59:59 aturing kernel: [3812251.350269] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 boyle kernel: [17919532.602233] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 gstokes kernel: [1478186.532861] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 hamilton2 kernel: [3249552.719500] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 holly kernel: [202854.050568] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 turing kernel: Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 zoot kernel: [100262.733845] Clock: inserting leap second 23:59:60 UTCOn an older FreeBSD machine, we saw some "microtime went backwards" messages. These are usually harmless and indicate that process accounting noticed that something funny happened.
Jul 1 00:59:59 hamilton /kernel: microuptime() went backwards (54909097.537454 -> 54909096.557135) Jul 1 00:59:59 hamilton /kernel: microuptime() went backwards (54909097.537454 -> 54909096.558586) Jul 1 00:59:59 hamilton /kernel: microuptime() went backwards (54909097.537454 -> 54909096.559044) Jul 1 00:59:59 hamilton /kernel: microuptime() went backwards (54909097.537454 -> 54909096.559554) Jul 1 00:59:59 hamilton /kernel: microuptime() went backwards (54909097.537454 -> 54909096.560173) Jul 1 00:59:59 hamilton /kernel: microuptime() went backwards (54909097.537454 -> 54909096.560542)
On one other machine, I was just using ntpdate to step the clock once an hour. To it, the leap second looked like this.
30 Jun 17:03:02 ntpdate[23901]: adjust time server 62.77.173.117 offset 0.125893 sec 30 Jun 18:03:02 ntpdate[25014]: adjust time server 62.77.173.117 offset 0.125380 sec 30 Jun 19:03:02 ntpdate[26161]: adjust time server 62.77.173.117 offset 0.125402 sec 30 Jun 20:03:02 ntpdate[27360]: adjust time server 62.77.173.117 offset 0.125432 sec 30 Jun 21:03:02 ntpdate[28499]: adjust time server 62.77.173.117 offset 0.124737 sec 30 Jun 22:03:02 ntpdate[29710]: adjust time server 62.77.173.117 offset 0.124795 sec 30 Jun 23:03:02 ntpdate[30817]: adjust time server 62.77.173.117 offset 0.123953 sec 1 Jul 00:03:03 ntpdate[31919]: adjust time server 62.77.173.117 offset 0.123585 sec 1 Jul 01:03:02 ntpdate[576]: step time server 62.77.173.117 offset -0.876739 sec 1 Jul 02:03:02 ntpdate[1692]: adjust time server 62.77.173.117 offset 0.183461 sec 1 Jul 03:03:02 ntpdate[2898]: adjust time server 62.77.173.117 offset 0.119632 sec 1 Jul 04:03:03 ntpdate[3998]: adjust time server 62.77.173.117 offset 0.122774 sec 1 Jul 05:03:02 ntpdate[5104]: adjust time server 62.77.173.117 offset 0.121191 sec 1 Jul 06:03:02 ntpdate[6198]: adjust time server 62.77.173.117 offset 0.121230 sec
The load on our NTP server (in packets per minute) looked like this.
You can see a peak in requests about 1AM, corresponding to the leap.
DVB transmits some timing information (in PID 20), but timestamps only come to one second precision, and often seem to be late. I had a go at recording the timing packets that arrived when a DVB-S card was tuned to BBC 1 NI (Astra2 10817 MHz V, vpid 0x15e0, apid 0x15e1, sid 0x2879), WDR Aachen (Astra 12603 MHz H, vpid 0x0d49, apid 0x0d4a, sid 0x6f76) and when a DVB-T card was tuned to RTE 1 (738 MHz, vpid 0x044d, apid 0x04b1). During the measurements, ntp indicated that the machine recording was within tens of ms of UTC.
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). The blue and purple lines show rough upper and lower bounds derived by looking at two packets that arrive with the same timestamp. Fitst let's look at the BBC graphs:
There is a glitch just before the leap second, a jump at it, and something that looks like a reset a while after. Since the bounds and the points jump, it looks like the the leap second may not have been accounted for. Zooming out a bit, we see the following.
So, we see there is a spike at the leap, but there are other spikes, so it's possible this is a non-leap related spike. Now, let's look at the WDR graph:
Again, a step at the leap, but also one while before and one a while after. However, if we look over a longer timescale.
It seems likely that this was a leap induced offset. Finally, let's have a look at the RTE graphs.
The RTE graph is very flat, but the offset is much bigger (around 20s rather than 0). The flatness might indicate that the point at which timing packets are sent does not vary much within from second to second. There is a 1s setp at the leap. Again, zooming out.
Again, while there are other steps, it looks more likely than not that the leap caused the offset.
The mains in Ireland is usually maintained at about 50Hz. When I last asked, they aimed to keep it between 49.9 and 50.1Hz over roughly 5s periods, and aim to keep the number of cycles correct over long periods. The Rugby signal used to be the benchmark against which the mains was measured.
To test what the mains did over the leap, I built a small loop of wire and connected it to the mic connector on a sound card. I left the loop near some power cables, in the hope it would pick up some mains hum. I then processed this in 60s chunks to look for a peak in the amplitude of the Fourier Transform between 49 and 51Hz.
The results are shown above, with one point per 60s worth of samples, horizontal lines showing 49.9Hz and 50.1Hz and the leap shown with a verticle line. There is a dip in frequency around the leap, but it's quite possible that this is just normal variation, as it isn't the lowest the frequency reaches.
Of course, one concern is that the sample rate of the sound card may be varying, and contributing to the variability in the mains. While this data was being recorded, I noted how fast samples were being written to the disk against the system clock, which was controlled by NTP. Unfortunately, this is quantised to disk blocks, which aren't quite the same size as the 8000*16bit samples per second being recorded. However, if you smooth over about 256 seconds, you'll get about 250 8KB blocks being written every interval, and you can look for variations.
This is plotted on the same relative scale as the graph above, and it looks much smoother. The notable steps are at the start (which I think is some jitter due to initialisation), at the leap second (because 257 seconds worth of samples were accumulated, even though 256 elapsed on the system clock) and a two steps after the leap second (details not so important). Overall, it looks like the sample rate from the sound card is pretty stable, though maybe marginally under 8000 SPS.
Finally, it's probably worth checking that the amplitude of the peak that we consider to be the mains is relatively constant. Since the loop is just picking up mains hum from the air, it's possible I'm just picking up noise. It seems it is relatively constant.
I also manually checked 60s windows, the Fourier Transform is quite sharply peaked in this range, suggesting there is only one significant peak to find.
