Синхронизация времени в гетерогенной среде

Question 1

[ПРАВКА] Значительная переработка со ссылками, поскольку я просто записал старый ответ по памяти.

Короткий ответ: нет.Сегодня невозможно получить точность, близкую к миллисекунде, от обычной операционной системы на платформе x86/x64.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ Это ответ дилетанта, поскольку я обычный системный администратор с обычным системным администраторским взглядом на компьютеры. Профессиональный уровень знаний по хронометрированию, вероятно, встречается среди некоторых разработчиков ядра и архитекторов оборудования.

Длинный ответ:

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

Первая проблема заключается не в том, чтобы иметь хронометраж на одном компьютере, а в том, чтобы заставить среду в целом согласиться на любой хронометраж, который у вас есть. Какой хронометраж? Оказывается, есть несколько способов отслеживать время на современном компьютере. Чаще всего мы видим системное время (отображаемое в одном из углов экрана). Давайте начнем с того, что притворимся, что все так просто, и усложним все на пару абзацев ниже.

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

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

За исключением устаревших версий, таких как NT, Windows использует для хронометража либо упрощенный протокол NTP (компьютеры, присоединенные к домену, начиная с XP/2003), либо упрощенный протокол SNTP (компьютеры, не присоединенные к домену, начиная с Win2k) — спасибо @Ryan за придирки к этим деталям.Microsoft поставила две целипри реализации хронометража ни один из них не обеспечивает желаемого нами уровня точности:

«Мы не гарантируем и не поддерживаем точность службы W32Time между узлами в сети. Служба W32Time не является полнофункциональным решением NTP, которое удовлетворяет потребности приложений, чувствительных ко времени. Служба W32Time в первую очередь предназначена для выполнения следующих задач:

Обеспечьте работу протокола аутентификации Kerberos версии 5.
Обеспечить свободное время синхронизации для клиентских компьютеров.

Служба W32Time не может надежно поддерживать время синхронизации в диапазоне от одной до двух секунд. Такие допуски выходят за рамки спецификации проекта службы W32Time."

Хорошо. Предположим, что мы запускаем ваш сервисный стек на более чем одном компьютере и имеем уровень допуска хронометража, приближающийся к 1 мс для корреляции событий, это довольно разочаровывает. Если сервисный стек включает два компьютера, мы фактически вообще не можем использовать собственный хронометраж Windows. Но пока мы этим занимаемся, давайте подчеркнем один или два ключевых момента о собственном хронометраже Windows и включим некоторую подробную документацию:

Если у вас есть AD, обратите внимание, что время в данном домене будет синхронизировано с ролью эмулятора PDC, какой бы контроллер домена ее ни имел. Таким образом, введение правильного времени в домен должно осуществляться через контроллер домена, выполняющий роль эмулятора PDC. Если в лесу с несколькими доменами это транслируется в эмулятор PDC корневого домена леса. Оттуда время в первую очередь распределяется по эмуляторам PDC поддоменов и каждому члену домена в режиме разветвления (с некоторыми оговорками). Этот процессзадокументировано здесь. Еще более подробная информацияздесь

Хорошо. Что мы можем сделать?

Для начала нам нужноодинилидругойболее точный способ синхронизации времени во всей среде. Предполагая, что мы не можем запустить Linux ntpd илиntpd для Windowsвы можете взглянуть на условно-бесплатный клиент под названиемТардис, но, вероятно, есть и другие, которые стоит попробовать.

Мы запустили Tardis на сервере Win2k3, работающем как PDC Emulator, у которого были часы CMOS с очень большим перекосом, по необъяснимым историческим причинам у нас не было выбора, кроме как синхронизировать всю сеть с него. Теперь его заменили к большой радости на выделенный Linux ntpd, который считывал время с атомных часов снаружи, но Tardis спас нас замечательно тогда и там.Однако я не знаю, поможет ли это вам достичь большей точности, чем та, что есть в Windows.

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

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

Давайте рассмотрим, как операционные системы на архитектуре x86/x64 планируют процессорное время.

Они используют прерывания, которыемногогранные звери, богатые археологическим материалом. Однако операционная система не одинока в своем желании прерывать. Аппаратное обеспечение тоже хочет прерывать, и у него есть средства для этого! (Привет, клавиатура) И операционные системы подыгрывают.

Вот где все становится сложнее, и я решу это путем упрощения. Вопросы? Я уклоняюсь, прикрываю и указываю вам наабсолютно превосходный трактат на эту тему. (Если вы охотитесь за миллисекундами на платформе Windows, вам действительно стоит это прочитать..) Обновленная версия для Win8.1/Win2012r2 —сообщается, что в разработкено дата релиза пока не объявлена.

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

Давайте кратко остановимся на прерывании хронометража. Прерывание имеет уровень приоритета, самый низкий уровень — это уровень, на котором пользовательские приложения (например, стандартная служба) получают свое процессорное время. Другие (более высокие) уровни зарезервированы для оборудования и для работы ядра. Если поступает прерывание на уровне выше самого низкого, система будет делать вид, что никаких прерываний с более низким приоритетом, также находящихся в очереди, не существует (пока не будут обработаны прерывания с более высоким приоритетом). Таким образом, обычные приложения и службы, работающие, будут последними в очереди на процессорное время. В отличие от этого, почти самый высокий приоритет дается прерыванию часов. Обновление времени будет выполняться в системе почти всегда. Это почти преступное упрощение того, как все это работает, но оно служит цели этого ответа.

