Русские Блоги

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

l Временная синхронизация: также называется фазовой синхронизацией, что означает, что частота и фаза между сигналами согласованы, то есть разность фаз между сигналами всегда равна нулю.

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

PTP следует протоколу IEEE1588 и подтверждает наиболее точные часы с помощью алгоритма Best Master Clock. PTP использует аппаратную метку времени, которая может завершить синхронизацию второго импульса.

Рисунок 1 Принципиальная схема временной и частотной синхронизации

Как показано на рисунке 1, есть две таблицы Watch A и Watch B. Если время этих двух таблиц постоянно согласовано, это состояние является синхронизацией времени; если время двух таблиц не согласовано, но сохраняйте постоянное значение. (Часы B всегда на 6 часов позже, чем часы A на картинке), это состояние — синхронизация частоты.

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

По сравнению с NTP (Network Time Protocol), PTP может соответствовать требованиям к более высокой точности синхронизации времени: NTP обычно может достигать только субсекундной точности синхронизации, тогда как PTP может достигать субмикросекундного уровня.

По сравнению с GPS (Global Positioning System, Global Positioning System), PTP имеет более низкие затраты на строительство и техническое обслуживание, а поскольку он может избавиться от зависимости от GPS, он также имеет особое значение для национальной безопасности.

В настоящее время устройства H3C поддерживают только функцию синхронизации времени PTP, но не функцию синхронизации частоты. В этой статье представлены только связанные концепции и принципы синхронизации времени PTP.

Основные понятия PTP

Мы называем сеть, в которой применяется протокол PTP, доменом PTP. В домене PTP есть одни и только одни часы синхронизации, и все устройства в домене синхронизируются с этими часами.

Мы называем порт на устройстве, на котором работает протокол PTP, портом PTP. Как показано на рисунке 2, роли портов PTP можно разделить на следующие три типа:

l Главный порт: порт, который объявляет время синхронизации, которое может существовать на BC или OC.

Подчиненный порт: порт, который получает время синхронизации, которое может существовать на BC или OC.

Пассивный порт: порт, который не получает время синхронизации и не публикует время синхронизации извне. Он существует только на BC.

Узлы в домене PTP называются узлами синхронизации. Протокол PTP определяет следующие три типа основных узлов синхронизации:

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

(2) BC (Boundary Clock): этот узел синхронизации имеет несколько портов PTP в одном домене PTP для участия в синхронизации времени. Он синхронизирует время от восходящего тактового узла через один из портов и передает время нисходящему тактовому узлу через оставшиеся порты. Кроме того, когда узел синхронизации используется в качестве источника синхронизации, он может публиковать время для нисходящих узлов синхронизации через несколько портов PTP. Мы также называем это BC, как показано в BC 1 на рисунке 2.

(3) TC (прозрачные часы): по сравнению с BC / OC, BC / OC необходимо поддерживать синхронизацию времени с другими узлами часов, в то время как TC не поддерживает синхронизацию времени с другими узлами часов. TC имеет несколько портов PTP, но он только пересылает пакеты протокола PTP между этими портами и корректирует задержку пересылки, без синхронизации времени через какой-либо один порт. TC включает следующие два типа:

l E2ETC (End-to-End Transparent Clock): напрямую пересылает пакеты протокола, отличного от P2P (Peer-to-Peer), в сети и участвует в вычислении задержки всего канала Время.

l P2PTC (Peer-to-Peer Transparent Clock): только напрямую пересылает сообщения Sync, сообщения Follow_Up и сообщения Announce, а также завершает другие сообщения протокола PTP и участвует в вычислении всей ссылки. Задержка ссылки.

Как показано на рисунке 2, позиции трех вышеуказанных основных узлов синхронизации в домене PTP.

Рисунок 2 Принципиальная схема основного тактового узла

В дополнение к вышеупомянутым трем базовым узлам синхронизации, есть также несколько узлов смешанной синхронизации, например TC + OC, который сочетает в себе характеристики TC и OC: он имеет несколько портов PTP в одном домене PTP, один из которых относится к типу OC, а другие Это тип ТС. С одной стороны, он пересылает сообщения протокола PTP через порты типа TC и выполняет коррекцию задержки пересылки; с другой стороны, он синхронизирует время через порты типа OC. Подобно классификации TC, TC + OC также включает два типа: E2ETC + OC и P2PTC + OC.

