Новостной и аналитический портал "время электроники". Протоколы синхронизации времени: NTP, IRIG, AFNOR Протокол ptp для синхронизации

Много статей написано про всем известный Network Time Protocol (NTP), в некоторых из них упоминается про Precision Time Protocol, который якобы позволяет добиться точности синхронизации времени порядка наносекунд (например, и ). Давайте разберемся, что этот протокол собой представляет и как достигается такая точность. А также посмотрим результаты моей работы с данным протоколом.

Введение

«Протокол точного времени» описан стандартом IEEE 1588 . Существует 2 версии стандарта. Первая версия вышла в 2002 году, затем стандарт был пересмотрен в 2008 и на свет вышел протокол PTPv2. Обратная совместимость не была сохранена.
Я работаю со второй версией протокола, в ней множество улучшений по сравнению с первой (точность, стабильность, как нам сообщает wiki). Не буду приводить сравнения с NTP, одно только упоминание о точности синхронизации, а точность PTP достигает действительно десятков наносекунд при «железной» поддержке, говорит о преимуществе перед NTP.
«Железная» поддержка протокола в разных устройствах может быть реализована по-разному. На самом деле минимум, требующийся для реализации PTP – умение «железки» проставлять таймштамп момента получения сообщения на порт. Проставленное время будет использовано для вычисления ошибки.

Почему часы расстраиваются?

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

Чего мы добиваемся?

Допустим, у нас есть устройство, работающее в идеальных условиях, какие-нибудь атомные часы, которые вообще не разойдутся до конца света (конечно же, до реального, а не предначертанного календарём Майя) и дана задача заполучить хотя бы примерно (с точностью до 10 -9 сек) такие же часы. Нам нужно эти часы синхронизировать. Для этого можно реализовать протокол PTP.

Разница чисто программной реализации и реализации с «железной поддержкой»

Чисто программная реализация не позволит добиться обещаемой точности. Время, прошедшее с момента получения сообщения (точнее получения сигнала на прием сообщения в устройстве) до перехода на точку входа в прерывание или на callback не может быть строго определенным. «Умные железки» с поддержкой PTP умеют проставлять эти таймштампы самостоятельно (например, чипы от Micrel , как раз для KSZ8463MLI я пишу драйвер).
Помимо таймштампов к «железной» поддержке также можно отнести умение настраивать кварцевый генератор (чтобы выровнять частоту с мастером), либо возможность подстройки часов (каждый такт увеличивать значение часов на X нс). Об этом ниже.

Перейдём к стандарту IEEE 1588

Стандарт описан аж на 289 страницах. Рассмотрим минимум, необходимый для реализации протокола. PTP является клиент-серверным протоколом синхронизации, т.е. для реализации протокола требуется как минимум 2 устройства. Итак, Master-устройство - атомные часы, а Slave устройство – часы, которые необходимо заставить работать точно.

Язык обмена

Announce message – сообщение анонса, содержит информацию, отправляемую мастером всем Slave устройствам. Slave устройство с помощью этого сообщения может выбрать лучшего мастера (для этого существует BMC (Best Master Clock)) алгоритм. BMC не так интересен. Этот алгоритм можно легко найти в стандарте. Выбор идет по таким полям сообщения как точность, дисперсия, класс, приоритет и т.п. Перейдём к другим сообщениям.

Sync/Follow Up, DelayResp, PDelayResp/PDelayFollowUp – отправляются мастером, ниже рассмотрим их поподробнее.

DelayReq, PDelayReq – запросы Slave устройств.

Как видим, Slave устройство не многословно, Master предоставляет всю практически всю информацию сам. Отправка осуществляется на Multicast (при желании можно использовать Unicast режим) адреса, строго определенные в стандарте. Для PDelay сообщений имеется отдельный адрес (01-80-C2-00-00-0E для Ethernet и 224.0.0.107 для UDP). Остальные сообщения отсылаются на 01-1B-19-00-00-00 или 224.0.1.129. Пакеты отличаются полями ClockIdentity (идентификатор часов) и SequenceId (идентификатор пакета).

Сеанс работы

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

