Ptp протокол синхронизации. Синхронизация в сетях нового поколения: три пути решения проблем. Примеры использования протокола PTP на объектах электроэнергетики

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

65 нанометров - следующая цель зеленоградского завода «Ангстрем-Т», которая будет стоить 300-350 миллионов евро. Заявку на получение льготного кредита под модернизацию технологий производства предприятие уже подало во Внешэкономбанк (ВЭБ), сообщили на этой неделе «Ведомости» со ссылкой на председателя совета директоров завода Леонида Реймана. Сейчас «Ангстрем-Т» готовится запустить линию производства микросхем с топологией 90нм. Выплаты по прошлому кредиту ВЭБа, на который она приобреталась, начнутся в середине 2017 года.

Пекин обвалил Уолл-стрит

Ключевые американские индексы отметили первые дни Нового года рекордным падением, миллиардер Джордж Сорос уже предупредил о том, что мир ждет повторение кризиса 2008 года.

Первый российский потребительский процесор Baikal-T1 ценой $60 запускают в массовое производство

Компания «Байкал Электроникс» в начале 2016 года обещает запустить в промышленное производство российский процессор Baikal-T1 стоимостью около $60. Устройства будут пользоваться спросом, если этот спрос создаст государство, говорят участники рынка.

МТС и Ericsson будут вместе разрабатывать и внедрять 5G в России

ПАО "Мобильные ТелеСистемы" и компания Ericsson заключили соглашения о сотрудничестве в области разработки и внедрения технологии 5G в России. В пилотных проектах, в том числе во время ЧМ-2018, МТС намерен протестировать разработки шведского вендора. В начале следующего года оператор начнет диалог с Минкомсвязи по вопросам сформирования технических требований к пятому поколению мобильной связи.

Сергей Чемезов: Ростех уже входит в десятку крупнейших машиностроительных корпораций мира

Глава Ростеха Сергей Чемезов в интервью РБК ответил на острые вопросы: о системе «Платон», проблемах и перспективах АВТОВАЗа, интересах Госкорпорации в фармбизнесе, рассказал о международном сотрудничестве в условиях санкционного давления, импортозамещении, реорганизации, стратегии развития и новых возможностях в сложное время.

Ростех "огражданивается" и покушается на лавры Samsung и General Electric

Набсовет Ростеха утвердил "Стратегию развития до 2025 года". Основные задачи – увеличить долю высокотехнологичной гражданской продукции и догнать General Electric и Samsung по ключевым финансовым показателям.

т е х н о л о г и и

С.Телегин

Протокол PTP для синхронизации сетей NGN

вопросы применения

В статье рассматривается задача синхронизации сетей передачи данных следующего поколения (NGN). В

качестве альтернативного метода передачи синхронизации автор предлагает использовать протокол PTP. Приведены характеристики систем синхронизации на основе протокола PTP (IEEE 1588) в сравнении с системами, использующими шину PXI, а также протокол NTP.

Проблема синхронизации в сетях NGN

Развитие телекоммуникационных технологий и сетей передачи данных постепенно приводит к построению операторами связи конвергентных сетей следующего поколения (NGN – Next Generation Networks). Основное отличие таких сетей от традиционных сетей с синхронной цифровой иерархией (SDH) – в них для магистральной передачи данных наряду с обычными синхронными каналами используются такие асинхронные технологии, как Ethernet (Gigabit Ethernet, 10Gigabit Ethernet). Главным требованием операторов связи к сетям следующего поколения является одновременная передача голоса, видео и данных по единой сети.

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

	ПЕРВАЯ МИЛЯ 5–6/2009

Для безошибочного восстановления переданных данных на стыке асинхронного и синхронного каналов оборудование также должно получать синхросигнал. Требования к стабильности синхросигнала варьируются в зависимости от конкретного назначения сети передачи данных. Так, в операторских сетях по предоставлению услуг телефонии и доступа в Интернет требования к синхронизации являются достаточно мягкими – 50 ppm (единиц на миллион), а в сотовых сетях для бесшовного перехода мобильных абонентов от одной базовой станции к другой необходима стабильность 50 ppb (единиц на миллиард).

Способы синхронизации сетей NGN

