|
|
1 |
(% class="row" %) |
|
|
2 |
((( |
|
|
3 |
(% class="col-xs-12 col-sm-8 test-report-content" %) |
|
|
4 |
((( |
|
|
5 |
---- |
|
|
6 |
|
|
|
7 |
The International Earth Rotation and Reference Systems Service (IERS) intends to eliminate the concept of leap seconds, including negative leap seconds, by 2035. |
|
|
8 |
As the name implies, a negative leap second is the opposite of a positive leap second. In a positive leap second, an extra second is inserted; for example, instead of the time changing from 23:59:59 to 00:00:00, it goes from 23:59:59 to 23:59:60 and then to 00:00:00. By contrast, during a negative leap second, one second is omitted, so the time jumps from 23:59:58 to 00:00:00. |
|
|
9 |
The purpose of this adjustment is to synchronize Coordinated Universal Time (UTC) with Universal Time (UT1), which is based on the Earth's rotation. |
|
|
10 |
So far, there has never been a documented instance of a negative leap second. However, since the IERS has not yet finalized the change, the possibility of a negative leap second remains until 2035. |
|
|
11 |
Because only positive leap seconds have occurred up to this point, the effects of a negative leap second on various computer systems and networks are still unknown. |
|
|
12 |
Our aim was to verify whether a time-synchronized network using Telecom Boundary Clocks (T-BCs) and Precision Time Protocol (PTP) would properly process a negative leap second and correctly propagate the leap second information downstream. |
|
|
13 |
PTP operates based on Temps Atomique International (TAI, or International Atomic Time) and is therefore not directly affected by leap seconds, as they affect only UTC, not TAI. Therefore, our test focused on whether all relevant flags in the Announce messages were correctly set and cleared as T-BCs handled the negative leap second. |
|
|
14 |
|
|
|
15 |
[[~[~[Figure 98: Class D T-BC holdover chain with negative leap second - Test bed setup~>~>image:487694060027445249_neg_leap_sec.png~|~|alt="Figure 98"~]~]>>attach:487694060027445249_neg_leap_sec.png||target="_blank"]] |
|
|
16 |
|
|
|
17 |
For this test, we prepared a setup using an emulated Telecom Grandmaster (T-GM), the Calnex Paragon neo, which was also capturing the announce messages at the end of the chain, followed by seven Telecom Boundary Clocks, each connected to the Keysight Time Sync Analyzer to capture the announce messages. |
|
|
18 |
The T-GM was manipulating the time to 31st of December, 23:40:00, right before a leap second event, and sending announce messages with the leap59 flag set to true, which is required to announce a negative leap second, and UTC Offset being set to 37. |
|
|
19 |
Once the time reached 23:55:00, we disconnected the link between the T-GM and T-BC-1, causing the whole chain to enter holdover; this was done to see how the nodes behave and process the announce message flags once the negative leap second occurs; If this were not done, the T-GM would process the information of the negative leap second, set leap59 to false and set UTC Offset to 36 by itself; every following T-BC would then simply receive and forward the announce message, which would not show whether they processed it properly themselves. |
|
|
20 |
Once the leap second event happened, so time jumped from 23:59:58 to 00:00:00, all T-BCs showed that leap59 was set to false and that UTC Offset had been set to 36, the correct expected behaviour, as verified using the Calnex Paragon neo and the Keysight Time Sync Analyzer. |
|
|
21 |
|
|
|
22 |
{{container cssClass="tc-role-table"}} |
|
|
23 |
(% class="table-bordered" %) |
|
|
24 |
|=Telecom Grandmaster|=Telecom Boundary Clocks|=Frequency/Phase Analyzers |
|
|
25 |
|Calnex Paragon neo|Ericsson RAN Connect 6682, |
|
|
26 |
Microchip Time Provider 4500, |
|
|
27 |
ZTE ZXR10 M6000-2S16, |
|
|
28 |
HPE PTX10002-60MR, |
|
|
29 |
Cisco 8011-4G24Y4H-I, |
|
|
30 |
Ciena 8192|Calnex Paragon neo, |
|
|
31 |
Keysight Time Sync Analyzer |
|
|
32 |
|
|
|
33 |
{{/container}} |
|
|
34 |
|
|
|
35 |
(% id="prev-next-links" %) |
|
|
36 |
|[[< Previous>>doc:PTP Performance Monitoring]]|[[Next ~>>>doc:ITU-T G\.8275\.2 Packet Forwarding]] |
|
|
37 |
))) |
|
|
38 |
|
|
|
39 |
(% class="col-xs-12 col-sm-4 test-report-sidebar" %) |
|
|
40 |
((( |
|
|
41 |
{{box}} |
|
|
42 |
{{include reference="Main.EANTC Transport & Cloud Networks Interop Test Report 2026.Sidebar Nav"/}} |
|
|
43 |
{{/box}} |
|
|
44 |
))) |
|
|
45 |
))) |