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:
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:
— Martin Burnicki martin.burnicki@meinberg.de 2019-06-06