В рекомендации ITU-T G.8261 рассмотрены три основных способа восстановления синхронизации на границах транспортной среды с коммутацией пакетов при передаче в ней группового сигнала с временным мультиплексированием в виде услуги эмуляции каналов. Для этого в оконечном станционном оборудовании должны быть предусмотрены функции межсетевого взаимодействия. Все абоненты транспортной среды с коммутацией пакетов могут получать тактовую частоту от сети синхронизации посредством обычного централизованного распределения (рис.1). Если абонентское оборудование работает на собственной тактовой частоте (рис.2), то на границе сети с коммутацией пакетов ее восстанавливают различными относительными способами, например, с помощью алгоритма согласования скоростей SRTS. В обоих случаях в узле межсетевого взаимодействия должен быть доступ к стыку с генератором первичной синхрони-

т е х н о л о г и и

зации (PRC). Для этого оператор сети NGN должен либо строить отдельную сеть синхронизации, либо арендовать ее у существующих операторов транспортной сети SDH.

Существует множество примеров локальной синхронизации оборудования. Так, например, в станционном помещении размещают недорогой источник первичной синхронизации (PRS) на основе GPS и распределяют от него тактовую частоту с помощью беспроводных технологий или по обычным выделенным кабелям, в физической среде Ethernet, а также c помощью других оригинальных схем . Если построение сети синхронизации (или использование стыков синхронизации) невозможно или нежелательно, то применяют самый простой, но проблематичный из соображений стабильности адаптивный способ согласования скоростей приема и передачи (рис.3).

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

Протокол PTP

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

помощью специально разработанных протоколов (рис.5). На данный момент таковыми являются протоколы NTP и PTP . Эти протоколы изначально создавались для синхронизации времени в различных устройствах сети, но в случае успешной синхронизации часов также становится возможным реализация алгоритмов синхронизации тактовых частот для восстановления данных реального времени. Протокол NTP (Network Time Protocol) широко используется для синхронизации текущего времени на прикладном уровне. В отличие от него, протокол "точного времени" PTP (Precision Time Protocol) действует на втором уровне модели взаимодействия открытых систем (OSI). Протокол РТР описан в стандарте IEEE 1588. Ожидается, что в дальнейшем РТР может быть использован как для высокоточной синхронизации текущего времени, так и для тактовой синхронизации оборудования. Рассмотрим данный протокол более подробно.

Стандарт IEEE 1588 предполагает, что протокол РТР предоставляет стандартный метод синхронизации устройств в сети с точностью выше 1 мкс (до 10 нс). Данный протокол обеспечивает синхронизацию ведомых устройств от ведущего, удостоверяясь, что события и временные метки на всех устройствах используют одну и ту же временную базу. В протоколе предусмотрены две ступени для синхронизации устройств: определе-

Рис. 3 Адаптивная синхронизация

Рис.4	Передача синхронизации с помощью RTP
Рис.5	Передача синхронизации с помощью PTP

ПЕРВАЯ МИЛЯ 5–6/2009

Рис. 6 Алгоритм работы PTP

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

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

Ведущее устройство начинает коррекцию сдвига часов, используя сообщения Sync и Follow-up. В сообщении Follow-up указывается время отправления сообщения Sync (ТМ1 ), измеренное наиболее близко к среде передачи для минимизации ошибки во времени опорного источника. После того, как ведомое устройство получает первые сообщения Sync и Follow-up, оно использует свои часы для отметки времени прибытия сообщения Sync (TS1 ) и сравнивает данную отметку с той, что пришла от ведущего устройства в сообщении Follow-up. Разница между этими двумя метками отражает сдвиг часов T0 плюс задержку передачи сообщения от ведущего устройства к ведомому ∆TMS : TS1  – TM1  = T0  + ∆TMS .

Для вычисления времени задержки передачи сообщения и сдвига отсчета часов ведомое устройство отправляет сообщение Delay_request со своим временем TS2 . Ведущее устройство отмечает прибытие данного сообщения и отправляет в ответ сообщение Delay_response меткой TM2 . Разница между двумя метками – это задержка передачи от ведомого устройства к ведущему ∆TSM минус сдвиг в отсчете ведомого устройства: TM2  – TS2  =∆TSM  – T0 .