Читайте так же:

Регулировка колесного редуктора маз

4. Отношения господин-раб

Отношения ведущий-ведомый (ведущий-ведомый) являются относительными. Для пары синхронизированных тактовых узлов существуют следующие отношения ведущий-ведомый:

l Узел, который публикует время синхронизации, называется главным узлом, а узел, который получает время синхронизации, называется подчиненным узлом.

l Часы на главном узле называются основными часами, а часы на ведомом узле называются ведомыми часами.

l Порт, который публикует время синхронизации, называется главным портом, а порт, который получает время синхронизации, называется подчиненным портом.

5. Оптимальные часы

Как показано на рисунке 2, все тактовые узлы в домене PTP организованы на определенном уровне, и эталонное время всего домена является оптимальным тактовым сигналом (Grandmaster Clock, GM), то есть тактовым сигналом самого высокого уровня. Благодаря взаимодействию сообщений протокола PTP между узлами синхронизации время оптимальных часов в конечном итоге будет синхронизировано со всем доменом PTP, поэтому его также называют источником часов.

Оптимальные часы можно указать статически с помощью ручной настройки или динамически выбрать с помощью протокола BMC (Best Master Clock). Процесс динамического выбора выглядит следующим образом:

(1) Благодаря оптимальному приоритету часов, уровню времени, точности времени и другой информации, передаваемой в интерактивном сообщении Announce между каждым узлом синхронизации, узел, наконец, выбирается в качестве оптимальных часов в домене PTP. В то же время каждый Также определяются отношения главный-подчиненный между узлами и портами главный-подчиненный на каждом узле. Посредством этого процесса во всем домене PTP создается полностью связное связующее дерево без петель с оптимальными часами в качестве корня.

(2) После этого главный узел будет периодически отправлять сообщения Announce на подчиненные узлы. Если подчиненный узел не получает сообщение Announce от главного узла в течение определенного периода времени, он будет считать главный узел недействительным и перезапустит оптимальные часы. s Выбор.

Принцип синхронизации PTP

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

Протокол PTP определяет два механизма измерения задержки распространения: механизм ответа на запрос (Requset_Response) и механизм задержки однорангового узла (Peer Delay), и оба эти механизма основаны на сетевой паре.

1. Механизм ответа на запрос

Рисунок 3 Процесс реализации механизма ответа на запрос

Метод запроса-ответа используется для измерения сквозной задержки. Как показано на рисунке 3, процесс реализации выглядит следующим образом:

(1) Ведущие часы отправляют сообщение синхронизации ведомым часам и записывают время передачи t1; после того, как ведомые часы получают сообщение, они записывают время приема t2.

(2) После того, как главные часы отправляют сообщение Sync, они немедленно отправляют сообщение Follow_Up, содержащее t1.

(3) Ведомые часы отправляют сообщение Delay_Req ведущим часам, чтобы инициировать вычисление задержки обратной передачи и записывают время передачи t3; после того, как ведущие часы получают сообщение, они записывают время приема t4.

(4) После получения сообщения Delay_Req главные часы отвечают сообщением Delay_Resp, содержащим t4.

В это время ведомые часы имеют четыре метки времени от t1 до t4. Отсюда общая задержка приема-передачи между ведущими и ведомыми часами может быть рассчитана как [(t2 — t1) + (t4 — t3)], потому что сеть Симметричный, поэтому односторонняя задержка между ведущими и ведомыми часами составляет [(t2 — t1) + (t4 — t3)] / 2. Следовательно, отклонение тактовых импульсов подчиненных часов относительно главных часов составляет: Смещение = (t2 — t1) — [(t2 — t1) + (t4 — t3)] / 2 = [(t2 — t1) — (t4 — t3)] / 2.

Кроме того, в зависимости от того, нужно ли отправлять сообщение Follow_Up, механизм ответа на запрос делится на одношаговый режим и двухэтапный режим:

В пошаговом режиме метка времени отправки t1 сообщения Sync переносится самим сообщением Sync, а сообщение Follow_Up не отправляется.

