Насколько «реальны» часы POSIX на виртуальной машине?

Вступление:

Время - это ОС, как и Linux, обычно полученная из микросхемы часов (RTC) или поддерживаемая программным обеспечением, использующим для реализации либо периодические прерывания, либо некоторые аппаратные регистры (например, счетчик циклов ЦП TSC).

Очевидно, что в виртуальной машине нет прямого доступа к оборудованию (например, к RTC), поэтому соблюдение правильного времени может быть сложным.

В частности, меня интересуют две реализации часов POSIX: CLOCK_REALTIME и CLOCK_MONOTONIC (есть еще).

Нарушения

Есть два основных «возмущения», которые я рассматриваю:

1. «Перегрузка ЦП»: предоставление виртуальным машинам большего количества ЦП, чем физических.
2. «Живая миграция»: перемещение виртуальной машины с одной машины на другую «без» влияния на операции.

Нормальная операция

Процессы, работающие в операционной системе на голом оборудовании, прерываются только операционной системой (которая тогда имеет контроль). Таким образом, операционная система может легко отслеживать время.

Операция ВМ

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

Выбор

• CLOCK_REALTIME: если в ОС отсутствует ЦП, часы реального времени могут либо замедляться (отставать), либо время от времени перескакивать вперед, чтобы не отставать.
• CLOCK_MONOTONIC: если в ОС отсутствует ЦП, часы реального времени могут быть либо замедлены (по сравнению с другими виртуальными машинами или настенным временем), либо время от времени перескакивать вперед, чтобы не отставать.

Последствия

• CLOCK_REALTIME: Очевидно, что если часы реального времени медленные, их нельзя использовать в качестве меры абсолютного времени, но в виртуальной машине они будут выглядеть согласованными. Если часы не отстают, перескакивая вперед на переменное количество времени, их можно использовать как абсолютную меру, но это будет плохо для измерения любой производительности (длительности) внутри виртуальной машины.
• CLOCK_MONOTONIC: перевод монотонных часов только в том случае, если виртуальная машина «имеет ЦП» обеспечит согласованное представление прошедшего времени в виртуальной машине. Если часы перескакивают вперед на переменные промежутки времени, это не позволит использовать их для измерения производительности (длительности) внутри виртуальной машины.

Живая миграция

Когда динамическая миграция требует копирования гигабайтов ОЗУ с одного узла на другой, будет некоторое «время зависания», когда виртуальная машина не может работать, скажем, 3 секунды.

Теперь должно ли в реальном времени двигаться вперед на 3 секунды, или оно должно терять эти три секунды до тех пор, пока оно не будет исправлено вручную или автоматически в какое-то время позже? Точно так же, когда монотонные часы используются для измерения «времени безотказной работы», должны ли они учитывать эти три секунды, добавляя их, или они должны учитывать время, когда виртуальная машина фактически имела ЦП?

Чрезмерная нагрузка на ЦП

То же, что и выше, но более частые короткие задержки вместо случайных больших.

Вопросы

Какой подход использует Xen?

Как VMware справляется с этим? Есть ли настраиваемые параметры? (Я знаю, что в Xen виртуальные машины могут быть синхронизированы с гипервизором или работать независимо (например, синхронизироваться извне с помощью NTP))

Есть ли какие-то «лучшие практики»?

POSIX (и Linux в целом) никогда не имеет гарантированных таймеров в том смысле, что если вы усыпите что-то, вы можете ожидать, что оно проснется в точно определенное время. Вы можете только когда-либо гарантировать, что пробуждение произошло ПОСЛЕ указанного времени, а не точно в это время и никогда перед этим*.

Linux не предназначен для работы в реальном времени и просто старается изо всех сил.

От мужчина 2 наносон который совместим с POSIX:

nanosleep() приостанавливает выполнение вызывающего потока до тех пор, пока по меньшей мере время, указанное в *req, истекло, или доставка сигнал, запускающий вызов обработчика в вызывающем потоке или это завершает процесс.

Если вы ожидаете, что тики будут надежными, то проблема, скорее всего, в том, что у вас нет эвристики для управления слайдом внутри данного окна.

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

IE

• Программное обеспечение прерывается из-за некоторой аномалии задержки.
• Программное обеспечение при пробуждении замечает разницу по сравнению с каким-либо другим авторитетным источником времени и «шагает» свое представление о следующем пробуждении, чтобы компенсировать это.
• Вы печатаете предупреждение или предоставляете какое-либо другое уведомление.

Неправдоподобно думать о времени как о надежной системе с вытеснением. Даже на голом металле.

• Немаскируемые прерывания не могут быть заблокированы.
• Высокая нагрузка означает, что у вас просто запланировано долгое время.
• Прерывания ЦП, вызванные оборудованием, могут вызвать задержки.
• Незначительные и серьезные ошибки страниц могут привести к очень длительным задержкам между активациями таймера.
• Распределение памяти в банках памяти, не принадлежащих ЦП, добавляет задержки.

На самом деле это просто функция современных вычислений x86.

По крайней мере, в KVM есть источник часов под названием «kvm-clock», который должен представлять тики базового гипервизора независимо от любых неизвестных задержек в виртуальной машине. Вы можете найти этот файл и то, что вы установили по этому пути: /sys/устройства/система/источник часов/источник часов*/текущий_источник часов и посмотрите, какие у вас есть варианты /sys/устройства/система/источник часов/источник часов*/доступный_источник_часов.

Но опять же, базовый хост может иметь свои собственные задержки. Так что это просто черепахи на всем пути вниз ..

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

NTP в целом представляет собой целый протокол, предназначенный для решения проблемы времени, того, какое время является «правильным» и что делать с обработкой изменений во времени. Это довольно сложная проблема.

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

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

То, как я рассматриваю время при работе с группами различных систем, которые все связаны, заключается в том, что более важно, чтобы их временная локальность * находилась в пределах небольшого окна разницы. В этом смысле у меня была бы локальная настройка сервера времени, которая сама использует какой-то авторитетный источник, а затем синхронизировала бы все компьютеры в этой группе с этой локальной системой. Очень низкая задержка для локального сервера времени служит для уменьшения локального джиттера, и все хосты должны оставаться очень точно синхронизированными.

• Некоторые реализации таймера используют обработчик сигналов для перехвата событий. IE SIGALRM, если вы отправите процессу сигнал ALRM вне таймера, он проснется раньше него.

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