Обновление времени фактически состоит из двух задач:

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

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

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

Короче говоря, синхронное хронометрирование имеет один опорный тактовый генератор на многоядерное ядро, который распределяет свой сигнал по всем ядрам. Асинхронное хронометрирование имеет один осциллятор на ядро. Стоит отметить, что новейшие многоядерные процессоры Intel (Haswell) используют некоторую форму синхронного дизайна с использованием последовательной шины, называемой «QuickPath Interconnect» с «Forwarded Clocking», ref.техническая спецификация. Перенаправленное тактирование описано в терминах, которые позволяют неспециалисту (то есть мне) быстро получить поверхностное представление о нем.здесь.

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

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

Тикающие ядраотправлять прерывания с фиксированными интервалами. ОС не может измерять время с более точным разрешением, чем интервал тика. Даже тогда фактическая обработка, вовлеченная в выполнение одного или нескольких действий, может содержать задержку, превышающую интервал тика. Рассмотрим, например, распределенные системы (например, микросервисы), где задержки, присущие межсервисным вызовам, могут потреблять относительно много времени. Тем не менее, каждый набор инструкций будет связан с одним или несколькими прерываниями, измеряемыми ОС с разрешением не более точным, чем время тика ядра. Время тика имеет базовое значение, но, по крайней мере, в Windows может быть уменьшено по требованию отдельным приложением. Это действие, связанноене только с выгодами, но и с затратами, и несетдовольно много мелкого шрифтас этим.

Так называемыебесклеточные ядра(которые имеют очень не описательное название) являются относительно новым изобретением. Ядро tickless устанавливает время тика с переменными интервалами (как можно более продолжительное в будущем). Причина в том, что ОС динамически позволяет ядрам процессора переходить в различные уровни сна как можно дольше с простой целью экономии энергии. «Различные уровни» включают обработку инструкций на полной скорости, обработку на пониженных скоростях (т. е. более медленная скорость процессора) или отсутствие обработки вообще. Разным ядрам разрешено работать с разной скоростью, и ядро tickless пытается позволить процессорам быть как можно более неактивными, даже в случаях, включающих постановку инструкций в очередь для их запуска в пакетах прерываний. Короче говоря, разным ядрам в многопроцессорной системе разрешено дрейфовать во времени относительно друг друга. Это, конечно, создает хаос для хорошего хронометража и пока является нерешенной проблемой с новыми архитектурами энергосберегающих процессоров и ядрами tickless, которые позволяют им эффективно экономить энергию. Сравните это с тикающим ядром (статический тиковый интервал), которое постоянно пробуждает все ядра процессора, независимо от того, получают ли они фактическую работу или нет, и где отсчет времени несет некоторую степень неточности, но в относительно надежной степени по сравнению с безтиковыми ядрами.

СтандартТактовое время Windows (т.е. системное разрешение) составляет 15,6 мс.вплоть до Windows 8/2012, где поведение по умолчанию было безтактовым (но можно вернуться к тикающему ядру). Я полагаю, что время тика по умолчанию в Linux зависит от компиляции ядра, ноэта нишаявляетсядалеко за пределами моего опыта(иВот этоттоже), так что вы можете дважды проверить, зависите ли вы от него. Ядра Linux, как я полагаю, скомпилированы без тактов, начиная с версии 2.6.21, и могут быть скомпилированы с различными флагами, оптимизирующими поведение без тактов (и из которых я припоминаю только несколько вариантов no_hz).

Вот вам и bare metal системы. В виртуальных системах все становится еще хуже, так как VM и гипервизор конфликтуют по-разному, что делает точный хронометраж крайне сложным. Вотобзор для VMwareивот один для RHEL KVM. То же самое справедливо и для распределенных систем. Облачные системыеще сложнеепоскольку мы даже близко не подошли к тому, чтобы увидеть настоящие гипервизоры и оборудование.

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

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

Но насколько близко мы можем подойти? Я не знаю, и это должно сильно различаться в разных системах. Определить неточность в собственных конкретных системах — задача непростая. Нужно только взглянуть накак Intel предлагает проводить бенчмаркинг кодаувидеть, что обычные системы, такие как те, которые мне приходится администрировать, в этой перспективе во многом выходят из-под контроля.

Я даже не думаю о достижении«Все функции оптимизации энергопотребления, технологии Intel Hyper-Threading, масштабирования частоты и турборежима были отключены»в критических системах, не говоря уже о возне с обертками кода на C и запуске долгосрочных тестов для получения последующих ответов. Я просто стараюсь поддерживать их в рабочем состоянии и узнавать о них как можно больше, не слишком их нарушая. Спасибо, timestamp, я знаю, что не могу доверять тебе полностью, но я знаю, что ты не слишком ошибаешься на несколько секунд. Когда фактическая точность в миллисекундах становится важной, одного измерения недостаточно, и для проверки шаблона требуется большее количество измерений. Что еще мы можем сделать?

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

Answer