В двухэтапном режиме отметка времени отправки t1 сообщения Sync переносится сообщением Follow_Up.

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

2. Механизм задержки окончания

Рисунок 4 Процесс реализации механизма задержки окончания

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

Читайте так же:

Приспособа для регулировки клапанов 2108 чертеж

(3) Ведомые часы отправляют сообщение Pdelay_Req ведущим часам, чтобы инициировать вычисление задержки обратной передачи и записывать время отправки t3; после того, как ведущие часы получают сообщение, они записывают время приема t4.

(4) После получения сообщения Pdelay_Req главные часы отвечают сообщением Pdelay_Resp, содержащим t4, и записывают время передачи t5; после получения сообщения ведомые часы записывают время приема t6.

(5) После того, как главные часы ответят на сообщение Pdelay_Resp, они немедленно отправят сообщение Pdelay_Resp_Follow_Up, содержащее t5.

В это время ведомые часы имеют шесть временных меток от t1 до t6. Исходя из этого, общая задержка приема-передачи между ведущими и ведомыми часами может быть рассчитана как [(t4 — t3) + (t6 — t5)], потому что сеть является Симметричный, поэтому односторонняя задержка между ведущими и ведомыми часами составляет [(t4 — t3) + (t6 — t5)] / 2. Следовательно, отклонение тактовых импульсов подчиненных часов относительно главных часов составляет: Смещение = (t2 — t1) — [(t4 — t3) + (t6 — t5)] / 2.

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

В пошаговом режиме метка времени отправки t1 сообщения Sync переносится самим сообщением Sync, а сообщение Follow_Up не отправляется; и разница между t5 и t4 переносится в сообщении Pdelay_Resp, а сообщение Pdelay_Resp_Follow_Up не отправляется.

В двухэтапном режиме метка времени отправки t1 сообщения Sync переносится сообщением Follow_Up, тогда как t4 и t5 переносятся сообщением Pdelay_Resp и сообщением Pdelay_Resp_Follow_Up соответственно. к

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

Active Directory Настройка синхронизации времени в домене

Топология синхронизации времени среди участников Active Directory

Среди компьютеров, участвующих в Active Directory работает следующая схема синхронизация времени.

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

Корневой PDC может синхронизировать свое время как со внешним источником, так и с самим собой, последнее задано конфигурацией по умолчанию и является абсурдом, о чем периодически намекают ошибки в системном журнале.

Синхронизация клиентов корневого PDC может осуществятся как с его внутренних часов, так и с внешнего источника. В первом случае сервер времени корневого PDC объявляет себя как «надежный» (reliable).

Далее я приведу оптимальную с моей точки зрения конфигурацию сервера времени корневого PDC, при которой сам корневой PDC периодически синхронизирует свое время от достоверного источника в интернете, а время обращающихся к нему клиентов синхронизирует со своими внутренними часами.

Конфигурация NTP-сервера на корневом PDC

Конфигурирование сервера времени (NTP-сервера) может осуществляться как с помощью утилиты командной строки w32tm, так и через реестр. Где возможно, я приведу оба варианта.

Включение синхронизации внутренних часов с внешним источником

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters]
«Type»=»NTP»
w32tm /config /syncfromflags:manual

Подробности — в библиотеке TechNet.

Объявление NTP-сервера в качестве надежного

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfig]
«AnnounceFlags»=dword:0000000a
w32tm /config /reliable:yes

Подробности — в библиотеке TechNet.

Включение NTP-сервера

NTP-сервер по умолчанию включен на всех контроллерах домена, однако его можно включить и на рядовых серверах.

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpServer]
«Enabled»=dword:00000001

Задание списка внешних источников для синхронизации

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters]
«NtpServer»=»time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 ru.pool.ntp.org,0x8»
w32tm /config /manualpeerlist:»time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 ru.pool.ntp.org,0x8″

Флаг 0×8 на конце означает, что синхронизация должна происходить в режиме клиента NTP, через предложенные этим сервером интервалы времени. Для того, чтобы задать свой интервал синхронизации, необходимо использовать флаг 0×1. Все остальные флаги описаны в библиотеке TechNet.

Задание интервала синхронизации с внешним источником

