Как уже упоминалась на Хабре, 30 июня 2012 г. будет внесена секунда координации.
Если вам интересно, что это такое и какие неприятности может вызвать — добро пожаловать под кат.
Секунда координации (leap second)
К сожалению, наш мир устроен так, что угловая скорость вращения Земли не постоянна. Хуже того, не постоянна и производная этой скорости. Из этого следуют два несколько неприятных вывода:
- какой бы отрезок времени не был бы выбран в качестве эталона секунды, через некоторое время обнаружится разница между нашей шкалой времени и солнечным временем, которую необходимо скорректировать;
- корректировку невозможно осуществлять на какой-либо регулярной основе.
Для компенсации разницы между всемирном координированном временем (UTC) и средним солнечным временем (UT1) вводят секунду координации (leap second). Секунду координации вводят в конце суток по всемирному времени 30 июня или 31 декабря так, чтобы время UTC не отличалось от UT1 более, чем на ±0,9 секунды. Считается, что в такие дни после времени 23:59:59 идёт 23:59:60 или же после 23:59:58 следующая секунда будет 00:00:00.
Так как корректировку невозможно осуществлять на какой-либо регулярной основе, корректировка автономных часов осуществляется вручную. В случае же часов с внешней синхронизацией корректировка может быть выполнена автоматически, на основе данных, полученных от внешнего источника.
Распространение информации о предстоящей секунды координации
Большинство служб и сетей точного времени предоставляют информацию о предстоящей секунде координации, например, GPS. Протокол NTP тоже предоставляет данную информацию. На нем я и остановлюсь поподробнее.
NTP-сервер может узнать о предстоящей секунде синхронизации тремя путями:
- информация может быть задана вручную (в случае ntpd это делается при помощи файла leapfile, который содержит сведения о всех секундах синхронизации, и директивы leapfile);
- посредством информации от драйвера эталонного источника времени;
- посредством протокола NTP.
Получив любым из этих способов информацию о предстоящей секунде координации, и с наступлением суток, к которым эта секунда относится, сервер устанавливает соответствующее значение внутренней переменной, информирует ядро ОС и начинает соответствующим образом информировать своих клиентов.
В датаграмме протокола NTP предусмотрено двухбитное поле для анонса секунды координации. Обычно оба бита установлены в ноль. Установка одного из битов в единицу означает, что в конце суток будет введена положительная или же отрицательная секунда координации (в ряде случаев оба бита могут быть установлены в единицу, что означает, что по тем или иным причинам сервер не может предоставить точное время).
По результатам опроса NTP серверов проводится голосование, на основании которого клиент устанавливает соответствующее значение внутренней переменной, информирует ядро ОС о предстоящей секунде координации и начинает соответствующим образом информировать своих клиентов.
Казалось бы вполне логичная и работоспособная схема, но, возможны грабли.
Грабли
Грабли обычно вызваны неправильной конфигурацией первичных серверов, когда сервер ничего не знает о предстоящей секунде координации и узнает о ней в лучшем случае постфактум. Примером тому поведение ntp-серверов ВНИИФТРИ (национального метрологического института России) 1 января 2009 года. Так же могут быть экзотические случаи, когда в цепочку синхронизации вклинивается сервер, не полностью поддерживающий NTP, или фаервол, некорректно «зачищающий» пакеты.
Ошибки Stratum 1 серверов наиболее часто встречаются, когда в качестве эталонного источника используется приемник GPS или ГЛОНАСC с протоколом NMEA, который передаёт информацию только об уже наступившей координационной секунде. Так что, если вы являетесь владельцем сервера Stratum 1 и не уверены в том, что драйвер вашего эталонного источника сможет передать нужную информацию, пожалуйста, «скормите» вашему серверу leapfile.
Проверить корректность конфигурации сервера в случае ntpd достаточно просто. Дайте команду ntpq -c rv. Вы получите приблизительно такой результат:
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
Если вы видите leapsec=201207010000, значит ваш сервер правильно настроен и использует адекватный leapfile. Если выполнить такую же команду 30 июня, то leap_none в первой строке должно измениться на leap_add_sec. Убедиться, что все в порядке, можно и анализируя ваш NTP-трафик 30 июня. Например, tcpdump с опцией -v успешно парсит пакеты NTP и показывает упомянутые выше биты анонса в читаемом виде.
Отдельно хочется отметить поведение операционных систем. Если Linux, FreeBSD и большинство современных UNIX-like операционных систем корректно обрабатывают секунду координации, то для Windows это будет сюрпризом. В какой-то момент времени Windows Time Service обнаружит, что время ОС отличается где-то на секунду. Будет ли Windows компенсировать эту разницу постепенно, замедляя (ускоряя) ход системных часов, или же рывком — зависит от параметра MaxAllowedPhaseOffset. В данном случае можно рекомендовать администратору определить, какой сценарий компенсации нанесет наименьший урон и задать данный параметр соответствующим образом.
Автор: timothyz