Всё начинается с того, что Master отправляет сообщение Sync и одновременно записывает время отправки t1. Существует одно- и двухэтапные режимы работы. Отличить их очень легко: если присутствует сообщение FollowUp – то мы имеем дело с двухэтапной реализацией, пунктирной стрелкой показаны необязательные сообщения
FollowUp сообщение отправляется вслед за Sync и содержит время t1. Если осуществляется передача в один этап, то Sync содержит t1 в теле сообщения. В любом случае t1 будет получено нашим устройством. В момент получения сообщения Sync на Slave генерируется таймпштамп t2. Таким образом мы получаем t1, t2
Slave генерирует сообщение DelayReq одновременно с генерацией t3
Master получает DelayReq сообщение, одновременно генерируя t4
t4 отправляется Salve устройству в DelayResp сообщении

Сообщения в сети

С помощью такого сеанса обмена, который показан выше, можно добиться успеха только в случае, если кварц генерирует идеально одинаковые частоты для синхронизируемых устройств. На деле же получается что частота часов разная, т.е. на одном устройстве за 1 секунду значение часов увеличится на 1 секунду, а на другом, например, на 1.000001 секунду. Отсюда появляется расхождение часов.
В стандарте описан пример вычисления отношения времени, прошедшего на Master и на Slave за определенный интервал. Это отношение будет являться коэффициентом для частоты Slave устройства. Но при этом есть указание, что подстройка может осуществляться различными способами. Рассмотрим два из них:

Изменить тактовую частоту Slave устройства (пример в стандарте)
Не менять тактовую частоту, но за каждый такт длительностью T значение часов будет увеличиваться не на T, а на T+∆t (используется в моей реализации)

В обоих способах потребуется вычислить разницу в значениях времени на Master устройстве за определенный интервал, а также разницу во времени, за этот же интервал на Slave устройстве. Коэффициент в первом способе:

Для второго способа требуется вычисление ∆t. ∆t – величина, которая будет складываться со значением времени каждый определенный интервал. На рисунке можно заметить, что в то время как на мастере прошло 22 – 15 = 7 секунд, на Slave прошло 75+(87-75)/2 –(30+ (37-30)/2) = 47.5

Частота – частота процессора, например, 25МГц - цикл процессора длится 1/(25*10 6) = 40нс.
В зависимости от возможностей устройства выбирается наиболее подходящий способ.
Чтобы перейти к следующему разделу, выразим смещение немного по-другому:

Режимы работы PTP

Заглянув в стандарт, можно обнаружить не единственный способ вычисления времени доставки. Существуют 2 режима работы PTPv2. Это E2E (End-to-End) , он был рассмотрен выше, также описан режим P2P (Peer-to-Peer) . Давайте разберемся, где какой способ применять и в чем их различие.
В принципе можно использовать любой из режимов по желанию, но их нельзя совмещать в одной сети.

В режиме E2E время доставки вычисляется по сообщениям, пришедшим через множество устройств, каждый из которых проставляет в поле коррекции сообщения Sync либо FollowUP (если двухэтапная передача) время, на которое пакет задержался на этом устройстве (если устройства подключены напрямую, коррекция не проставляется, поэтому их детально рассматривать не будем). Используются сообщения: Sync/FollowUp, DelayReq/DelayResp
В режиме P2P в поле коррекции заносится не только время, на которое задержался пакет, к нему прибавляется (t2-t1) (можно почитать в стандарте). Используются сообщения Sync/FollowUp, PDelayReq/PDelayResp/PDelayRespFollowUp

Согласно стандарту, часы, сквозь которые PTP сообщения проходят с изменением поля коррекции, называются Transparent Clock (TC) . Посмотрим на рисунках, как передаются сообщения в этих двух режимах. Синими стрелочками указаны сообщения Sync и FollowUp .

Режим End-to-End

Режим Peer-to-Peer
Видим, что в P2P режиме появились какие-то красные стрелочки. Это оставшиеся сообщения, которые мы не рассмотрели, а именно PDelayReq , PDelayResp и PDelayFollowUp . Вот сеанс обмена этими сообщениями:

Ошибка времени доставки

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

Что требуется фильтровать:

Время доставки
Смещение

В моем драйвере используется примерно такая же система фильтрации, как и в Linux демоне PTPd , исходники которого можно найти еще есть немного информации . Приведу лишь схему:

LP IIR (Infinite Impulse Response low-pass) фильтр (Фильтр с бесконечной импульсной характеристикой), описываемый формулой:

, где s – коэффициент, позволяющий регулировать срез фильтра.

Вычисление подстройки

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

Я использовал фильтр Калмана, чтобы отфильтровать сильное дрожание подстройки из-за помех в сети, уж больно понравилась мне . А вообще, можно использовать любой фильтр, который нравится, главное чтобы сглаживал график. В PTPd , например, фильтрация попроще - вычисляется среднее от текущего и предыдущего значения. На графике можно посмотреть результаты работы фильтра Калмана в моем драйвере (показана ошибка подстройки, выражена в субнаносекундах на 25МГц чипе):

Переходим к регулированию подстройки, подстройка должна стремиться к константе, используется ПИ-регулятор. В PTPd регулируется смещения часов (настройка идёт по смещению), но я использую его для регулирования подстройки (особенность KSZ8463MLI). Видим, что контроллер настроен не идеально, но в моем случае такая регулировка достаточна:

Результат работы

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

09.07.2012, Пн, 10:07, Мск

Основная проблема в транспортных сетях нового поколения - то, что технология Ethernet изначально проектировалась для локальных вычислительных сетей и никогда не была предназначена для передачи сигналов синхронизации. В сетях с коммутацией каналов в последние десятилетия как транспортная среда доминирует технология синхронной цифровой иерархии (SDH), в ее основу заложена передача синхросигналов. Но даже эта надежная и хорошо себя зарекомендовавшая технология не отвечает требованиям современных приложений.

страницы: предыдущая | | 2

Использование стандарта Sync Ethernet

Изначально технология Ethernet разрабатывалась исключительно для использования в локальных сетях. Методы линейного кодирования информации на физическом уровне выбирались в соответствии с задачами, которые не предполагали передавать синхросигнал. В сетях SDH изначально использовались линейные коды NRZ, которые приспособлены для передачи синхронизации на физическом уровне канала связи. При создании технологии Sync Ethernet физический уровень и методы кодирования были заимствованы у технологии SDH, а второго (канального) уровня изменения практически не коснулись. Структура кадров осталась неизменной, за исключением SSM-байта статуса синхронизации. Его значения также были заимствованы в технологии SDH.

Принцип передачи синхронизации по протоколу Sync Ethernet

К преимуществам технологии Sync Ethernet можно отнести использование SDH-структуры физического уровня, а вместе с этим - огромный и бесценный опыт проектирования и построения сетей тактовой сетевой синхронизации. Идентичность методов сохранила актуальность старых рекомендаций G.803, G.804, G.811, G.812 и G.813 в новой технологии. Дорогие устройства - первичные эталонные генераторы (ПЭГ), вторичные задающие генераторы (ВЗГ) - могут быть задействованы также и в новой транспортной сети, построенной на стандарте Sync Ethernet.

Типовая схема синхронизации с использованием технологии Sync Ethernet

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

Использование протокола PTP (IEEE1588v2)

И последний способ передачи синхронизации, который в последнее время становится все более популярным, - это протокол Precise Time Protocol (PTP). Он описан в рекомендации IEEE 1588. В 2008 году вышла вторая версия этого документа, которая описывает использование протокола в телекоммуникационных сетях. Precise Time Protocol достаточно молодой, но сама технология передачи времени была заимствована у протокола Network Time Portocol (NTP). Протокол NTP в своей последней версии не дает точность, которая необходима для современных приложений, и поэтому он остался хорошим средством для временной синхронизации, которое широко используется в синхронизации серверов, распределенных баз данных и т.д. Но в построении сети тактовой сетевой синхронизации подходит логическое продолжение протокола NTP - это протокол PTP. Сетевыми элементами, которые участвуют во взаимодействии по протоколу PTP, являются следующие устройства: PTP Grand Master и PTP Slave. Обычно Grand Master берет синхронизацию от GNSS приемника и, используя эту информацию, обменивается пакетами с Slave устройством и постоянно корректирует временные расхождения между Grand Master и Slave устройствами. Чем активнее будет этот обмен, тем точность корректировки будет выше. Минусом такого активного обмена является увеличение полосы пропускания, которая выделяется для протокола PTP. Самой главной проблемой в расчете расхождения временных интервалов является то, что между устройствами Grand Master и Slave могут стоять "классические" маршрутизаторы 3 уровня. Термин "классические" в данном случае употреблен для того, чтобы подчеркнуть, что данные устройства ничего не понимают в протоколе PTP 5 уровня.

