A leap second was inserted into the last minute of June 2015. This page contains some information recorded around the leap second. I also recorded some information over the 2005, 2008 and 2012 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.
Below, are the last timecode before the leap and the first timecode after that decoded correctly.
A: 00000000000000000001010100111000001011000000100001001111110 B: 00000000111111100000000000000000000000000000000000000011110 1/7/2015 0:42 Wed -700 DST A: 00000000000000000001010100111000001011000010001001001111110 B: 11100000000000000000000000000000000000000000000000000011010 1/7/2015 2:12 Wed 300 DSTYou can see that the DUT value stepped back by 1000ms.
I still have a working Long Wave software radio setup, thanks to Ian Dowse and Juan Domenech Fernandez. However, the machine it was originally in has died, and unfortunately the new machine seems to generate more radio noise. Using this, I had a go at recording 3 minutes of 896kSPS radio around 23:00, 0:00 and 1:00 UTC. 23:00 is local midnight.
Here are spectrograms for a 10s slice around 23:00, 00:00 and 01:00. These are improved compared to the original spectrograms that I generated, as I've narrowed the frequency range a bit and improved the contrast.
When conditions are good, 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?).
You can see RTE transmitting pips at local midnight in the 23:00 one, and you can also see minute marker in the Rugby signal in the second marked 7. The RTE pips are a few seconds late, which seems to be normal, as the long wave version of the station is a relay of some other version (see my previous attempt to measure this).
Unfortunately conditions have changed an an hour later, and you can't really see the Rugby signal so well. I've improved the contrast a bit compared to my first versions of the spectrogram, and the BBC 4 pips are now reasonably clear. You can see the 6 short pips and one long one, form seconds marked 3 to 9.
By the 01:00 trace, you can still see the modulation on BBC4 (showing 5 short pips and one long) and the DCF 77, however the Rugby signal is still not clear.
I have the raw data, if anyone would like 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. For comparison, you can find a page showing similar graphs for each June/December.
In comparison, this seems like one of the best behaved leap seconds so far - leaps are advertised pretty sharply one day before, and most servers stop advertising the leap just the hour after the leap.
Here's the number of responding servers.
Our Linux machines' kernels logged a message indication the insertion of a leap seconds.
Jul 1 00:59:59 aturing kernel: [3810068.108018] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 boyle kernel: [88516141.252974] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 graves kernel: [5390881.820077] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 gstokes kernel: [3809672.145364] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 hamilton kernel: [3376073.556011] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 holly kernel: [48082979.000059] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 ivy kernel: [1348536.120010] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 maisy kernel: [1349744.216006] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 mojo kernel: [48082755.856345] Clock: inserting leap second 23:59:60 UTC [118848.747324] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 localhost kernel: [1347673.110889] Clock: inserting leap second 23:59:60 UTC Jul 1 00:59:59 zoot kernel: [142203.496093] Clock: inserting leap second 23:59:60 UTC
The load on our NTP server (in packets per minute) looked like this.
Our main ntp server, which acts as a public server, is shown on the left. It appears that 24 hours before the leap second, we started getting a lot more requests (there are also a small increase about 9am the previous morning, but that's me turning up the monitoring). It's not yet clear to me what this is. There is a very small spike in the graph for a secondary NTP server.
Here is the NMEA data received from a Sure GPS unit. There's some weird stuff in the output elsewhere, but this seems to be the secion around the leap.
$GPRMC,235954.000,A,XXXX.XXXX,N,0XXXX.XXXX,W,0.01,303.72,300615,,,D*7D $GPGSA,M,3,10,25,06,01,23,32,09,17,31,,,,1.72,0.90,1.46*0C @$GPGGA,235959.000,XXXX.XXXX,N,0XXXX.XXXX,W,2,9,0.90,17.1,M,54.8,M,0000,0000*7F $GPGSA,M,3,10,25,06,01,23,32,09,17,31,,,,1.71,0.90,1.46*0F @$GPGGA,000000.000,XXXX.XXXX,N,0XXXX.XXXX,W,2,9,0.90,17.0,M,54.8,M,0000,0000*7F $GPGSA,M,3,10,25,06,01,23,32,09,17,31,,,,1.71,0.90,1.46*0F $GPGSV,4,1,13,23,69,122,20,06,51,295,27,09,50,192,31,03,50,082,*72 $GPGSV,4,2,13,17,34,228,32,10,30,265,29,31,17,036,22,01,15,137,19*74 $GPGSV,4,3,13,02,12,307,,32,09,081,16,12,06,317,,25,06,352,18*73 $GPGSV,4,4,13,36,,,*7E $GPRMC,000000.000,A,XXXX.XXXX,N,0XXXX.XXXX,W,0.01,303.72,010715,,,D*72
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 One 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 (570 MHz, vpid 0x0835, apid 0x0899). Arond the leap second, ntp indicated that the machine recording was within tens of ms of UTC, though one of the three NTP servers it was monitoring wandered off (this is my fault).
The purple and green points show the difference between the received timestamp (only includes 1s accuracy) and the timestamp of the machine (to ms accuracy). The cyan and orange lines show rough upper and lower bounds derived by looking at two packets that arrive with the same timestamp. First let's look at the BBC graphs:
There is a jump, just after the leap second. 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, there is a step after 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 somehow leap induced offset. Finally, let's have a look at the RTE graphs.
The RTE graph is very flat in comparison (different update rate?) There is a 1s setp just after 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. When I last heard, 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 vertical 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 512 seconds, you'll get about 500 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), there are several paired spikes (blocks being written just in the wrong 512s interval) and a single spike at the leap. Overall, it looks like the sample rate from the sound card is pretty stable.
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.
Here are some links, found via the LEAPSECs mailing list, the time-nuts mailing list and twitter.
