Как заменяемый текст отображается в терминале? [duplicate]

Время UNIX измеряется на вашем компьютере под управлением UNIX.

Этот ответ предполагает, что вы знаете, что такое всемирное координированное время (UTC), международное атомное время (TAI) и секунда в системе СИ. Их объяснение выходит далеко за возможности Unix и Linux Stack Exchange. Это не Стеклообменники по физике или астрономии.

Аппаратное обеспечение

Ваш компьютер содержит различные генераторы, которые управляют часами и таймерами. То, что у него есть, варьируется от компьютера к компьютеру в зависимости от его архитектуры. Но обычно и в очень общих чертах:

  • Где-то есть программируемый интервальный таймер (PIT), который можно запрограммировать на подсчет заданного количества колебаний и запуск прерывания для центрального процессора.
  • На центральном процессоре имеется счетчик циклов , который просто считает 1 для каждого исполняемого цикла команд.

Теория работы в очень широком смысле

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

В программном обеспечении ядро ​​увеличивает значение счетчика каждый тик. Он знает частоту тиков, потому что он изначально запрограммировал PIT. Итак, он знает, сколько тиков составляет секунда.Он может использовать это, чтобы знать, когда увеличивать счетчик, который считает секунды. Это последняя идея ядра «UNIX Time». На самом деле он просто считает в сторону увеличения со скоростью один за секунду в СИ, если оставить его наедине с собой.

Это усложняют четыре вещи, которые я собираюсь представить в очень общих чертах.

Аппаратное обеспечение несовершенно. PIT, в технических данных которого указано, что он имеет частоту генератора Н Герц, может вместо этого иметь частоту (скажем) Н 0,0000002 Гц, с очевидными последствиями.

Эта схема очень плохо взаимодействует с управлением питанием, потому что ЦП просыпается сотни раз в секунду, чтобы сделать немного больше, чем просто увеличить число в переменной. Таким образом, некоторые операционные системы имеют так называемый «тиковый» дизайн. Вместо того, чтобы заставлять PIT посылать прерывание для каждого тика, ядро ​​вычисляет (из низкоуровневого планировщика), сколько тиков будет проходить без исчерпания квантов потока, и программирует PIT для подсчета этого количества тиков в future перед выдачей тикового прерывания. Он знает, что затем он должен записать прохождение N тиков при прерывании следующего тика вместо 1 тика.

Прикладное программное обеспечение может изменять текущее время ядра. Он может изменить значение или изменить значение. Поворот включает в себя регулировку количества тактов, которые должны пройти, чтобы увеличить счетчик секунд. Таким образом, счетчик секунд не обязательно ведет счет со скоростью одна секунда в СИ в любом случае , даже если предположить, что осцилляторы идеальны.Пошаговое выполнение включает в себя простую запись нового числа в счетчик секунд, что обычно происходит не раньше, чем через 1 секунду после последней секунды.

Современные ядра считают не только секунды, но и наносекунды. Но нелепо и часто совершенно невозможно использовать прерывание с интервалом один раз в наносекунду. Здесь в игру вступают такие вещи, как счетчик циклов . Ядро запоминает значение счетчика циклов каждую секунду (или каждый тик) и может вычислить, исходя из текущего значения счетчика, когда что-то хочет узнать время в наносекундах, сколько наносекунд должно пройти. с последней секунды (или отметки). Опять же, управление питанием и температурой наносит ущерб, поскольку частота цикла команд может изменяться, поэтому ядра полагаются на дополнительное оборудование, например, например, на высокоточный таймер событий (HPET).

Язык C и POSIX

Стандартная библиотека языка C описывает время в терминах непрозрачного типа, time_t , типа структуры tm с различными заданными полями, и различные библиотечные функции, такие как time () , mktime () и localtime () .

Вкратце: сам язык C просто гарантирует, что time_t является одним из доступных числовых типов данных и что единственный надежный способ вычисления разницы во времени это функция difftime () .Это стандарт POSIX, который обеспечивает более строгие гарантии того, что time_t на самом деле является одним из целочисленных типов и что он считает секунд с начала Эпохи . Это также стандарт POSIX, который определяет тип структуры timespec .

Функция time () иногда описывается как системный вызов. Фактически, в наши дни это не было основным системным вызовом во многих системах в течение довольно долгого времени. В FreeBSD, например, основным системным вызовом является clock_gettime () , который имеет различные доступные «часы», которые измеряют в секундах или секундах + наносекундах различными способами. Это этот системный вызов, с помощью которого прикладное программное обеспечение считывает время UNIX из ядра. (Соответствующий системный вызов clock_settime () позволяет им пошагово, а системный вызов adjtime () позволяет им убрать его.)

