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

На нескольких производственных площадках мы наблюдали симптомы, которые, по-видимому, указывают на то, что часы дневного времени периодически прыгают вперед или назад. Скачки, как правило, около 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 .

13 голосов | спросил brett 7 MarpmFri, 07 Mar 2014 23:00:04 +04002014-03-07T23:00:04+04:0011 2014, 23:00:04

4 ответа


8
  

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

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

Пример:

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

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

  

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

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

Короче говоря, переключение источника аппаратных часов - это все, что вы можете сделать. Если вы не сделаете или не можете выполнить обмен, я бы предположил, что вы делаете

ответил Bratchley 7 MarpmFri, 07 Mar 2014 23:51:01 +04002014-03-07T23:51:01+04:0011 2014, 23:51:01
3

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

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

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

clocksource=hpet

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

  

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

     

Википедия: счетчик штампов времени

ответил 7 MarpmFri, 07 Mar 2014 23:56:52 +04002014-03-07T23:56:52+04:0011 2014, 23:56:52
1

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

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

ответил brett 13 MaramThu, 13 Mar 2014 01:00:57 +04002014-03-13T01:00:57+04:0001 2014, 01:00:57
0

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

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

ответил orion 8 MaramSat, 08 Mar 2014 01:44:32 +04002014-03-08T01:44:32+04:0001 2014, 01:44:32

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132