Время в секундах между опросами источника синхронизации, по умолчанию 900с = 15мин. Работает только для источников, помеченных флагом 0×1.

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpClient]
«SpecialPollInterval»=dword:00000384

Установка минимальной положительной и отрицательной коррекции

Максимальная положительная и отрицательная коррекция времени (разница между внутренними часами и источником синхронизации) в секундах, при превышении которой синхронизация не происходит. Рекомендую значение 0xFFFFFFFF, при котором коррекция сможет производиться всегда.

Все необходимое одной строкой

Полезные команды

Применение внесенных в конфигурацию службы времени изменений
w32tm /config /update
Принудительная синхронизация от источника
w32tm /resync /rediscover
Отображение состояния синхронизации контроллеров домена в домене
w32tm /monitor
Отображение текущих источников синхронизации и их статуса
w32tm /query /peers

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

Контроллеры домена, работающие в виртуализированной среде, требуют к себе особенного отношения.

Страна Админа

За 2020 год из пары десятков тысяч посетителей, набралось всего пару десятков перечислений от 50 до 300 рублей.

Пустяк в денежном выражении, но большая ценность для автора. Посмотрим что год грядущий нам готовит ))

Сумма абсолютно не важна — главное участие.

Читайте так же:

Регулировка распредвалов 405 двигатель

NTP в домене Windows

Текст:

Казалось бы, по теме синхронизации времени в домене Windows написаны десятки подробных статей статей, например, качественная How the Windows Time Service Works.

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

Начнем. Зачем нам в домене нужно точное время на всех компьютерах?

Во-первых из-за Kerberos. Компьютер начинает проверку своей подлинности на контроллере с посылки Authentication Service Request (AS_REQ). Составной частью пакета является зашифрованная отметка времени. На котроллере домена отметка времени сравнивается с текущим временем системы и при разнице более 300 секунд запрос отклоняется. Эта мера безопасности затрудняет передачу измененных AS_REQ.

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

Если в первом случае, достаточно синхронизировать время внутри домена, то во втором необходима также синхронизация с внешним источником точного времени. Это может быть собственный NTP сервер, построенный на базе устройств спутниковой навигации GPS или ГЛОНАСС. Но обычно используются бесплатные NTP сервера доступные в Интернет.

В теории все получается просто, при вводе в домен на компьютерах автоматически настраиваются параметры и все клиентские станции начинают синхронизировать свое время с домен контроллером на котором они прошли аутентификацию. В свою очередь контроллеры домена синхронизируются с контроллером на котором находится FSMO роль PDC. По умолчанию, PDC синхонизируется с time.windows.com и его необходимо вручную настроить на нужный источник. Чтобы разобраться в текущей ситуации, можно последовательно выполнить команду

w32tm /query /peers

на рабочей станции, на домен контроллере с которого она берет время и на PDC.

Поняв текущую схему, можно переходить к изменениям настроек. Здесь нужно понимать, что есть сервис Windows Time (W32Time) и его субкомпонент который переводит часы на компьютере или изменяет их тактовую частоту. Сейчас мы будем говорить о настройках W32Time касающихся работы с NTP серверами.

Настройки расположены в двух разделах реестра:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32Time

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftW32Time

При установке ОС создается только первый раздел, второй появляется при применении локальной или доменной политики и имеет приоритет. Из командной строки настройки Windows Time можно помотреть командой w32tm /query /configuration. Причем, настройки взятые из первого раздела будут отображаться с отметкой (Local), из второго с отметкой (Policy).

Настройки достаточно подробно описаны в Windows Time Service Tools and Settings. У меня, сложности вызвал, параметр HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParametersNtpServer

Он представляет собой перечисление NTP серверов с которыми может синхронизироваться данный сервер. Каждый сервер представляет собой IP адрес или DNS имя, а также флаг, относящийся к данному NTP серверу. Флаг следует после имени сервера и отделяется от него запятой. Сервера в строке разделяются пробелами. (Внимание. Допустим только один пробел, двойной пробел считается концом строки и имена серверов после него не рассматриваются).

ntp1.vniiftri.ru,0x02 ntp2.vniiftri.ru,0x02 ntp3.vniiftri.ru,0x02 ntp4.vniiftri.ru,0x02

