Писал статью предполагая, что наиболее вероятный сценарий — «прощелканная клювом» секунда координации. И вот обнаружился Stratum 1 сервер, который наоборот анонсирует секунду координации слишком заранее (уже несколько дней) — Time2.Stupi.SE.
Рекомендую воздержаться от его использования, так как в ряде случаев при использовании старых версий ntpd (например, 4.2.4p5) это может приводить к ложной секунде координации.
Хмм, из статьи следует, что нормируется сопротивление именно заземляющего устройства. Мне почему-то всегда казалось, что должно нормироваться сопротивление заземляющего устройства и проводника земли заземляемой сети. То есть, что для любой точки заземляемой сети сопротивление заземления не должно превышать Х Ом.
Вот эта компенсация пинга и дает ошибку при постоянной асимметрии роутинга. Для простоты арифметики представим, что у нас есть две машины с идеальными часами. В момент t одна машина шлет другой пакет. Допустим, он идет 30 мс. В момент t+30 мс вторая машина получает этот пакет, помещает в него свой таймштамп (t+30) и отсылает обратно. И тут вдруг пакет идет по более длинному маршруту уже за 70 мс. Таким образом первая машина получает ответ на свой запрос в t+100. Так как никаких данных как и с какой скоростью шел пакет, машина предполагает, что путь туда и обратно занимал одинаковое время, следовательно, вторая машина поместила свой таймштамп в t+50. В таймстампе при этом t+30 и первая машина считает, что ее часы бегут на 20 мс. А так как такое происходит всегда, эту ошибку нельзя выявить какими-либо статистическими методами.
Вы правы. В протоколе нет такой возможности. Из наблюдений, ~20 мс наблюдается между ростелекомом и остальным рунетом. Это стало одной из причин, по которой доступ к моему Stratum 1 серверу предоставляется только после предварительной договоренности.
P.S. официальные российские ntp-сервера работают через Ростелеком.
Я бы предположил, что в конфиге была директива tos orphan на случай, чтобы часы внутри сети не шли в разнобой при потере внешнего канала. А когда по какой-то причине внешний источник «потерялся» насовсем, машины в сети стали синхронизировать время с системным временем одного из серверов. Если бы не Orphan Mode, то был бы еще и цирк с разным временем на машинах внутри сети.
Собственно, с полночью это не ко мне. Я как раз в разговоре с вами и с еще одним человеком до вас упорно намекал, что стрельнет далеко не в полночь, но если на этот момент придется исполнение какой-нибудь, критичной к монотонности времени, софтины, то можно наступить на грабли. И чтобы не наступить на грабли, то в случае unix-like систем стоит посмотреть на сервера с которыми вы синхронизуетесь (это все же правильнее чем крутить step), а в случае Windows придется посмотреть, не накрутил ли кто MaxAllowedPhaseOffset так, что она сделает рывок назад (по закону подлости в самый неподходящий момент). Ну а для владельцев Stratum 1 — что не желательно, чтобы их сервера «отравили» клиентов, так как парочку таких серверов я уже находил.
Мощно вы так записали в велосипеды Starum 1 сервера, подключенные к различным эталонам.
Рекомендую подумать, откуда берет информацию о том что «leap second day today» startum 1 сервер, подключенный к тупому эталону, меланхолично считающему секунды по шкале TAI.
Вообще, интервал в котором до моих систем дойдет время скачек времени можно оценить таким образом для ntpd:
[(2^minpoll + stepout timeout) * (stratum — 1), (2^maxpoll + stepout timeout) * (stratum — 1)], где stratum — текущий stratum вашего сервера. (в реальности, там еще добавляется некое рандомное значение)
Подставляем дефолтные для ntpd значения и видим:
StratumИнтервал, с
2[964, 1924]
3[1928, 3848]
4[2892, 5772]
5[3856, 7696]
Да, GPS дает время в своей шкале, но так же дает и разницу с UTC. Лично я еще не видел ни одного GPS-приемника, который бы не мог справиться с такой арифметикой. Тем более, что NMEA 0183 явно специфицирует, что время в UTC.
И чем же с GLONASS проще в плане leap seconds? Собственно корректируется то шкала UTC, а часы спутника так же продолжают монотонно тикать вперед.
Только вот перед тем как изобретать велосипеды для того, чтобы не делать правильно, неплохо было бы вспомнить такую строчку из мануала:
«Note: The kernel time discipline is disabled if the step threshold is set to zero or greater than 0.5 s.»
Сам бы я тоже хочу, чтобы системное время шло по TAI, API было расширенно функциями для работы с TAI, а текущее API осуществляло бы прозрачный пересчет между TAI и UTC аналогично работе с локальным временем, но пока это, к сожалению, не так.
Есть. Но обычно используется версия без учета високосных секундах. В противном случае получится, что система у вас идет не по 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) так и будет, возможны неприятности с повторным запуском на исполнение того, что не надо. Например, запуск криво сделанного скрипта для импорта данных в какой-нибудь варехауз.
Рекомендую воздержаться от его использования, так как в ряде случаев при использовании старых версий ntpd (например, 4.2.4p5) это может приводить к ложной секунде координации.
P.S. официальные российские ntp-сервера работают через Ростелеком.
Рекомендую подумать, откуда берет информацию о том что «leap second day today» startum 1 сервер, подключенный к тупому эталону, меланхолично считающему секунды по шкале TAI.
[(2^minpoll + stepout timeout) * (stratum — 1), (2^maxpoll + stepout timeout) * (stratum — 1)], где stratum — текущий stratum вашего сервера. (в реальности, там еще добавляется некое рандомное значение)
Подставляем дефолтные для ntpd значения и видим:
StratumИнтервал, с
2[964, 1924]
3[1928, 3848]
4[2892, 5772]
5[3856, 7696]
И чем же с GLONASS проще в плане leap seconds? Собственно корректируется то шкала UTC, а часы спутника так же продолжают монотонно тикать вперед.
«Note: The kernel time discipline is disabled if the step threshold is set to zero or greater than 0.5 s.»
Кроме того, скрипты обычно ставят на исполнение по локальному времени, а leap second привязана с 00:00 по UTC.
В случае, если у вас настроена autokey авторизация, то leapfile передается клиенту. Возможно в ntpd просто переиспользовали использовали механизм передачи открытого ключа для передачи leapfile.
Плюсы: Относительно дешевый. Простота подключения (честные уровни RS-232).
Минусы: Большой jitter (~100 мс), если использовать только NMEA без PSS. Нет возможности принудительно зафиксировать координаты — это полезно в случае плохой видимости спутников — с зафиксированными координатами приемник теоретически может отдавать точное время и при видимости только одного спутника.
Но если в течение этого часа в вашей сети произойдет какой-либо инцидент, то даже 1 секунда разницы может добавить работы при его расследование.
В случае же, если компенсация происходит рывком, а в случае с ntpd с дефолтными настройками (step 0.128) так и будет, возможны неприятности с повторным запуском на исполнение того, что не надо. Например, запуск криво сделанного скрипта для импорта данных в какой-нибудь варехауз.