Coordination second (leap second) - what it is and how to lay straws
As already mentioned on Habré , on June 30, 2012, a second of coordination will be entered.
If you are wondering what it is and what kind of trouble can cause - welcome under cat.
Unfortunately, our world is designed so that the angular velocity of the Earth’s rotation is not constant. Worse, the derivative of this velocity is not constant. From this follow two unpleasant conclusions:
To compensate for the difference between universal time (UTC) and mean solar time (UT1), a second coordination (leap second) is entered . The coordination second is entered at the end of the day, UT on June 30 or December 31, so that the UTC time does not differ from UT1 by more than ± 0.9 seconds. It is believed that on such days after the time of 23:59:59 it is 23:59:60 or after 11:59:58 the next second is 00:00:00.
Since the adjustment cannot be carried out on any regular basis, the adjustment of the off-line clock is carried out manually. In the case of clocks with external synchronization, the adjustment can be performed automatically, based on data received from an external source.
Most services and time networks provide information about the upcoming second coordination, for example, GPS. NTP also provides this information. I will dwell on it in more detail.
The NTP server can learn about the upcoming second of synchronization in three ways:
Having obtained information on the upcoming second of coordination by any of these methods, and with the onset of the day to which this second relates, the server sets the corresponding value of the internal variable, informs the OS kernel and starts informing its clients accordingly.
The NTP datagram provides a two-bit field for the announcement of the second coordination. Usually both bits are set to zero. Setting one of the bits to one means that a positive or negative second of coordination will be entered at the end of the day (in some cases, both bits can be set to one, which means that for one reason or another the server cannot provide the exact time).
According to the results of the survey of NTP servers, a vote is taken, on the basis of which the client sets the appropriate value for the internal variable, informs the OS kernel about the upcoming coordination second and starts informing its customers accordingly.
It would seem quite logical and workable scheme, but rakes are possible.
Rakes are usually caused by incorrect configuration of primary servers, when the server knows nothing about the upcoming second of coordination and learns about it at best after the fact. An example of this is the behavior of ntp-servers of VNIIFTRI (National Metrology Institute of Russia) on January 1, 2009 . There may also be exotic cases when a server that does not fully support NTP is wedged into the synchronization chain, or a firewall that incorrectly “cleans up” packets.
Stratum 1 server errors are most often encountered when a GPS or GLONASS receiver with NMEA protocol is used as the reference source, which transmits information only about the coordination second that has already arrived. So, if you are the owner of the Stratum 1 server and are not sure that the driver of your reference source will be able to transmit the necessary information, please “feed” to your leapfile server.
Checking the correctness of the server configuration in the case of ntpd is quite simple. Give the ntpq -c rv command. You will get approximately the following result:
')
If you see leapsec = 201207010000 , then your server is properly configured and uses an adequate leapfile. If you execute the same command on June 30, then the leap_none in the first line should change to leap_add_sec . You can make sure that everything is in order by analyzing your NTP traffic on June 30. For example, tcpdump with the -v option successfully parses the NTP packets and shows the above-mentioned announcement bits in a readable form.
Separately, I want to note the behavior of operating systems. If Linux, FreeBSD and most modern UNIX-like operating systems correctly handle a second of coordination, then this will be a surprise for Windows. At some point in time, the Windows Time Service will detect that the OS time is different for about a second. Whether Windows will compensate for this difference gradually, slowing down (speeding up) the system clock, or jerk - depends on the MaxAllowedPhaseOffset parameter. In this case, we can recommend the administrator to determine which compensation scenario will cause the least damage and set this parameter accordingly.
If you are wondering what it is and what kind of trouble can cause - welcome under cat.
Coordination second (leap second)
Unfortunately, our world is designed so that the angular velocity of the Earth’s rotation is not constant. Worse, the derivative of this velocity is not constant. From this follow two unpleasant conclusions:
- no matter how much time is chosen as the standard of a second, after a while there will be a difference between our time scale and solar time, which needs to be corrected;
- no adjustment is possible on a regular basis.
To compensate for the difference between universal time (UTC) and mean solar time (UT1), a second coordination (leap second) is entered . The coordination second is entered at the end of the day, UT on June 30 or December 31, so that the UTC time does not differ from UT1 by more than ± 0.9 seconds. It is believed that on such days after the time of 23:59:59 it is 23:59:60 or after 11:59:58 the next second is 00:00:00.
Since the adjustment cannot be carried out on any regular basis, the adjustment of the off-line clock is carried out manually. In the case of clocks with external synchronization, the adjustment can be performed automatically, based on data received from an external source.
Dissemination of information about the upcoming second coordination
Most services and time networks provide information about the upcoming second coordination, for example, GPS. NTP also provides this information. I will dwell on it in more detail.
The NTP server can learn about the upcoming second of synchronization in three ways:
- information can be set manually (in the case of ntpd, this is done using the leapfile file, which contains information about all seconds of synchronization, and the leapfile directive);
- through information from the driver of the reference time source;
- through the NTP protocol.
Having obtained information on the upcoming second of coordination by any of these methods, and with the onset of the day to which this second relates, the server sets the corresponding value of the internal variable, informs the OS kernel and starts informing its clients accordingly.
The NTP datagram provides a two-bit field for the announcement of the second coordination. Usually both bits are set to zero. Setting one of the bits to one means that a positive or negative second of coordination will be entered at the end of the day (in some cases, both bits can be set to one, which means that for one reason or another the server cannot provide the exact time).
According to the results of the survey of NTP servers, a vote is taken, on the basis of which the client sets the appropriate value for the internal variable, informs the OS kernel about the upcoming coordination second and starts informing its customers accordingly.
It would seem quite logical and workable scheme, but rakes are possible.
Rake
Rakes are usually caused by incorrect configuration of primary servers, when the server knows nothing about the upcoming second of coordination and learns about it at best after the fact. An example of this is the behavior of ntp-servers of VNIIFTRI (National Metrology Institute of Russia) on January 1, 2009 . There may also be exotic cases when a server that does not fully support NTP is wedged into the synchronization chain, or a firewall that incorrectly “cleans up” packets.
Stratum 1 server errors are most often encountered when a GPS or GLONASS receiver with NMEA protocol is used as the reference source, which transmits information only about the coordination second that has already arrived. So, if you are the owner of the Stratum 1 server and are not sure that the driver of your reference source will be able to transmit the necessary information, please “feed” to your leapfile server.
Checking the correctness of the server configuration in the case of ntpd is quite simple. Give the ntpq -c rv command. You will get approximately the following result:
')
associd = 0 status = 0419 leap_none, sync_uhf_radio, 1 event, leap_armed, version = "ntpd 4.2.6p5@1.2349-o Wed Jun 13 10:36:21 UTC 2012 (1)", processor = "x86_64", system = "Linux / 3.2.20", leap = 00, stratum = 1, precision = -22, rootdelay = 0.000, rootdisp = 0.002, refid = GPS, reftime = d3856e94.2052bbf0 Fri, Jun 15 2012 15: 19: 32.126, clock = d3856e97.6bdc8f80 Fri, Jun 15 2012 15: 19: 35.421, peer = 48525, tc = 3, mintc = 3, offset = 0.001, frequency = 23.641, sys_jitter = 0.000, clk_jitter = 0.000, clk_wander = 0.001, tai = 34, leapsec = 201207010000, expire = 201212280000
If you see leapsec = 201207010000 , then your server is properly configured and uses an adequate leapfile. If you execute the same command on June 30, then the leap_none in the first line should change to leap_add_sec . You can make sure that everything is in order by analyzing your NTP traffic on June 30. For example, tcpdump with the -v option successfully parses the NTP packets and shows the above-mentioned announcement bits in a readable form.
Separately, I want to note the behavior of operating systems. If Linux, FreeBSD and most modern UNIX-like operating systems correctly handle a second of coordination, then this will be a surprise for Windows. At some point in time, the Windows Time Service will detect that the OS time is different for about a second. Whether Windows will compensate for this difference gradually, slowing down (speeding up) the system clock, or jerk - depends on the MaxAllowedPhaseOffset parameter. In this case, we can recommend the administrator to determine which compensation scenario will cause the least damage and set this parameter accordingly.
Source: https://habr.com/ru/post/146047/
All Articles