Задержками в буферах таких маршрутизаторов управлять достаточно сложно, и они носят случайный характер. Для того чтобы осуществлять контроль над этими случайными ошибками, а также чтобы расчет расхождения времени между Grand Master и Slave был точнее, в протоколе PTP был введен специальный параметр - метка времени (Time Stamp). Эта метка указывает на время прохождения пакета через маршрутизатор. Если на всем пути от Grand Master до Slave маршрутизаторы будут обладать функциональностью PTP и выставлять метку времени, то случайную ошибку, связанную с прохождением пакетов PTP через IP сеть, можно будет свести к минимуму.

Пример построения сети синхронизации на протоколе PTP

Сравнение методов передачи синхронизации в пакетных сетях нового поколения

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

Технология	Преимущества	Недостатки
GNSS	Предоставление частотной, фазовой и временной синхронизации. Не зависит от нагрузки сети.	Обязательная установка антенны. Невозможность использования в закрытых помещениях. Возможные помехи от других радиоустройств. Резервирование предоставляется только установкой второго приемника GNSS
Sync Ethernet	Не зависит от нагрузки сети. Схожесть с сетью SDH	Предоставляет только частотную синхронизацию. Необходима поддержка Sync Ethernet всеми элементами сети
PTP	Предоставление частотной, фазовой и временной синхронизации.	Зависит от загрузки сети.

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

Михаил Вексельман

страницы: предыдущая | | 2

Network Time Protocol — сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной латентностью, основанных на коммутации пакетов.

Хотя традиционно NTP использует для своей работы протокол UDP, он также способен работать и поверх TCP. Система NTP чрезвычайно устойчива к изменениям латентности среды передачи.

Время, представляется в системе NTP 64-битным числом, состоящим из 32-битного счетчика секунд и 32-битного счетчика долей секунды, позволяя передавать время в диапазоне 2 32 секунд, с теоретической точностью 2 -32 секунды. Поскольку шкала времени в NTP повторяется каждые 2 32 секунды (136 лет), получатель должен хотя бы примерно знать текущее время (с точностью 68 лет). Также следует учитывать, что время отсчитывается с полуночи 1 января 1900 года, а не с 1970, поэтому из времени NTP нужно вычитать почти 70 лет (с учетом високосных лет), чтобы корректно совместить время с Windows или Unix-системами.

Как это работает

NTP-серверы работают в иерархической сети, каждый уровень иерархии называется ярусом (stratum). Ярус 0 представлен эталонными часами. За эталон берется сигнал GPS (Global Positioning System) или службы ACTS (Automated Computer Time Service). На нулевом ярусе NTP-серверы не работают.

NTP-серверы яруса 1 получают данные о времени от эталонных часов. NTP-серверы яруса 2 синхронизируются с серверами яруса 1. Всего может быть до 15 ярусов.

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

Иерархическая структура протокола NTP является отказоустойчивой и избыточной. Рассмотрим пример его работы. Два NTP-сервера яруса 2 синхронизируются с шестью различными серверами яруса 1, каждый — по независимому каналу. Внутренние узлы синхронизируются с внутренними NTP-серверами. Два NTP-сервера яруса 2 координируют время друг с другом. В случае отказа линии связи с сервером яруса 1 или с одним из серверов уровня 2 избыточный сервер уровня 2 берет на себя процесс синхронизации.

Аналогично узлы и устройства яруса 3 могут использовать любой из серверов яруса 2. Что еще более важно, так это то, что наличие избыточной сети серверов NTP гарантирует постоянную доступность серверов времени. Синхронизируясь с несколькими серверами точного времени, NTP использует данные всех источников, чтобы высчитать наиболее точное временя.

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

