Leap Second Testing With A Meinberg GPS/GNSS PCI Card
Please be sure you have read the article Leap Second Testing - Introduction before continuing to run a leap second test.
Preparations
Running a leap second test when no leap second is actually announced means that the UTC / leap second parameter set on the device has to be modified to announce a fake leap second.
The antenna should be disconnected during the test to make sure the fake leap second announcement is not overwritten when the satellites sent the real current parameter set.
Setting the leap second information on the PCI card
As explained in the introduction, a leap second is announced if the 2 UTC offset values in the UTC parameter set differ.
A pre-release version of the mbgctrl utility can be used to set a fake leap second announcement on the PCI card.
The program versions shipped with current release versions of mbgtools don't support this, yet,
so please contact Meinberg to get a copy of the pre-release version.
The mbgstatus program can be run
display the current leap second information, e.g.:
mbgstatus -vvv mbgstatus v4.2.6 copyright Meinberg 2001-2019 GPS180PEX 029511008290 (FW 2.48, ASIC 8.06) at port 0xBE00, irq 18 … … UTC correction parameters: CSUM: 14FC, valid: 0001 t0t: 2059|319488.0000000, A0: 0 A1: 2.66454e-15 WNlsf: 2185, DN: 7, offs: 18/18 Last leap second eventually at UTC midnight at the end of Sat, 2021-11-27
Please note the leap second week number is transmitted as 8 bit value only, so the full week number is ambiguous if the real leap second date is 128 weeks or more in the future or past. Since the last leap second was scheduled for 2016-12-31, this is currently more than 128 weeks in the past, and thus the leap second date is not displayed correctly anymore, and is labeled eventually.
One of the following commands can be run to set a fake leap second announcement:
mbgctrl FAKELEAP= # set leap second announcement for 2016-12-31 mbgctrl FAKELEAP= # set leap second announcement for 2019-06-30 mbgctrl FAKELEAP= # set leap second announcement for 2016-12-31
Afterwards the mbgstatus program can be run once more to check the changed settings, e.g.:
mbgstatus -vvv mbgstatus v4.2.6 copyright Meinberg 2001-2019 GPS180PEX 029511008290 (FW 2.48, ASIC 8.06) at port 0xBE00, irq 18 … … UTC correction parameters: CSUM: 14FC, valid: 0001 t0t: 2059|319488.0000000, A0: 0 A1: 2.66454e-15 WNlsf: 1929, DN: 7, offs: 17/18 GPS/UTC offset transition from 17s to 18s due to leap second insertion at UTC midnight at the end of Sat, 2016-12-31.
So in the example here the card has a valid leap second announcement for 2016-12-31 24:00:00.
Setting the PCI card's date and time
The PCI card outputs a leap second announcement during a specific interval before the leap second occurs. In GPS180PEX firmare 2.48 the announcement interval has been changed to 23 hours before the leap second event time, but for different PCI card models or earlier firmware versions the announcement interval was only 59 minutes.
So depending on whether only the leap second itself, or also the beginning of the leap second announcement are to be tested, the card's on-board date has to be set matching the leap second date, and the time has to an appropriate interval before the leap second event:
mbgctrl DATE=2016-12-31 TIME=00:55:00 # little more than 23 hours before leap second mbgctrl DATE=2016-12-31 TIME=22:55:00 # little more than 1 hour before leap second mbgctrl DATE=2016-12-31 TIME=23:45:00 # 15 minutes before the leap second
Monitoring the leap second status
The command
mbghrtime -u 250000 -vvv | tee -a mbghrtime.log
reads and displays the card's date, time and status four times per second, and also logs the output to a file so that can be inspected later.
The status bits labeled st: are described here:
At the beginning of a 23 hour leap second announcement the status changes from 0x0014 to 0x0034, which means the leap second is being announced:
HR time raw: 0x5867030F.24DBB249, 2016-12-31 00:59:59.1439773 UTC (+250227.8 us), st: 0x0014, sig: 128, latency: 5.5 us HR time raw: 0x5867030F.64E96F07, 2016-12-31 00:59:59.3941869 UTC (+250209.6 us), st: 0x0014, sig: 128, latency: 7.5 us HR time raw: 0x5867030F.A6FDBCB2, 2016-12-31 00:59:59.6523092 UTC (+258122.3 us), st: 0x0014, sig: 128, latency: 7.0 us HR time raw: 0x5867030F.E70D20BB, 2016-12-31 00:59:59.9025440 UTC (+250234.8 us), st: 0x0014, sig: 128, latency: 7.1 us HR time raw: 0x58670310.271C7494, 2016-12-31 01:00:00.1527779 UTC (+250233.9 us), st: 0x0034, sig: 128, latency: 7.4 us HR time raw: 0x58670310.672B973B, 2016-12-31 01:00:00.4030088 UTC (+250230.9 us), st: 0x0034, sig: 128, latency: 7.3 us HR time raw: 0x58670310.A73AB6B1, 2016-12-31 01:00:00.6532396 UTC (+250230.8 us), st: 0x0034, sig: 128, latency: 6.9 us HR time raw: 0x58670310.E747C782, 2016-12-31 01:00:00.9034390 UTC (+250199.4 us), st: 0x0034, sig: 128, latency: 8.0 us
When the leap second actually occurs then the status changes from 0x0034 to 0x0114 during the leap second,
and back to the normal 0x0014 after the leap second:
HR time raw: 0x5868467F.0F9F9DDB, 2016-12-31 23:59:59.0610293 UTC (+250234.8 us), st: 0x0034, sig: 128, latency: 7.2 us HR time raw: 0x5868467F.4FAEBC86, 2016-12-31 23:59:59.3112600 UTC (+250230.7 us), st: 0x0034, sig: 128, latency: 7.1 us HR time raw: 0x5868467F.8FBCA33D, 2016-12-31 23:59:59.5614721 UTC (+250212.1 us), st: 0x0034, sig: 128, latency: 7.4 us HR time raw: 0x5868467F.D40F7BDD, 2016-12-31 23:59:59.8283612 UTC (+266889.1 us), st: 0x0034, sig: 128, latency: 7.7 us HR time raw: 0x5868467F.141EE511, 2016-12-31 23:59:59.0785964 UTC (-749764.8 us), st: 0x0114, sig: 128, latency: 7.2 us HR time raw: 0x5868467F.542D371A, 2016-12-31 23:59:59.3288149 UTC (+250218.5 us), st: 0x0114, sig: 128, latency: 7.7 us HR time raw: 0x5868467F.943CB952, 2016-12-31 23:59:59.5790515 UTC (+250236.6 us), st: 0x0114, sig: 128, latency: 7.4 us HR time raw: 0x5868467F.D44C179B, 2016-12-31 23:59:59.8292860 UTC (+250234.5 us), st: 0x0114, sig: 128, latency: 7.8 us HR time raw: 0x58684680.145B43B5, 2017-01-01 00:00:00.0795175 UTC (+250231.5 us), st: 0x0014, sig: 128, latency: 7.0 us HR time raw: 0x58684680.546BB633, 2017-01-01 00:00:00.3297685 UTC (+250251.0 us), st: 0x0014, sig: 128, latency: 7.9 us HR time raw: 0x58684680.947B51E6, 2017-01-01 00:00:00.5800067 UTC (+250238.2 us), st: 0x0014, sig: 128, latency: 8.3 us HR time raw: 0x58684680.D4E9300F, 2017-01-01 00:00:00.8316831 UTC (+251676.4 us), st: 0x0014, sig: 128, latency: 7.2 us
Passing the leap second announcement to 'ntpd'
On Linux, the
mbgsvcd
daemon is used to pass the date, time and status of the PCI card to the NTP daemon, ntpd.
Since the antenna has been disconnected for the test, the card's status is unsynchronized,
so ntpd would normally not accept the time from the card.
To avoid this, mbgsvcd has to be run with the -p parameter to let the daemon pretend that the card is synchronized, even if it is not.
To first kill the running daemon, and then start it again, run these commands as root:
killall mbgctrl mbgctrl -p
After the date on the PCI card has changed, and the mbgsvcd daemon has been restarted, ntpd should be restarted as well.
Please keep in mind that this will change the system time of your computer to the leap second date!
After the test
Once the test has finished, you should set the PCI card's date back to the current date, and afterwards connect the antenna to let the card synchronize to the current time.
— Martin Burnicki martin.burnicki@meinberg.de 2019-06-25
127.0.0.1