Есть. Но обычно используется версия без учета високосных секундах. В противном случае получится, что система у вас идет не по UTC, а по TAI. Что несколько идет в разрез с POSIX и рушит всю арифметику, основанную на том, что в сутках 86400. Когда я проводил подобный эксперимент, первое, что было замечено, это съехавшие даты в mysql.
Кстати, 30 минут может быть мало. Вполне типичный интервал опроса 1024 с + дефолтный stepout timeout 900 c дают 1924 c, что несколько больше получаса.
Кроме того, скрипты обычно ставят на исполнение по локальному времени, а leap second привязана с 00:00 по UTC.
Кстати, в статье я не стал упоминать еще один способ распространения файлов leapfile между ntpd.
В случае, если у вас настроена autokey авторизация, то leapfile передается клиенту. Возможно в ntpd просто переиспользовали использовали механизм передачи открытого ключа для передачи leapfile.
Нет. Так как в прямых системах и софте обычно используют время UTC, которое не меняется при переходе на зимнее время/летнее время, а в часовые пояса используются лишь для интерфейса с человеком.
Я использовал Garmin GPS 18x LVC. Разница LVC от PC и USB в том, что в LVC выведен PPS.
Плюсы: Относительно дешевый. Простота подключения (честные уровни RS-232).
Минусы: Большой jitter (~100 мс), если использовать только NMEA без PSS. Нет возможности принудительно зафиксировать координаты — это полезно в случае плохой видимости спутников — с зафиксированными координатами приемник теоретически может отдавать точное время и при видимости только одного спутника.
Хорошо если вы можете быть так же уверены и в стороннем софте, что в какой-то момент он не скажет что-нибудь типа: «обнаружен файл из будущего, дохну». Кстати, в ряде случаев это может быть вполне оправданное поведение.
В некотором плане вы правы и для корректно спроектированных систем это не критично.
Но если в течение этого часа в вашей сети произойдет какой-либо инцидент, то даже 1 секунда разницы может добавить работы при его расследование.
В случае же, если компенсация происходит рывком, а в случае с ntpd с дефолтными настройками (step 0.128) так и будет, возможны неприятности с повторным запуском на исполнение того, что не надо. Например, запуск криво сделанного скрипта для импорта данных в какой-нибудь варехауз.
Не совсем. Вы можете попробовать убедиться, что ваш клиент использует корректно сконфигурированные серверы. Например, если два сервера ответят, что коррекции не будет, а один, что будет — ваш клиент будет считать, что коррекции не будет.
Как убедится — зависит от конкретного софта. В случае канонического ntp будут полезны ntpq -c rv, ntpdc -c kern, ntptime. Универсальный способ проверки — анализ пакетов NTP от серверов к вашему клиенту 30 июня 2012 UTC.
Кроме того, скрипты обычно ставят на исполнение по локальному времени, а leap second привязана с 00:00 по UTC.
В случае, если у вас настроена autokey авторизация, то leapfile передается клиенту. Возможно в ntpd просто переиспользовали использовали механизм передачи открытого ключа для передачи leapfile.
Плюсы: Относительно дешевый. Простота подключения (честные уровни RS-232).
Минусы: Большой jitter (~100 мс), если использовать только NMEA без PSS. Нет возможности принудительно зафиксировать координаты — это полезно в случае плохой видимости спутников — с зафиксированными координатами приемник теоретически может отдавать точное время и при видимости только одного спутника.
Но если в течение этого часа в вашей сети произойдет какой-либо инцидент, то даже 1 секунда разницы может добавить работы при его расследование.
В случае же, если компенсация происходит рывком, а в случае с ntpd с дефолтными настройками (step 0.128) так и будет, возможны неприятности с повторным запуском на исполнение того, что не надо. Например, запуск криво сделанного скрипта для импорта данных в какой-нибудь варехауз.
Как убедится — зависит от конкретного софта. В случае канонического ntp будут полезны ntpq -c rv, ntpdc -c kern, ntptime. Универсальный способ проверки — анализ пакетов NTP от серверов к вашему клиенту 30 июня 2012 UTC.