Почему CLOCK_TAI и CLOCK_REALTIME возвращают то же значение?
На моей Ubuntu 15.04 (3.19.0-28-универсальное Ядро Linux) я получаю то же значение при запросе CLOCK_TAI и CLOCK_REALTIME с clock_gettime(). Это - по-видимому, ошибка потому что различие между CLOCK_TAI и CLOCK_REALTIME должно быть число секунд прыжка плюс различие эпохи, рассмотрев эту статью об ОС Redhat.
2 ответа
CLOCK_TAI is basically designed as CLOCK_REALTIME(UTC) + tai_offset.
, Таким образом, часть мкс/национальной безопасности timeval/timespec должна быть идентичной.
CLOCK_MONOTONIC: Zeroed at boot.
CLOCK_TAI = CLOCK_MONOTONIC + tai_mon_offset
CLOCK_REALTIME(UTC) = CLOCK_TAI - tai_utc_offset
, Но из-за проблемы производительности (CLOCK_REALTIME - то, что приложения куют больше всего), в Linux мы на самом деле структурируем его как:
CLOCK_REALTIME: Initialized at boot from RTC
CLOCK_MONOTONIC: CLOCK_REALTIME - wall_to_monotonic
CLOCK_TAI: CLOCK_REALTIME + tai_offset
Так CLOCK_REALTIME and CLOCK_TAI return the same because the kernel parameter tai_offset is zero.
Проверка при помощи adjtimex(timex tmx) и читают значение. Я думаю, что ntpd установит его, если это будет достаточно новое (>4.2.6) и будет иметь прыжок второй файл. Это может также смочь получить его от вышестоящих серверов, но я не смог проверить. Вызов adjtimex() может установить tai_offset вручную, когда выполнено как корень.
Ответ был найден в отнесенной статье. Акцент мной.
Для приложений, где было бы возможно работать со временем TAI вместо UTC, ядро обеспечивает специальные часы CLOCK_TAI, которые действительно включают секунды прыжка, и doesn’t должен быть исправлен после второго прыжка, избежав проблемы с обратным переходом во время полностью. It’s реализовал как часы, работающие при фиксированном интегральном смещении к CLOCK_REALTIME, который атомарно увеличен 1, когда часы CLOCK_REALTIME отступаются на втором прыжке. Это было представлено в версии 3.10 ядра Linux и доступно с ядрами, поставленными в RHEL7. Обратите внимание на то, что смещение от CLOCK_REALTIME инициализируется на начальной загрузке для обнуления, и ни ntpd, ни chronyd не устанавливают его по умолчанию на правильное значение (в настоящее время 35). Переключение на CLOCK_TAI в приложениях, конечно, потребовало бы модификаций к коду и возможно также всем протоколам, которые используют представление Unix времени.