Многие люди размахивают стандартом POSIX с помощью очень определенные и точные утверждения о том, что он предписывает. Такие люди чаще всего фактически не читали стандарт POSIX. В соответствии с его логическим обоснованием, идея подсчета «секунд с начала эпохи», которая используется в стандарте намеренно , не указывает, что секунды POSIX имеют ту же длину, что и секунды SI, или что результатом gmtime () будет «обязательно UTC, несмотря на его внешний вид». Стандарт POSIX намеренно достаточно свободен, чтобы разрешить (скажем) систему UNIX, в которую входит администратор и вручную исправляет корректировки секунды координации, переустанавливая часы через неделю после того, как они произошли. Действительно, обоснование указывает на то, что оно намеренно достаточно ослаблено, чтобы приспособиться к системам, в которых часы намеренно установлены неправильно на какое-то время, отличное от текущего времени UTC.

UTC и TAI

Интерпретация времени UNIX, полученного от ядра, зависит от библиотечных процедур, выполняемых в приложениях. POSIX определяет идентичность между временем ядра и «временем простоя» в struct tm . Но, как однажды заметил Дэниел Дж. Бернстайн, в стандарте 1997 года эта идентификация была приведена к досадной ошибке, так как было нарушено правило високосного года григорианского календаря (то, что учат школьники), так что с 2100 года и далее вычисления были ошибочными. «Больше чести в нарушении, чем в соблюдении» - это фраза, которая легко приходит на ум.

И действительно, это так. Некоторые системы в настоящее время основывают эту интерпретацию на библиотечных подпрограммах, написанных Артуром Дэвидом Олсоном, которые обращаются к печально известной «базе данных часовых поясов Олсона», обычно закодированной в файлах базы данных в каталоге / usr / share / zoneinfo / . В системе Олсона было два режима:

  • Считается, что "секунды с начала эпохи" ядра отсчитывают секунды по всемирному координированному времени с 00:00:00 UTC 01.01.1970, за исключением дополнительных секунд. При этом используется набор posix / файлов базы данных часовых поясов Olson. Все дни имеют 86400 секунд ядра, и никогда не бывает 61 секунды в минуте, но они не всегда равны секунде SI, и часы ядра нуждаются в повороте или пошаговом изменении при возникновении дополнительных секунд.
  • Считается, что "секунды с начала эпохи" ядра подсчитывают секунды TAI с 1970-01-01 00:00:10 TAI. При этом используется набор right / файлов базы данных часовых поясов Olson.Секунды ядра имеют длину 1 секунду SI, и часы ядра никогда не нуждаются в повороте или пошаговом изменении для настройки дополнительных секунд, но время простоя может иметь такие значения, как 23:59:60, а дни не всегда имеют длину 86400 секунд ядра.

М. Бернштейн написал несколько инструментов, в том числе свой набор инструментов daemontools , для которых требовалось right / , потому что они просто добавляли 10 к time_t , чтобы получить секунды TAI с 01.01.1970. : 00: 00 ТАЙ. Он задокументировал это на странице руководства.

Это требование было (возможно, неосознанно) унаследовано такими инструментами, как daemontools-encore и runit , а также libowfat Феликса фон Лейтнера . Используйте Bernstein multilog , Guenter multilog или Pape svlogd с конфигурацией Olson posix / , например, и все временные метки TAI64N будут (на момент написания) на 26 секунд отстают от фактического секундного отсчета TAI с 1970-01-01 00:00:10 TAI.

Лоран Берко и я рассматривали этот вопрос в s6 и nosh, хотя и использовали разные подходы. tai_from_sysclock () М. Берко полагается на флаг времени компиляции. nosh инструменты, которые работают с TAI64N, смотрят на переменные среды TZ и TZDIR для автоматического определения posix / и right / , если они могут .

Интересно, что FreeBSD документирует time2posix () и posix2time () функции, которые позволяют эквивалент режима Olson right / с time_t ] в секундах TAI. Однако они явно не включены.

Еще раз…

UNIX-время измеряется на вашем компьютере, работающем под UNIX, с помощью генераторов, содержащихся в аппаратном обеспечении вашего компьютера. Он не использует секунды SI; это не всемирное координированное время, даже если внешне оно может напоминать его;и он намеренно позволяет вашим часам быть неправильными.

Дополнительная литература

1
13.10.2013, 23:52
0 ответов

Теги

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