Как я могу измерить и предотвратить смещение часов?

15

На нескольких производственных платформах мы наблюдали симптомы, которые, по-видимому, свидетельствуют о том, что время суток периодически скачет вперед или назад. Прыжки, как правило, составляют около 1 секунды, обычно отменяются (скачок вперед, затем назад очень скоро после этого) и происходят около 50 раз в день. Этот дрейф наиболее заметен в периоды пиковой нагрузки на приложения, а также в периоды интенсивного дискового ввода-вывода, например ежедневного резервного копирования. Эти дрейфы влияют на наше мягкое чувствительное приложение в реальном времени.

Системы - это серверы Oracle Netra X4250 и Netra X4270, работающие под управлением SLES 11SP2 с ядром по умолчанию 3.0.58-0.6.6.

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Мы отключили NTP , но это не оказало никакого влияния на заносы. Существуют ли инструменты для измерения времени смещения часов? Как мы можем избежать этого?

Это производственные платформы, и мы не можем воссоздать проблему в наших лабораториях, поэтому моя способность экспериментировать ограничена. Если я оставлю это своим собственным устройствам, я напишу инструмент для измерения дрейфа и, возможно, поэкспериментирую с источником часов HPET .

linux sles clock Бретт
источник
5
Отключение NTP делает часы намного более нестабильными ... единственная причина, по которой я вижу, что NTP не держит часы в очереди, состоит в том, что часы не работают, и NTP отказывается их обновлять (см. ntpdate(8)Или ntpd(8)).
vonbrand
1
NTPD отслеживает и корректирует смещение часов, но то, что у вас есть, не смещается. Дрейф последовательно в одном и том же направлении со временем примерно одинаков. Если он случайным образом прыгает вперед и назад, нет способа предсказать его и приспособиться к нему.
Патрик
1
То, что @Patrick сказал правильно, проблема, которую вы описываете, это прерывистый скачок времени вперед и назад, несколько раз в день. NTP хорошо работает на дрифте, но это вам мало поможет. Что-то, вероятно, сбрасывает системную дату на какой-либо внешний источник времени, который может иметь разрешение только в 1 секунду. Если ваши серверы имеют архитектуру x86 *, аппаратный RTC может быть источником, а виновником может быть какое-то задание cron. Поскольку измерение смещения тактового сигнала Ntpdate Братчли является разумным подходом, при условии, что используется хороший эталон тактового импульса для страты 1: запускайте раз в минуту и ​​gnuplot результат для изображения.
Дуанев
1
Пробежался по этой оценке запуска NTP на новом сервере ( drdobbs.com/embedded-systems/… ). NTP часы, чтобы изучить новый кристалл. Для действительно плохих кристаллов NTP придется «многократно» шагать по часам во время тренировки (см. Рисунки 4 и 5 в этой статье). Окончательное значение в ntp.drift 118ppm составляет 10 секунд в день или 208ms каждые 30 минут. Хотя это не то, что видел OP, изначально NTP может вызывать заметные скачки во времени.
Дуанев

Ответы:

8

Существуют ли инструменты для измерения времени смещения часов?

Единственные инструменты, которые мне известны, это инструменты NTP, которых должно быть достаточно. Вам не нужно настраивать ntpd для синхронизации с данным источником синхронизации, вы можете просто использовать -dопцию ntpdateдля получения рассчитанного смещения.

Пример:

[davisja5@xxxadmvlm08 ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[davisja5@xxxadmvlm08 ~]$

-d это опция отладки, которая работает по протоколу NTP, фактически не затрагивая системные часы.

Любой совет, как мы можем избежать этого?

Я не слишком удивлен, что вы не можете воспроизвести это в среде разработки / тестирования, так как это, вероятно, только из-за аппаратных часов. Если у вас есть аппаратная поддержка с кем-то, я постараюсь обслуживать ваши машины. Одна возможность - обменять одну из машин разработчика на эту производственную машину, починить прежние системы PROD и повторно представить ее как машину разработчика, чтобы заменить ту, которая сейчас находится в PROD.

Если не считать этого, переключение источника аппаратных часов - это почти все, что вы можете сделать. Если вы не можете или не можете сделать обмен, я бы посоветовал вам пойти по пути hpet. Вы можете проверить, не мешает ли изменение источника синхронизации системным службам, а затем развернуть его в производственной среде.

Bratchley
источник
Под «измерением смещения часов» я не имел в виду смещение от эталонного источника времени, такого как NTP. Я имел в виду инструмент, который может обнаруживать «скачки» во времени дневного времени в непрерывном диапазоне времени. Например, возьмите выборки по времени дня каждые 50 мс и сообщите, отличается ли разница от последней выборки от 50 мс. Такой инструмент показал бы, отклоняется ли время суток от базовых аппаратных часов по какой-либо причине.
Бретт
1
Не приведет ли присутствие такого вмешательства к более значительному снижению производительности, чем вы надеетесь решить? По всей вероятности, это аппаратная проблема, поэтому вам нужно будет обслуживать оборудование или использовать источник синхронизации без этой проблемы. tscоснован на процессоре, поэтому имеет смысл, что более высокая активность процессора в любом случае вызовет проблему с аппаратными часами. Если hpet достаточно быстр для вас, то вам, возможно, придется просто попробовать это, получить обслуживание или выполнить обмен. Это единственные варианты, которые я вижу для вас.
Братчли
3

Одним из решений является использование HPET

Смотрите также Высокоточный таймер событий

Чтобы установить его в качестве параметра загрузки, используйте

clocksource=hpet

На старом оборудовании TSCон часто был нестабильным и был отключен ядром.

С появлением многоядерных / гиперпоточных процессоров, систем с несколькими процессорами и гибернационных операционных систем нельзя полагаться на TSC для получения точных результатов ...

Википедия: Счетчик отметок времени


источник
В производственной системе, демонстрирующей симптомы дрожания часов, я переключил источник синхронизации на hpet. Это не повлияло на наблюдаемые симптомы дрожания часов.
Брет
HPET является внешним аппаратным таймером и не может дрожать. Так что это решение кажется неправильным путем. Было много проблем с синхронизацией со старым оборудованием, особенно при использовании виртуализации. Вы проверяли это с другим программным обеспечением также?
1

Я написал более подробный инструмент для сопоставления измерений часов с симптомами задержки, которые демонстрирует наше приложение. Этот инструмент, кажется, исключает то, что я ранее подозревал как дрожание в часах времени Linux.

Короче говоря, моя первоначальная гипотеза оказалась неверной. Но я много узнал о часах Linux из ответов и ссылок, так что спасибо всем, кто откликнулся!

Бретт
источник
3
(...) моя первоначальная гипотеза была неверна. Не могли бы вы рассказать нам, какова была настоящая причина?
Петр Доброгост
0

Разве часы не должны быть однообразными, если кто-то не изменит их? Прыжки назад не должны быть возможными. Должно быть что-то, что настраивает часы - задание cron или какой-то другой демон (например, вызов hwclock --adjust). Напомню, что ntp сам обновляет статистику по дрифту и регулярно его компенсирует, и если вам не удается долго запустить ntp и получить огромное смещение, он теряет время на несколько дней после него, если вы не сбросите настройки/etc/adjtime . У вас может быть что-то подобное, что-то, что периодически корректирует смещение времени (и вызывает скачки).

ntp на самом деле предназначен для противодействия этой проблеме.

Орион
источник
Я тоже так думал. Мое чтение источников аппаратных часов показывает, что счетчик должен монотонно увеличиваться. Если бы это было правдой, в худшем случае мы должны наблюдать беспорядочную частоту тиков, но никогда не возвращаться назад. В многопроцессорной системе я понимаю, что tsc необходимо синхронизировать между процессорами - возможно, именно это вызывает скачки в обратном направлении?
Брет