Leap Second Testing With A Meinberg LANTIME Device

Please be sure you have read the article Leap Second Testing - Introduction before continuing to run a leap second test.

A leap second test with a complex system like a LANTIME can be tricky since beside the GPS receiver there are a number of software modules involved, all of which need to have consistent date, time and status settings.

The necessary steps for the test are described below.

Don't reboot the LANTIME during the leap second test. This would undo some of the changes to be made below.

Simulation mode should be enabled for the GPS receiver during the test to make sure the receiver claims to be synchronized even while the antenna has been disconnected. If the receiver didn't claim to be synchronized, the subsequent software modules wouldn't accept the time, leap second announcement, etc. from the receiver.

The setting can be changed in the web interface on the Clock tab in the Miscellaneous section.

Once the GPS Simulation Mode checkbox has been checked and the changes have been saved, the web interface may ask if you want to save the changes as startup configuration. Just ignore the message and don't click on Save as startup configuration now.

… and also all other potential input time sources.

On the LANTIME the current leap second information is stored in a file /etc/ls_announcement which eventually needs to be edited. This can be done in an SSH session to the LANTIME:

nano /etc/ls_announcement

For the last recent leap second the file should contain the following lines:

#Leap Second Transition Information
Date: 2016-12-31
Leap Seconds BEFORE Transition: 17
Leap Seconds AFTER Transition: 18

This is OK to run a leap second test for 2016-12-31. To run a test for a future leap second date edit the file accordingly, e.g.:

#Leap Second Transition Information
Date: 2019-12-31
Leap Seconds BEFORE Transition: 18
Leap Seconds AFTER Transition: 19

and save the modified file.

By default the LANTIME uses a leap second file for ntpd. If the current version of the file is installed and the leap second test is run using the last recent leap second date then everything should be fine.

However, if the test is run with a future leap second date then the file may still be valid but not contain an entry for the leap second to be tested, which may yield unexpected behavior.

So just to be sure type the following command within an SSH session to the LANTIME to delete the leap second file:

rm /etc/leap_second

The leap second file will be restored when the LANTIME is rebooted after the test.

The system time should be set to at least 30 minutes before the selected leap second date and time.

This can be done in the web interface on the Clock tab in the Initialize Receiver section.

Please note that leap seconds are always inserted at UTC midnight. If the GPS receiver has been configured for a specific local time zone then the time zone offset has to be taken into account when setting the receiver's date and time, so that the UTC time is shortly before UTC midnight.

For example, if you want to set the UTC date and time to 2019-12-31 23:30:00, i.e. 30 minutes before a leap second event, but the selected time zone is CET, i.e. UTC + 1 hour, then you have to enter the date and time 1 hour later, i.e. 2020-01-01 00:30:00.

If the system time is changed significantly the web session may become invalid, so you may have to load the main page of the web interface and eventually log in once more.

Check if the system time shows to the expected date/time.

After the system time has been set go to the SSH session again and run the following commands:

stop softwatch
killall lantimed

The wait 30 seconds and run:

lantimed

This starts the affected services and makes sure the new time and leap second configuration is forwarded to all relevant subsystems.

The LANTIME will then continue counting time across the leap second, and clients should see and report the leap second accordingly.

In the SSH session to the LANTIME you can run:

[root/172.16.14.10] ~ # ntpq -c 'cv &1' | grep timecode
timecode=“\x0201.01.20; 3; 00:28:39; +01:00;     A  ; 51.9824N   9.2258E  179m\x03”,

The highlighted A in the example above is the leap second warning flag, the default value would be a space ' '. See also:

• https://www.meinbergglobal.com/english/specs/unierlan.htm

In the SSH session to the LANTIME you can run:

[root/172.16.14.10] ~ # ntpq -c 'rv 0 leap'
leap=01

Here the leap value 01 indicates that the NTP daemon has accepted the leap second announcement, the default value would be 00.

On a Windows or Linux client you can run the Meinberg ntptest program to send queries to the NTP serever, and see what the server sends back to its clients:

martin@pc-martin:~> ./ntptest -Z lt-martin

ntptest v1.10, © Meinberg 2014-2018, contact: martin.burnicki@meinberg.de

