Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron every hour or two.
BTW: ntpd в ряде случаев тоже переставляет время рывком.
Честно говоря, меня ломает вставать в 7 утра, чтобы это проверить. Но я вполне верю спецификации на мой GPS приемник, в которой указано, что приемник сам пересчитывает время и отдает его по NMEA в UTC, а так же, что положительная leap second отображается как 235960.
Писал статью предполагая, что наиболее вероятный сценарий — «прощелканная клювом» секунда координации. И вот обнаружился 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 аналогично работе с локальным временем, но пока это, к сожалению, не так.
Time adjustments are made by ntpdate in one of two ways. If ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when ntpdate is run by cron every hour or two.
BTW: ntpd в ряде случаев тоже переставляет время рывком.
Рекомендую воздержаться от его использования, так как в ряде случаев при использовании старых версий 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.»