•Фаза 2 — Синхронизация обычных и граничных часов
•Сразу после установки иерархии «Ведущие часы — Ведомые часы» начинается фаза синхронизации обычных и граничных часов. Для синхронизации ведущие часы отправляют ведомым часам сообщение, содержащее метку времени.
•Ведущие часы могут быть:
•одноступенчатые;
•двухступенчатые.
•Одноступенчатые часы для синхронизации посылают одно сообщение Sync. Двухступенчатые часы для синхронизации используют два сообщения — Sync и Follow_Up.
•Для фазы синхронизации могут быть использованы два механизма:
•Механизм запроса-ответа задержки (Delay request-response mechanism).
•Механизм измерения задержки соседнего узла (Peer delay measurement mechanism).
Механизм запроса-ответа задержки (Delay request-response mechanism)
•Механизм предполагает два шага:
•Измерение задержки при передаче сообщения между ведущими часами и ведомыми. Выполняется при помощи механизма запроса-ответа задержки.
•Выполняется коррекция сдвига точного времени.
Когда ведомые часы знают время t1, t2, t3 и t4, то они могут рассчитать среднюю задержку при передаче сообщения синхронизации (tmpd). Она рассчитывается следующим образом:
•При передаче сообщения Sync и Follow_Up вычисляется задержка времени от мастера к слэйву — t-ms.
•При передаче сообщений Delay_Req и Delay_Resp вычисляется задержка времени от слэйва к мастеру — t-sm.
•Если между этими двумя значениями возникает какая-то асимметрия, то появляется ошибка коррекции ухода точного времени. Ошибка
обуславливается тем, что вычисленная задержка является средним от задержек t-ms и t-sm. Если задержки не равны друг другу, то мы будем корректировать время неточно.
Коррекция сдвига точного времени
Ведомые часы используют сообщение Sync и опциональное сообщение Follow_Up для расчета сдвига точного времени при передаче пакета
от ведущих часов к ведомым. Сдвиг рассчитывается по следующей формуле:
Механизм измерения задержки соседнего узла (Peer delay measurement mechanism). Данный механизм также использует два шага для синхронизации: Устройства измеряют задержку времени до всех соседей через все порты. Для этого они используют peer delay mechanism.
Корректировка сдвига точного времени.
Измерение задержки между устройствами, поддерживающих режим Peer-to-Peer
Задержка между портами, поддерживающими механизм peer-to- peer, измеряется при помощи следующих сообщений:
Когда порту 1 известно время t1, t2, t3 и t4, он может рассчитать среднюю задержку (tmld). Она рассчитывается по следующей формуле:
Затем порт использует это значение при расчете поля корректировки для каждого сообщения Sync или опционального сообщения Follow_Up, которые проходят через данное устройство.
Итоговая задержка будет равна сумме задержки при передаче через данное устройство, средней задержке при передаче через канал данных и уже содержащейся задержки в данном сообщении, включенной на вышестоящих устройствах.
Сообщения Pdelay_Req, Pdelay_Resp и опциональное Pdelay_Resp_Follow_Up позволяет получить задержку от мастера к слэйву и от слэйва к мастеру (круговую).
Любая асимметрия между этими двумя значениями привнесет ошибку коррекции сдвига точного времени.
Корректировка сдвига точного времени
Ведомые часы используют Sync-сообщение и опциональное сообщение Follow_Up для расчета сдвига точного времени при передаче пакета от ведущих часов к ведомым. Сдвиг рассчитывается по следующей формуле:
Преимущества корректировка механизма peer-to-peer — задержка времени каждого сообщения Sync или Follow_Up рассчитывается по ходу его передачи в сети. Следовательно, и изменение пути передачи не повлияет никаким образом на точность корректировки.
При использовании этого механизма синхронизация времени не требует расчета задержки времени на пройденном пакетом синхронизации пути, как это делается при базовом обмене. Т.е. сообщения Delay_Req и Delay_Resp не отправляются.
В этом методе задержка между ведущими часами и ведомыми просто суммируется в поле корректировки каждого сообщения Sync или Follow_Up.
Еще одно преимущество — ведущие часы разгружаются от необходимости обрабатывать сообщения Delay_Req.
Режимы работы прозрачных часов
•Соответственно, это были разобраны простые примеры. А теперь предположим, что на пути синхронизации появляются коммутаторы. Если использовать коммутаторы без поддержки PTPv2, то пакет синхронизации будет задерживаться на коммутаторе примерно на 10 мкс.
•Коммутаторы с поддержкой PTPv2 в терминологии IEEE 1588v2 называются прозрачными часами (Transparent clock). Прозрачные часы не синхронизируются от ведущих часов и не участвуют в иерархии «Ведущие часы — Ведомые часы», но при передаче сообщений синхронизации запоминают, на сколько сообщение задержалось на них. Это позволяет скорректировать задержку времени.
•Прозрачные часы могут работать в двух режимах:
•End-to-End.
•Peer-to-Peer.
End-to-End (E2E)
Прозрачные часы E2E передают сообщения Sync и сопутствующие сообщения Follow_Up на все порты. Даже на те, которые заблокированы какими-либо протоколами (например, RSTP).
Коммутатор запоминает метку времени, когда пакет Sync (Follow_Up) был принят на порт и когда был отправлен с порта. На основании этих двух меток времени вычисляется время обработки коммутатором сообщения. В стандарте это время называется residence time.
Время обработки добавляется в поле correctionField сообщения Sync (одноступенчатые часы) или Follow_Up (двухступенчатые часы).