Host lt-martin, running continuously
Initial time offset 18003656.366830319 will be compensated
E1B65B3E.E9D43120  2019-12-31 23:41:50.913394041, st 1, leap 1, offs[ms]: +0.107
E1B65B3F.2A256D86  2019-12-31 23:41:51.164633603, st 1, leap 1, offs[ms]: +0.119
E1B65B3F.6A60062A  2019-12-31 23:41:51.415527711, st 1, leap 1, offs[ms]: +0.064
E1B65B3F.AA9D8ABF  2019-12-31 23:41:51.666466399, st 1, leap 1, offs[ms]: +0.082

Again, the leap 1 indicates an announcement of a leap second to be inserted.

Please note that current versions of ntpd send a leap value 3 for a couple of seconds across the leap second insertion, which is intentional. Then the leap value reverts to 0.

In the example here, the ntptest program has just been used to monitor the NTP server from a normal Linux workstation. The workstation's time was not synchronized to the NTP server under test, so you can see that the time offset increases when the leap second is inserted:

E1B65F7D.DD416D67  2019-12-31 23:59:57.864279592, st 1, leap 1, offs[ms]: +0.075
E1B65F7E.1D7DB212  2019-12-31 23:59:58.115199212, st 1, leap 1, offs[ms]: +0.079
E1B65F7E.5DBF55A0  2019-12-31 23:59:58.366200782, st 1, leap 1, offs[ms]: +0.066
E1B65F7E.9DFCD45A  2019-12-31 23:59:58.617139121, st 1, leap 3, offs[ms]: +0.092
E1B65F7E.DE818D63  2019-12-31 23:59:58.869164311, st 1, leap 3, offs[ms]: +0.072
E1B65F7F.1EBBB41B  2019-12-31 23:59:59.120051628, st 1, leap 3, offs[ms]: +0.092
E1B65F7F.5EF14AE0  2019-12-31 23:59:59.370869331, st 1, leap 3, offs[ms]: +0.085
E1B65F7F.9F282DCC  2019-12-31 23:59:59.621706831, st 1, leap 3, offs[ms]: +0.020
E1B65F7F.DF6C3B85  2019-12-31 23:59:59.872745246, st 1, leap 3, offs[ms]: +0.055
E1B65F7F.1FA1F918  2019-12-31 23:59:59.123565262, st 1, leap 3, offs[ms]: -999.924
E1B65F7F.5FDC43B0  2019-12-31 23:59:59.374454718, st 1, leap 3, offs[ms]: -999.903
E1B65F7F.A0118D83  2019-12-31 23:59:59.625267834, st 1, leap 3, offs[ms]: -999.900
E1B65F7F.E048D1EF  2019-12-31 23:59:59.876111145, st 1, leap 3, offs[ms]: -999.922
E1B65F80.208F133F  2020-01-01 00:00:00.127183153, st 1, leap 3, offs[ms]: -999.900
E1B65F80.60CACC7E  2020-01-01 00:00:00.378094464, st 1, leap 3, offs[ms]: -999.910
E1B65F80.A10314B1  2020-01-01 00:00:00.628953259, st 1, leap 0, offs[ms]: -999.912
E1B65F80.E142BFA5  2020-01-01 00:00:00.879924752, st 1, leap 0, offs[ms]: -999.950
E1B65F81.2189EDA3  2020-01-01 00:00:01.131010868, st 1, leap 0, offs[ms]: -999.924
E1B65F81.61CE2FEC  2020-01-01 00:00:01.382052416, st 1, leap 0, offs[ms]: -999.906

Please note that client software on other machines or devices may not accept the huge time step at the beginning of the leap second test at all, or only after a significant delay. So eventually client services also need to be restarted after the beginning of the test.

Once the leap second test has finished:

1. The LANTIME's system time should be set to the real current date.
2. Simulation mode should be disabled.
3. The device should be rebooted or power cycled to make sure all subsystems are initialized with current, valid settings.
4. Finally the antenna should be reconnected, as well as other time sources that have been disconnected during preparation of the test.

— Martin Burnicki martin.burnicki@meinberg.de 2019-06-06