Синхронизация времени с помощью ГНСС приемников. Высокоточная сетевая синхронизация по протоколу PTP.
В предыдущих статьях цикла о временной синхронизации были обсуждены основные принципы сетевой синхронизации по протоколу NTP. Мы знаем, что точность, которую обеспечивает NTP, напрямую зависит от сетевой инфраструктуры. Даже в локальной сети точность NTP может в лучшем случае достигать уровня миллисекунд. А если используется глобальная сеть, с множеством свитчей (коммутаторов) и маршрутизаторов, из-за неопределенностей в путях передачи и задержках, точность NTP находится на уровне сотен миллисекунд.
Почему точность NTP может быть только в миллисекундах (локальная сеть, LAN) и сотнях миллисекунд (глобальные сети, WAN)?
Как было описано в предыдущей статье, есть две основных причины низкой точности временной синхронизации NTP:
• Задержка обработки процессорами
Четыре метки времени в технологии NTP, T1, T2, T3, и T4, это те отметки времени, когда процессор обрабатывает пакет данных, а не отметки времени, когда пакет данных отправлен/получен на сетевом порте.
Есть четкая разница между временем, когда процессор обрабатывает пакет данных и временем приема/отправки данных на сетевом порте, которая также является причиной снижения точности.
Более того, поскольку процессоры управляются операционными системами и работают в многопотоковых режимах, результат обработки процессором не фиксирован во времени и не может быть скомпенсирован.
• Задержка сетевой инфраструктуры
В технологии синхронизации по проколу NTP предполагается, что задержка передачи T1 от сервера к клиенту, и задержка передачи T2 от клиента к серверу идентичны и симметричны. Однако, в реальной среде сетевой передачи данных, как правило имеется множество коммутаторов и множество маршрутизаторов, которые могут перенаправлять пакеты разными маршрутами, поэтому вышеуказанные значения времени T1 и T2 не могут быть равны и симметричны.
Это подводит нас к таком понятию как ошибка синхронизации NTP. С ростом числа маршрутизаторов в глобальных сетях (WAN), маршрут от сервера к клиенту и маршрут от клиента к серверу будут сильно различаться, что будет приводить к большой разнице между T1 и T2, так что точность временной синхронизации ухудшится до уровня сотен миллисекунд.
Есть ли способ повысить точность сетевой синхронизации до уровня менее 1 микросекунды? В данной статье рассматриваются пути решения этой задачи.
Существует метод сетевой синхронизации времени, который может дать точность менее 1 микросекунды, и это протокол PTP. Первая буква "P" в аббревиатуре PTP означает Precise – точный.
Давайте начнем с причин плохой точности NTP.
Решение проблемы с задержкой процессорной обработки
Мы знаем, что:
• Процессорная обработка имеет задержки
• Требуемые нам метки времени – время отправки пакета и время получения пакета на сетевом порте
Поэтому, когда мы получаем метки времени T1, T2, T3 и T4, мы можем записывать время напрямую на физическом уровне (PHY) или на уровне сетевого интерфейса (NIC). Это позволяет устранить колебания задержек операционной системы и стека программных протоколов, и при этому отсутствует фактор случайной задержки, вызванный планировщиками задач операционной системы, обработчиками прерываний и пр.
Как показано на следующем рисунке:
Метки времени
Источник точного времени принято называть ведущими часами (master clock), получатель точного времени – ведомыми часами (slave clock).
Решение проблемы с задержкой сетевой среды. Компенсация задержки промежуточного узла.
При прохождении пакетов данных по сети через промежуточные узлы, такие как коммутаторы и маршрутизаторы, следует учитывать время обработки внутри этих узлов. Время обработки в коммутаторах и маршрутизаторах называется residence time.
Если можно измерить время задержки, его можно поместить в выделенное поле пакета временных данных как величину компенсации и передать его на следующий уровень.
После получения пакета данных, узел следующего уровня обрабатывает его и добавляет собственное значение величины задержки (residence time) к задержке обработки (residence time) на предыдущем уровне до отправки, и помещает результат в выделенное поле пакета данных и так далее.
Пакет данных проходит уровень за уровнем по своему маршруту. Когда он достигает ведомых часов (slave clock) на пути от ведущих часов (master clock), ведомые часы не только знают всю задержку маршрута T от ведущих часов до ведомых часов, но также знает общее время обработки Tr каждого промежуточного узла.
В пакете данных, передаваемом от ведущих часов к ведомым, имеется выделенное поле временной коррекции correctionField.
Представим, что между ведущими часами и ведомыми часами имеются два маршрутизатора, время обработки первым маршрутизатором составляет 3 микросекунды (мкс), а время обработки вторым маршрутизатором составляет 2 мкс. Когда пакет данных от ведущих часов отправляется первым маршрутизатором, в поле correctionField пакета данных записывается значение 3 мкс, а после отправки пакета данных вторым маршрутизатором, в поле пакета данных correctionField записывается значение 5 мкс.
После получения пакета данных от ведущих часов, мы получаем 5 мкс из поля correctionField, то есть мы знаем, что узлы маршрутизаторов на пути прохождения данных по сети добавляют задержку в 5 мкс, таким образом общая задержка по маршруту T минус суммарное время обработки (residence time) Tr = 5 мкс, не является ли это реальной задержкой сетевой передачи?
Аналогично, если в сети имеется N уровней маршрутизаторов (сегментов сети), каждый маршрутизатора добавляет к значению в поле correctionField собственное время обработки (residence time).
Это можно изобразить на следующей схеме:
Анализ задержек
Используя указанный метод, задержка по причинам обработки пакетов маршрутизаторами и коммутаторами может быть устранена, даже если пакеты проходят через множество уровней маршрутизаторов и коммутаторов.
В области временной синхронизации есть специальный термин для компенсации задержек, вызванных промежуточными узлами, – «прозрачные часы», это означает, что пакет с данными полностью «прозрачен» для обработки, то есть не увеличивает время задержки, потому что задержка была компенсирована.
Принудительная маршрутизация
Компенсация задержек промежуточных узлов может устранить воздействие задержек внутренней обработки в маршрутизаторах и коммутаторах. Однако, если маршрут от сервера к клиенту отличается от маршрута от клиента к серверу, ошибки задержек прохождения пакетов все еще будут появляться, выражаясь в асимметричности задержек при двусторонних передачах, что существенно влияет на точность временной синхронизации.
Поэтому можно оптимизировать сетевую маршрутизацию путем настройки протокола маршрутизации с использованием принудительного двустороннего канала между сервером и клиентом, чтобы пакеты проходили по одному и тому же физическому маршруту, и, как следствие, обеспечивали симметричность задержек двусторонней передачи.
Наконец, будет ещё лучше, если независимая виртуальная подсеть (VLAN) или физическое соединение (physical link) могут быть преднастроены на приоритет пакетов данных PTP. Это не только обеспечит прохождение двусторонних связей по одному и тому же физическому маршруту, но также позволит избежать случайных задержек, которые могут быть вызваны перегрузкой каналов на маршруте.
Пример реализации
Выше представлен метод решения проблемы низкой точности временной синхронизации протокола NTP. Синхронизация PTP использует подобный метод повышения точности временной синхронизации.
В первую очередь, метки времени, применяемые в протоколе PTP, основаны на часах сетевого интерфейса NIC или физического уровня PHY, фиксируемые в моменты приема/передачи сетевым портом, исключая влияние задержки при процессорной обработке.
Сетевые узлы, коммутаторы и маршрутизаторы, замеряют собственное время обработки (residence time) Tr, после чего добавляют результат к общему времени residence time.
В чем конкретно заключается процесс передачи информации о времени между источником и получателем (ведущими и ведомыми часами)? Посмотрим на следующий рисунок.
Передача времени между ведущими и ведомыми часами
1. Сообщения Sync и Follow_Up (ведущие → ведомые) Ведущие часы отправляют сообщение с информацией о синхронизации Sync. Если это аппаратное время, в пакет данных сообщения Sync проставляется время отправки пакета сетевым портом T1, после чего сообщение отправляется. Если на аппаратном уровне это не поддерживается, процессор фиксирует время передачи пакета сетевым портом T1, и затем инициирует отправку пакета данных Follow_UP, в который помещается время T1.
2. Сообщение Delay_Req (ведомые → ведущие) При получении ведомыми часами пакета данных Sync, они записывают время получения пакета собственным сетевым портом T2, и передают пакет данных Delay_Req к ведущим часам, фиксируя время отправки сообщения T3 собственным сетевым портом. Следует обратить внимание, что ни одну из меток времени T2 и T3 не требуется передавать обратно ведущим часам.
3. Ответное сообщение Delay_Resp (ведущие → ведомые) После получения сообщения Delay_Req, ведущие часы фиксируют время получения пакета T4 собственным сетевым портом, и затем отправляют T4 ведомым часам в пакете данных сообщения Delay_Resp.
В итоге на приемной стороне (ведомые часы) имеются метки времени T1, T2, T3 и T4, каков алгоритм их обработки для получения смещения/разницы во времени между ведущими и ведомыми часами?
По аналогии с алгоритмом NTP, можно выполнить следующие расчеты:
Задержка передачи от ведущих часов (master) к ведомым (slave)
Задержка передачи от ведомых часов (slave) к ведущим (master)
Здесь мы снова допустим, что задержки времени туда и обратно - симметричны, то есть,
Тогда смещение времени между ведущими часами (master) и ведомыми (slave):
После того, как мы рассчитали смещение времени, часы можно синхронизировать от ведущих часов, добавляя полученное смещение.
Почему протокол PTP допускает, что время прохождения сигнала в прямом и обратном направлении от ведущих часов к ведомым симметрично? Прозрачные часы устраняют величину времени задержки внутренней обработки (residence time) на каждом узле, а принудительная маршрутизация фиксирует маршрут прохождения пакетов данных между ведущими и ведомыми часами и обратно, обеспечивая симметрию задержки.
Передача тактовых сигналов (clock transfer) между разными уровнями ведущих часов
Если топология сети слишком сложна, то даже после всех представленных выше операций, время прохождения сигнала в прямом и обратном направлении от ведущих часов к ведомым всё ещё асимметрично. Другим способом повышения точности временной синхронизации является сегментирование (разбиение) длинного маршрута между ведущими и ведомыми часами на множество коротких маршрутов.
Допустим, что требуется получить время от ведущих часов A ведомым часам B, но при этом топология сети между A и B относительно сложна. Тогда между узлами A и B можно добавить PTP узел C. Узел C имеет возможность получения времени от ведущих часов A и синхронизировать собственное время с ведущими часами.
В то же время, C также может служить новыми ведущими часами, т.е. быть источником синхронизации для часов следующего уровня B.
Пример передачи часов с использованием промежуточных PTP узлов
Так как длинный маршрут был разделен на несколько более коротких, становится легче обеспечить симметрию времени прохождения сигнала в прямом и обратном направлении на каждом коротком маршруте.
Модули для синхронизации времени
Ниже представлена одна из моделей доступных на рынке плат для синхронизации PTP с ее техническими характеристиками:
Пример модуля для PTP-синхронизации
Источник: блог Навигация и Связь, 23.05.2025.
Перевод и адаптация: ООО «ГНСС плюс», 2025.
