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

[EDIT] Крупная перезапись со ссылками, так как я только что записал из памяти старый ответ.

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

Длинный ответ: BIG FAT DISCLAIMER Это ответ мирянина. Я обычный сисадмин с обычным сисадминским видом на компьютеры. В этом ответе я нахожусь на территории, выходящей далеко за пределы моих профессиональных возможностей, и любые выводы должны быть тщательно изучены. Тем не менее, я постараюсь дать ссылки на высказывания, которые я делаю, связывая источники с глубокой тематикой. Возможно, даже то, что я неправильно понял соответствующие части и полностью упустил другие. Такова непрофессионализм. Я думаю, что, скорее всего, профессиональный уровень знаний может быть востребован разработчиками ядра и архитекторами аппаратного обеспечения.

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

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

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

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

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

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

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

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

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

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

OK. Что мы можем сделать?

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

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

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

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

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

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

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

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

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

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

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

• Обновление счетчика тиков, используемого, например, при измерении длительности выполнения кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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