В 2005 году была начата работа по изменению стандарта IEEE1588-2002 с целью расширения возможных областей его применения (телекоммуникации, беспроводная связь и в др.). Результатом работы стало новое издание IEEE1588-2008, которое доступно с марта 2008 со следующими новыми особенностями:

Усовершенствованные алгоритмы для обеспечения погрешностей в наносекундном диапазоне.
Повышенное быстродействие синхронизации времени (возможна более частая передача сообщений синхронизации Sync).
Поддержка новых типов сообщений.
Ввод однорежимного принципа работы (не требуется передачи сообщений типа FollowUp).
Ввод поддержки функции т.н. прозрачных часов для предотвращения накопления погрешностей измерения при каскадной схеме соединения коммутаторов.
Ввод профилей, определяющих настройки для новых областей применения.
Возможность назначения на такие транспортные механизмы как DeviceNet, PROFInet и IEEE802.3/Ethernet (прямое назначение).
Ввод структуры TLV (тип, длина, значение) для расширения возможных областей применения стандарта и удовлетворения будущих потребностей.
Ввод дополнительных опциональных расширений стандарта.

Принцип функционирования систем на основе протокола PTP

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

Рис. 1. Согласно протоколу PTP синхронизация устройств по времени осуществляется на основе схемы «ведущий - ведомый».

Процедура синхронизации согласно протоколу PTP подразделяется на два этапа. На первом этапе осуществляется коррекция разницы показаний времени между ведущими и ведомыми часами - то есть осуществляется так называемая коррекция смещения показаний времени. Для этого ведущее устройство осуществляет передачу сообщения для целей синхронизации времени Sync ведомому устройству (сообщение типа Sync). Сообщение содержит в себе текущее показание времени ведущих часов и его передача осуществляется периодически через фиксированные интервалы времени.

Однако поскольку считывание показаний ведущих часов, обработка данных и передача через контроллер Ethernet занимает некоторое время, информация в передаваемом сообщении к моменту его приема оказывается неактуальной. Одновременно с этим осуществляется как можно более точная фиксация момента времени, в который сообщение Sync уходит от отправителя, в составе которого находятся ведущие часы (TM1). Затем ведущее устройство осуществляет передачу зафиксированного момента времени передачи сообщения Sync ведомым устройствам (сообщение FollowUp). Те также как можно точнее осуществляют измерение момента времени приема первого сообщения (TS1) и вычисляют величину, на которую необходимо выполнить коррекцию разницы в показаниях времени между собою и ведущим устройством соответственно (O) (см. рис. 1 и рис. 2). Затем непосредственно осуществляется коррекция показаний часов в составе ведомых устройств на величину смещения. Если задержки в передачи сообщений по сети не было, то можно утверждать, что устройства синхронизированы по времени.

Рис. 3. Вычисление времени задержки сообщений в коммутаторах.

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

Хотя принцип, основанный на использовании граничных часов показал свою практическую эффективность, другой механизм был определен во второй версии протокола PTPv2 - механизм использования т. н. прозрачных часов. Данный механизм предотвращает накопление погрешности, обусловленной изменением величины задержек в передаче сообщений синхронизации коммутаторами и предотвращает снижение точности синхронизации в случае наличия сети с большим числом каскадно-соединенных коммутаторов. При использовании такого механизма передача сообщений синхронизации осуществляется от ведущего устройства ведомому, как и передача любого другого сообщения в сети. Однако когда сообщение синхронизации проходит через коммутатор фиксируется задержка его передачи коммутатором. Задержка фиксируется в специальном поле коррекции в составе первого сообщения синхронизации Sync или в составе последующего сообщения FollowUp (см. рис. 2). При передаче сообщений Delay Request и Delay Response также осуществляется фиксация времени задержки их в коммутаторе. Таким образом, реализация поддержки т. н. прозрачных часов в составе коммутаторов позволяет компенсировать задержки, возникающие непосредственно в них.

Реализация протокола PTP

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

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

Выводы

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