При вычислении задержки передачи сообщения принимается, что средняя задержка передачи данных в канале рав-

на среднему арифметическому задержек распространения в разные стороны канала:

		T MS + T SM

Зная времена TS1 , TM1 , TM2 и TS2 , ведомое устройство вычисляет усредненную задержку распространения в канале передачи данных:

T = (TS1 − TM1 ) + (TM2 − TS2 ) . 2

Финальная синхронизация часов выполняется после отправки ведущим устройством второго набора сообщений Sync (TS3 ) и Follow-up (TM3 ). Ведомое устройство вычисляет сдвиг своих часов по формуле T0  = TS3  – TM3  – ∆T.

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

Особенности реализации протокола PTP

Большинство реализаций PTP имеют отклонение меньше 1 мкс, однако реальная точность работы зависит от приложения. Протокол PTP в устройствах реализуют тремя способами: программным, программно-аппаратным и аппаратным. Программные реализации РТР позволяют передавать сигналы синхронизации с точностью порядка 100 мкс. Чтобы достичь более высокой точности, необходимо использовать аппаратные средства. Каждый компонент, который обрабатывает пакет PTP после его получения из физической среды передачи, увеличивает ошибку синхронизации. Программная часть вносит наибольшую ошибку, поскольку загрузка процессора и задержка, связанная с обработкой прерывания, влияют на скорость обработки запроса синхронизации.

При программно-аппаратной реализации наиболее чувствительные функции протокола, такие как запись временной метки PTP-пакета, реализуются на физическом уровне Ethernet , например, в отдельной микросхеме программируемой логики. Такие методы сегодня наиболее оптимальны, так как требуют не слишком много ресурсов и времени на разработку устройства, позволяя добиться точности порядка 20 нс. В случае же полной аппаратной реализации протокола PTP достижима точность порядка 10 нс.

Кроме способа реализации на точность работы протокола РТР влияет ряд других факторов. Например, стандарт IEEE 1588 не специфицирует частоту синхронизации ведущего и ведомого устройств. В результате синхросигналы с более низкой частотой будут иметь менее точное временное разрешение, приводящее к менее точным временным меткам в синхронизирующих сообщениях. Стабильность частоты опорных генераторов также влияет на качество реализации протокола. Синхросигналы, полученные при использовании термостатированных и термокомпенсированных кварцевых генераторов, будут более стабильны (от-

	ПЕРВАЯ МИЛЯ 5–6/2009

						т е х н о л о г и и
	клонение в миллиардные доли), нежели кварцевые генераторы					шую альтернативу для синхронизации распределенных сис-
	без термостабилизации (отклонение в миллионные доли).					тем с субмикросекундной точностью.
	На качество синхронизации устройств влияет также топо-					Таким образом, протокол PTP является альтернативным
логия сети и равномерность трафика. В сети с большим чис-						способом синхронизации сетей, который может получить рас-
лом устройств и высокой загрузкой каналов передачи данных						пространение в сетях NGN. По сравнению с используемыми в
точность трансляции синхронизации будет хуже. Поэтому для						настоящее время средствами синхронизации, данный метод
передачи сигналов синхронизации предпочтительно использо-						обладает рядом преимуществ:
вать отдельную сеть передачи данных.						Не требуется доступ оборудования напрямую к стыку синхро-
						низации PRC, что позволит операторам оптимизировать за-
Сравнительные характеристики						траты на построение сети. При этом протокол РТР может обес-
систем синхронизации						печить передачу синхронизации с субмикросекундной точнос-
Рассмотрим характеристики систем синхронизации, использую-						тью, а значит, достижима стабильность лучше, чем 1 ppm;
щих протокол PTP, в сравнении с системами с синхронизацией						В отличие от адаптивного метода, для восстановления синх-
по шине PXI (физическая линия синхронизации) и по протоко-						ронизации необходим высокостабильный опорный генератор
лу NTP (см. таблицу). В отличие от систем с физической линией						только в ведущем устройстве;
синхронизации, где точность событий определяется точностью						Для задач синхронизации можно использовать асинхрон-
синхросигнала, в протоколе PTP определяющим факторов явля-						ный канал со сравнительно небольшой пропускной способ-
ется дрожание фазы (джиттер), связанное со случайным измене-						ностью, что значительно уменьшает стоимость реализации.
нием межпакетных интервалов. Большинство реализаций прото-						Предпочтительно, чтобы этот канал был выделенным.
кола PTP обеспечивает точность менее 1 мкс.						Принимая во внимание простоту развертывания сетей
	Еще одна важная величина, отличающая разные способы					Ethernet, субмикросекундную точность и функционирование