Используется два основных флага 0x01 и 0x02.

0x01 SpecialInterval

От этого флага зависит как будет Windows Time использоват параметры:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpClientSpecialPollInterval

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

При отсутствии флага будет использоваться динамический интервал, ограниченный параметрами MinPollInterval и MaxPollInterval (двоичный логарифм от секунд, например, значение параметра 6 значит опрос сервера будет происходит через 2 в степени 6 = 64 секунды).

Посмотреть интервалы опроса и время оставшееся до следующего опроса можно командой w32tm /query /peers — строки PeerPoll Interval и Time Remaining.

Еще раз подчеркну, что интервалы отосятся к опросу NTP серверов, а не к обновлению времени системы.

Имеются неожиданные последствия, если все сервера указать с данным флагом — они перейдут в статус Pending. Если выполнить команду w32tm /monitor то можно увидеть, что RefId изменился на ‘LOCL’ [0x4C434F4C]. То есть, сервер не стал синхронизироваться с внешними NTP и выбрал источником синхронизации Local CMOS Clock (идентификатор этого источника 0x4C434F4C). С таким сервером часть клиентов синхронизироваться не будет, например, UNIXы в зависимости от настроек.

0x02 UseAsFallbackOnly

По моему мнению, данный флаг сделан специально для запутывания процесса. Предполагается, что помеченные этим флагом сервера будут опрашиваться только в случае неудачного опроса основных серверов (без флага 0x02). Но на практике реакция на данный флаг непредсказуема.

Я рекомендую не указывать никаких флагов, а просто задать имена серверов разделенные пробелами:

ntp1.vniiftri.ru ntp2.vniiftri.ru ntp3.vniiftri.ru ntp4.vniiftri.ru

и управлять частотой опроса через параметры MinPollInterval и MaxPollInterval

Все настройки сделанные в реестре вручную либо через политику вступают в силу после рестарта сервиса W32Time.

Собственно все, про NTP, в реализации от Микрософт.

Теперь немного о субкомпоненте (clock discipline subcomponent) который переводит локальные часы системы или изменяет их тактовую частоту в соответствии с данными NTP.

Он также настраивается через реестр, выше была приведена статья с описанием настроек, к данному субкомпоненту относятся:

FrequencyCorrectRate
HoldPeriod
LargePhaseOffset
MaxAllowedPhaseOffset
MaxNegPhaseCorrection
MaxPosPhaseCorrection
PhaseCorrectRate
PollAdjustFactor
SpikeWatchPeriod
UpdateInterval

Читайте так же:

Самоходная косилка е 302 регулировка сцепления

В большинстве случаев их изменение не требуется.

Но иногда таки приходится.

Например, параметр MaxAllowedPhaseOffset (по умолчанию 300 секунд) управляет способом перевода локальных часов. Если расхождение между локальным временем и NTP источником меньше MaxAllowedPhaseOffset то W32Time пытается скорректировать время изменением тактовой частоты часов. Если — больше то локальное время переводится согласно полученному от NTP сервера.

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

Лучше попробовать способ с изменением тактовой частоты, для этого в первую очередь нужно установить MaxAllowedPhaseOffset = 350. Это необходимое, но недостаточное условие. Также должно выполнятся соотношение:

|CurrentTimeOffset| / (PhaseCorrectRate*UpdateInterval) < SystemClockRate / 2

SystemClockRate получим командой w32tm /query /status /verbose строка вывода ClockRate: 0.0156250s переведем секунды в такты ОС (1ms = 10000 тактов): 0.0156250s*1000*10000 = 156250 тактов.

В XP w32tm /query еще не поддерживается и значение SystemClockRate можно взять из реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeConfigLastClockRate

Выполняем команду w32tm /query /configuration — берем строки вывода UpdateInterval: 100 и PhaseCorrectRate: 1 (можно взять эти же значения из реестра).

UpdateInterval — по единицам измерения данной величины в источниках от Микрософт есть противоречие. В вышеприведенной статье указано, что величина измеряется в тактах и ее нужно подставлять в формулу как есть. В описании групповой политики единица измерения указана 1/100 секунды. В микрософтовском примере значение UpdateInterval используется без пересчета (по моим опытам это действительно так). PhaseCorrectRate — скалярная величина используем ее как есть.

