LINUX.ORG.RU

Как отследить стабильность часов,тиков,времени в linux ?

 тики,


0

1

У одной программы (автор не я) вывод времени свершившегося события раз от раза отличается и есть подозрение что часы в Linux скачут +- секунда, а может и больше.

Нагрузка на сервер минимальна.

Как это можно отследить? в чем может быть причина?

★★★★

Последнее исправление: Vlad-76 (всего исправлений: 5)

Поставь RT ядро. Маловероятно, что проблема в системных часах. Хотя если у тебя Linux запущен в виртуальной машине Hyper-V - вполне возможно, встречался с тем, что системные часы в ВМ с Linux спешили или отставали, уже точно не помню.

Если выше описанное не помогает - проблема в программе.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)

Если «одно и тоже событие» происходит в многозадачной системе и включает в себя вероятность переключения контекста (например, системный вызов) — оно очевидно не обязано выполняться за константное время. Это нормальное поведение.

Чтобы можно было что–то ещё сказать, нужно больше конкретики.

anonymous
()
Ответ на: комментарий от anonymous

про событие поправил первый пост.

Какой конкретики?

На консоли программы,смотрю вывод. В один раз время свершения (установление соединения, в прошлом) события 14:26:55, через час бывает 14:26:56, через пару часов снова 14:26:55

Vlad-76 ★★★★
() автор топика
Последнее исправление: Vlad-76 (всего исправлений: 1)
Ответ на: комментарий от Vlad-76

И? По приведённому описанию ничего конкретного сказать нельзя.

Это может быть банально ошибка в алгоритме вывода времени, когда округление до секунд может проивзодиться как в большую, так и в меньшую сторону.

anonymous
()

У одной программы (автор не я) вывод времени… отличается

Есть несколько системных вызовов для получения времени, у каждого свои особенности — надо смотреть, какой использует (не) твоя программа. Если скажешь, что нет исходных текстов, то у меня встречный вопрос: почему ты вообще решил, что это время, а не какая-то последовательность чисел, похожая на него?

есть подозрение что часы в Linux скачут

Больше того, если запущен какой-нибудь синхронизатор времени по NTP, то часы точно плывут.
Хотя да, в обратную сторону в приличных синхронизаторах время не движется.

anonymous
()

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

masa
()

вывод времени свершившегося события раз от раза отличается и есть подозрение что часы в Linux скачут +- секунда, а может и больше.

часы в линукс точно никуда не скачут. не сомневайтесь.

а почему время свершившегося события должно быть одинаковым? у нас же время вроде как не стоит на месте. ну и время событий тоже меняется не?

antech
()
Ответ на: комментарий от anonymous

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

antech
()
Последнее исправление: antech (всего исправлений: 1)

если это _свершившееся_ событие, т.е. сначала событие - а потом запись таймстампа в лог, то возможно происходит не задержка начала выполнения этого события, а выполнение кода этого события занимает разное количество реального времени (система занята чем-то другим), а если лог пишет какой-то третий сервис (e.g. journald), то добавить расход времени на обмен сообщением с ним, например

посмотреть как плывут часы можно в логе ntp-клиента если он установлен

посмотреть когда в твоей программе стреляет то или иной событие - strace.

slowpony ★★★★★
()

Для начала есть часы реального времени и монотонные. Монотонные используются если нужно отмерять периоды времени. Обычные часы можно в любой момент подвести либо вручную, либо с помощью NTP. Чтобы программы не ломались, в монотонных часах никогда не скачут показания, даже если обычные на несколько лет вперёд поменялись.

Часы реального времени пытаются максимально соответствовать движению Земли, чтобы пик солнечного дня всегда был в среднем в 12:00. Планета вращается несколько неравномерно ввиду множества факторов: влияние других планет, Луны, неравномерно распределённая масса внутри самой планеты. Поэтому требуются удачно сформированные календари и введение поправок постфактум, в случае григорианского календаря это високосные дни и секунды. То есть, при синхронизации времени по NTP скакнуть внезапно на секунду это нормально, но обычно такое происходит редко и есть заранее известная эфемерида для тех кому важно.