синхронизации, – время ожидания синхронизирующего собы-						с минимальными затратами на обработку сообщений, прото-
тия. Это время между отправкой события ведущим устройс-						кол PTP все чаще используется во многих отраслях, особенно
твом и получением его ведомым. Поскольку протоколы PTP и						в промышленной автоматике, в метрологии и т.п. Ожидает-
NTP для передачи синхронизирующих сообщений использу-						ся, что в будущем возможности протокола PTP расширят его
ют пакеты данных, ожидание события определяется временем						применение и в телекоммуникациях для синхронизации уст-
ожидания пакета плюс время передачи и обработки заголовка						ройств по сетям с коммутацией пакетов.
пакета и, как правило, составляет несколько миллисекунд. В
отличие от них системы с физической линией синхронизации						Литература
ожидают синхронизирующего события в течение нескольких						1. Stein Y., Schwartz E. Circuit Extension over IP: The
наносекунд. Время ожидания синхронизирующего события оп-						Evolutionary Approach to Transporting Voice and Legacy
ределяет такую характеристику, как максимально возможная						Data over IP Networks. – RAD Data Communications, 2002.
частота подстройки синхросигнала.						2. ITU-T G.8261/Y.1361 Timing and synchronization
	Системы синхронизации с единой шиной синхронизации,					aspects in packet networks. – ITU_T, April 2008.
такие как PXI, идеально подходят для высокоточного и скоро-						3. Rodrigues S. Technology options for sync delivery in
стного восстановления синхронизации и могут быть расши-						Next Generation Networks. – 3rd International Telecom
рены на расстояния до сотен метров с помощью специальных
модулей синхронизации, размещаемых в кассетах. Стандар-						4. Телегин С.А. Применение TDMoIP мультиплекси-
тная синхронизация по сети Ethernet с помощью NTP предо-						рования для передачи данных в транспортных сетях
ставляет миллисекундную синхронизацию, подходящую для						GSM. – Нелинейный мир, 2007, т.5, №5, с. 270–271.
низкоскоростных приложений, не очень критичных к качеству						5. IEEE Std. 1588–2008 IEEE Standard for a Precision
синхронизации. Протокол же PTP представляет собой хоро-						Clock Synchronization Protocol for Networked
	Сравнительные характеристики систем синхронизации					Measurement and Control Systems. – IEEE, July 2008.
						6. IETF RFC1305 Network Time Protocol (Version 3).
			Синхронизирующие	Протокол	Протокол
						Specification, Implementation and Analysis. – IETF,
			модули на шинах PXI
	Временное
					<1·107	7. Tan E. IEEE 1588 Precision Time Protocol Time
	разрешение
	событий, нс					Synchronization Performance. Application Note 1728. –
						National Semiconductor, October 2007.
	ожидания
						8. Hamdi M. Neagoe T. A Hardware IEEE-1588
						Implementation with Processor Frequency Control. –
	подстройки					Arrow Electronics, August 2006.

ПЕРВАЯ МИЛЯ 5–6/2009

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 настраивают свои часы, синхронизируясь с текущим временем постепенно либо единовременно.

Много статей написано про всем известный 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, либо мастер в сети единственный. На картинке показана процедура общения главного устройства и синхронизируемого.

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

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

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

1. Изменить тактовую частоту Slave устройства (пример в стандарте)
2. Не менять тактовую частоту, но за каждый такт длительностью 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 уровне. В таких сетях время доставки пакета постоянно меняется (особенно заметно, когда работаешь с наносекундной точностью). Для того чтобы отфильтровать эти значения применяются различные фильтры.

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

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

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

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

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

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

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

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

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

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

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