Подставляем в условие:

|3200 000 000| / (1*100) < 156250 / 2

32 000 000 < 78125 не выполняется.

Подберем значение UpdateInterval с которым условие будет выполняься = 40960. Сделаем запас и установим UpdateInterval = 45000.

|3200 000 000| / (1*45000) < 156250 / 2

71111 < 78125 второе условие выполнено.

Изменяем значение UpdateInterval в реестре, перезапускаем сервис W32Time. Устраняем причину неработоспособности NTP (если необходимо выполняем w32tm /resync) и . локальные часы начинают плавно синхронизироваться, путем корректировки тактовой частоты.

Выявить такие ситуации можно анализируя сетевой трафик, например с помощью Network Monitor. Будет видно, что ваш сервер посылает правильный запрос, а в ответ ему ничего не приходит.

P.S. Аналогично time.windows.com и часть серверов ru.pool.ntp.org

Да, внутренние настройки —

Опубликовано 27 марта, 2018 — 09:28 пользователем Николай (не проверено)

Да, внутренние настройки — это хорошо, но и это очень важный момент:

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

Проблема как раз в обнаружении проблемы. Я на простом домашнем компе написал батник, который синхронизирует время и засунул ярлык в автозагрузку. Когда внешне всё в порядке, то всё нормально синхронизируется. После этого службу даже можно остановить, чтобы не путалась под ногами. А если внешний сервер отвалится? w32tm об этом сообщит и завершит работу вроде бы штатно, при этом errorlevel=0. И окно cmd закроется, тем более, что оно у меня вообще свёрнуто. И я буду думать, что синхронизация продолжается. А как сделать так, чтобы неудачная попытка синхронизации изменяла поведение батника?

На вопрос так как он

Опубликовано 28 марта, 2018 — 17:52 пользователем manager

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

1. служба w32time остается включенной и настраивается на требуемый режим синхронизации, под ногами она совершенно не путается, это не какой-нибудь там windows search или diagnostic policy

2. в task scheduler регулярно запускается bat файл сверяющий время на локальном компьютере и ntp сервере при помощи команды w32tm /stripchart /computer:ntp1.vniiftri.ru /dataonly /samples:2

вывод там будет такой

The current time is 28.03.2018 17:40:53.
17:40:53, +00.3551899s

его можно распарсить и при расхождении во времени больше заданного выдавать оповещение

А как синхронизировать время

Опубликовано 12 апреля, 2018 — 10:32 пользователем Bob (не проверено)

А как синхронизировать время на сетевых устройствах (принтера, свитчи, камеры) с контроллером домена? Их в домен не добавить и реестра у них нет.

Клиентом может быть любое

Опубликовано 12 апреля, 2018 — 10:48 пользователем manager

Клиентом может быть любое устройство поддерживающее протокол NTP.

Вводить в домен не обязательно.

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

Как синхронизировать часы VMWare VM?

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

Кто-нибудь еще заметил это? Что делают другие люди, чтобы держать свое VM время в синхронизации?

Читайте так же:

Регулировка фар санг енг актион нью

Edit: это CLI linux VMs кстати..

11 ответов

VMware ESXi: автоматический перезапуск VM

Вот у меня есть машина с VMware ESXi 5. Один из моих VMs выключается через некоторое время (я не могу этого предотвратить). Однако я хочу, чтобы VM был автоматически перезапущен, если он был выключен. Но я не могу найти вариант в моем клиенте vSphere, чтобы сделать это. Так есть ли способ сделать.

Допустим, я получаю двоичный сигнал в цифровом виде, где логический 1 передается как наличие сигнала, а логический 0 передается как отсутствие сигнала. Продолжительность времени логического 1 такая же, как и логического 0, но часы передатчика могут дрейфовать, немного отличаясь от 1 или 0.

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

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

Чтобы это сработало, вам необходимо установить инструменты VMWare в вашем гостевом OS.

согласно базе знаний VMware, фактическое решение зависит от дистрибутива Linux и выпуска, в RHEL 5.3 я обычно редактирую /etc/grub.conf и добавляю эти параметры к записи kernel: divider=10 clocksource=acpi_pm