Часы в системе всегда имеют некоторую погрешность. Причём часы когда компьютер включен и когда выключен — это разные часы с разными погрешностями. Поэтому они периодически подводятся по NTP, чтобы не накапливалось слишком большой ошибки. Монотонные часы точно так же имеют погрешность, но не подводятся по NTP, а тупо считают число секунд. Погрешность часов обычно состоит из двух компонент: линейного и случайного, линейное это какое-нибудь отставание на 5 секунд каждый день, то есть у них в сутках чуть меньше секунд, чем нужно. Случайное это дополнительный непредсказуемый шум. Скорее всего, обе эти компоненты в часах современных компьютеров когда они включены измеряются микросекундами в сутки, но конкретные цифры я не нашёл.

Вывод времени обычно использует немонотонные часы, то есть простейший цикл while true { sleep 86400 ; do_action ; report_time } может немного скакать даже если action и report отрабатывают мгновенно, так как sleep ориентируется на монотонные часы. Более того, этот же простой алгоритм будет постоянно уползать вперёд, так как action и report всё-таки занимают время. Чтобы это работало корректно, длительность sleep нужно каждый раз вычислять. И куда более прозаичных причин: action выполняется каждый раз за разное время, к примеру то 3, то 4 секунды, выходит что report будет показывать плавающий результат. Скорее всего, это именно то что у тебя происходит. Можешь считать, что это недочёт в программе.

Собственно поведение программы может быть подстроено так, чтобы выполняться в конкретное время солнечных часов, с подстройкой по NTP. А может быть заточено под строгую периодичность, неважно который там час. Неизвестно какая цель была у той программы что у тебя.

neumond
()

А событие в эту программу приходит откуда-то извне и синхронизировано по отдельным часам?

Так, можете написать код, который раз в секунду сверяет время от clock_gettime(CLOCK_REALTIME) и clock_gettime(CLOCK_MONOTONIC) или постоянно сверять системное время с другим часами, не важно, ntp-сервер или отдельные RTC-часы на i2c.

mky ★★★★★
()
Ответ на: комментарий от antech

«а почему время свершившегося события должно быть одинаковым?»

Событие - (tcp соединение) свершилось в прошлом и висит(tcp соединение не рвется), время его свершения (установление tcp соединения) зафиксировалось таймштампом (в прошлом). Я исхожу из этого.

Смотрю через консоль статус события, вижу время его свершения (в прошлом) меняется раз от раза.

Время в формате часы:минуты:секунды.

Vlad-76 ★★★★
() автор топика
Последнее исправление: Vlad-76 (всего исправлений: 2)
Ответ на: комментарий от Vlad-76

ну вот «установление» это процесс который определяется периодом началось во столько, закончилось во столько. так? timestamp он ставится на тсп пакет а не соединение. и кто его ставит ты или вторая сторона?

antech
()
Ответ на: комментарий от Vlad-76

Не совсем понял. В выводе программы время свершения одного и того же события раз от разу меняется? То есть:

При первом запуске:  16.02.25 14:37:23
В втором запуске:    16.02.25 14:37:24
При третьем запуске: 16.02.25 14:37:22
То есть программа где-то у себя не хранит это время, а как-то его вычисляет, что-ли? Вроде, у сокета время создания смотрится через /proc/PID/fd, хотя там какие-то оговорки, что там фиксируется не время создания сокета, а время первого чтения каталога /proc/PID/fd. Но, в любом случае, это время из структур ядра, оно там хранится и, по идее, не может прыгать.

mky ★★★★★
()

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

rtxtxtrx ★★
()
Ответ на: комментарий от rtxtxtrx

совершенно, не стало

эта ситуация попалась на глаза случайно, при разборе полетов с таймерами протокола, которые работают с таймингами < 1секнуды

Vlad-76 ★★★★
() автор топика

Как это можно отследить?

Можно взять monotonic часы и смотреть через равные (по ним) интервалы изменения у wallclock. Можно через ntp (или эту его новую упрощенную версию от МО) брать время извне.

в чем может быть причина?

В кривой программе не твоего авторства? Смотри её исходники.

anonymous
()