Что: 0995cc9cf92cb41b2f25532c6d806ecf3f69ca22
Когда: 2020-11-03 21:47:06+03:00
------------------------------------------------------------------------
Темы: time
------------------------------------------------------------------------
Может ли время на компьютере идти вспять?

Вот только что:

    ~|0|0-% fdm -a XXX fetch
    stcnet: 0 messages processed in -0.252 seconds

проверило сообщения ещё до вызова команды.

------------------------------------------------------------------------
оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20%D0%9C%D0%BE%D0%B6%D0%B5%D1%82%20%D0%BB%D0%B8%20%D0%B2%D1%80%D0%B5%D0%BC%D1%8F%20%D0%BD%D0%B0%20%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%B5%20%D0%B8%D0%B4%D1%82%D0%B8%20%D0%B2%D1%81%D0%BF%D1%8F%D1%82%D1%8C%3F%20%280995cc9cf92cb41b2f25532c6d806ecf3f69ca22%29

------------------------------------------------------------------------
комментарий 0:
From: kmeaw
Date: 2020-11-04 01:27:40Z

CLOCK_REALTIME может, а CLOCK_MONOTONIC не может. Но в Linux есть time
namespace, который позволяет виртуализировать CLOCK_MONOTONIC и добавить
к нему (возможно отрицательное) смещение, так что в редких случаях всё
равно может.

Самая частая причина скачков CLOCK_REALTIME это работа клиента
сихронизации времени с внешним источником.

В большинстве реализаций ntp есть код для плавной подстройки часов
(adjtimex), чтобы такого не происходило.

К сожалению, не все знают про CLOCK_MONOTONIC, и до сих пор часто пишут
код, который измеряет прошедшее время между двумя точками через разность
CLOCK_REALTIME.

В Go про это подумали, и засунули и те, и другие часы в time.Time:
https://golang.org/pkg/time/#hdr-Monotonic_Clocks

fdm, как несложно догадаться, использует CLOCK_REALTIME:
https://github.com/nicm/fdm/blob/eabdf3beb623aba8e5905c9d5d2cb3eed8c6a780/fdm.c#L79-L87
https://github.com/nicm/fdm/blob/eabdf3beb623aba8e5905c9d5d2cb3eed8c6a780/child-fetch.c#L321

------------------------------------------------------------------------
комментарий 1:
From: Sergey Matveev
Date: 2020-11-04 08:16:06Z

*** kmeaw [2020-11-04 04:22]:
>Самая частая причина скачков CLOCK_REALTIME это работа клиента
>сихронизации времени с внешним источником.

Я как-раз на тот момент перезагрузил систему (точнее забыл подключить к
питанию и не заметил что аккумулятор сел) и наверное NTP на тот момент
решил подкрутить время. Хотя я думал что NTP в BSD из коробки именно
управляет скоростью хода времени и оно никогда не может идти не в перёд,
Но также слышал что в момент первого запуска он может и жёстко выставить
его -- думаю это и произошло. Надо бы конечно не гадать, а взять и
посмотреть, чтобы понимать работу компьютера, а не на слухах жить, но...
лень :-)

>К сожалению, не все знают про CLOCK_MONOTONIC, и до сих пор часто пишут
>код, который измеряет прошедшее время между двумя точками через разность
>CLOCK_REALTIME.

Я вообще не знал про эти штуки. Честно говоря, думал что из-за NTP,
которые управляют скоростью хода часов, а не жёстко выставляют, можно
всегда предполагать что часы идут только вперёд и поэтому можно
безопасно вызывать "обычный" CLOCK_REALTIME (что всю жизнь и делал,
получается). Только при загрузке ОС допустимо делать что-нибудь типа
ntpdate, до запуска, грубо говоря, любых других программ. А кто
синхронизирует время по cron этой командой -- сам дурак и сам виноват :-).
А если NTP не используется, то тоже часы идут только вперёд.
Эх, век живи -- век учись!

------------------------------------------------------------------------
Сгенерирован: SGBlog 0.34.0