Затем включите NTP, отключите синхронизацию времени VMware из vmware-toolbox и, наконец, перезагрузите VM

Полную таблицу с рекомендациями для каждого дистрибутива Linux можно найти здесь:

Здесь есть что отметить. У нас была та же проблема с Windows VM, работающим на хосте ESXi. Синхронизация времени была включена в инструментах VMWare для гостя, но гостевые часы были последовательно выключены (примерно на 30 секунд) от часов хоста. Узел ESXi был настроен для получения обновлений времени от внутреннего сервера времени.

Оказывается, у нас была включена настройка времени в Интернете в Windows VM (Панель управления > Дата и время > вкладка Время в Интернете), поэтому гость получал обновления времени из двух мест, и время в Интернете выигрывало. Мы выключили это, и теперь гостевые часы хороши, получая свое время исключительно от хозяина ESXi.

Я отвечу за Windows гостей. Если у вас установлено VMware инструмента, то в области уведомлений панели задач (рядом с часами) есть значок для VMware инструментов. Дважды щелкните по нему и задайте параметры.

Если у вас не установлены инструменты VMware, вы все равно можете настроить синхронизацию времени в Интернете с некоторым сервером NTP. Если ваша физическая машина обслуживает протокол NTP для ваших гостевых машин, вы можете сделать это с помощью сети только для хостов. В противном случае вам придется разрешить вашим гостям синхронизироваться с подлинным сервером NTP в Интернете, например time.windows.com.

В моем случае мы запускаем VMWare Server 2.02 на Windows Server 2003 R2 Standard. Хост также является стандартом Windows Server 2003 R2. У меня были инструменты VMware, установленные и настроенные на синхронизацию времени. Я сделал все, что только можно себе представить, что нашел на различных интернет-сайтах. У нас все еще был ужасный дрейф, хотя он сократился с 15 минут или более до 3 или 4 минут.

Наконец, в vmware.log я нашел эту запись (находится в папке как файл .vmx): «Ваша хост-система не гарантирует синхронизацию TSCs между различными CPUs, поэтому, пожалуйста, установите параметр /usepmtimer в файле Windows Boot.ini, чтобы обеспечить надежность хронометража. См. Microsoft KB http://support.microsoft.com/kb . для получения подробной информации и Microsoft KB http://support.microsoft.com/kb . для получения дополнительной информации.»

Причина: Эта проблема возникает, когда на компьютере включена технология AMD Cool’n’Quiet (AMD двухъядерных процессоров) в BIOS или некоторых многоядерных процессорах Intel. Многоядерные или многопроцессорные системы могут столкнуться с дрейфом счетчика временных меток (TSC), когда время между различными ядрами не синхронизировано. В операционных системах, использующих TSC в качестве ресурса хронометража, может возникнуть проблема. Более новые операционные системы обычно не используют TSC по умолчанию, если в системе доступны другие таймеры, которые можно использовать в качестве источника хронометража. Другие доступные таймеры включают PM_Timer и Высокоточный таймер событий (HPET). Решение: Чтобы устранить эту проблему, обратитесь к поставщику оборудования, чтобы узнать, доступно ли новое обновление драйвера/встроенного ПО для устранения проблемы.

Примечание. Установка драйвера может добавить переключатель /usepmtimer в файл Boot.ini.

Как только это (переключатель/usepmtimer) было сделано, часы остановились вовремя.

Как сохранить VMware Fusion VM?

Я работаю над созданием 3 VM версий XP с IE6, 7 и 8 отдельно для моей команды. Я начал со старого образа VMware, который у нас был с IE6 и SP2, и прошел через него и настроил его со всем необходимым, оставив IE6. Теперь мне нужно продублировать этот VM и впоследствии обновить его до IE7 и 8 на.

Я новичок в raspberry pi, пытаюсь отправить поток битов от отправителя к получателю. Однако биты в большинстве случаев не принимаются в правильном порядке, они, кажется, немного сдвинуты. Я думаю, что не могу правильно их синхронизировать. Кто-нибудь знает, как я могу синхронизировать часы Python.

голоса

Рейтинг статьи

Русские Блоги