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

Предположим, что на компьютере установлены точные часы, которые не инициализированы. То есть время на часах компьютера - это реальное время плюс некоторое постоянное смещение. Компьютер имеет подключение к сети , и мы хотим использовать это соединение для определения смещения постоянного .$B$

Простой способ состоит в том, что компьютер отправляет запрос на сервер времени, отмечая местное время . Сервер времени получает запрос в момент времени и отправляет ответ, содержащий обратно клиенту, который получает его в момент времени . Тогда , т. .$B + C_1$$T$$T$$B + C_2$$B + C_1 \le T \le B + C_2$$T - C_2 \le B \le T - C_1$

Если время передачи по сети и время обработки на сервере симметричны, то . Насколько я знаю, NTP , протокол синхронизации времени, используемый в дикой природе, работает на этом предположении.$B = T - \dfrac{C_1 + C_2}{2}$

Как повысить точность, если задержки не симметричны? Есть ли способ измерить эту асимметрию в типичной интернет-инфраструктуре?

Невозможность измерить асимметрию

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

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

Вы можете создавать больше дел, «захватывая» временную шкалу ПК и «скользя» по ней, удерживая точки отправки / получения сообщений фиксированными относительно их соответствующих временных шкал. Асимметрия, которую вы вызываете, точно сводится на нет смещением часов. Фактически, вы можете даже заставить сообщения отправляться НАЗАД ВРЕМЕНИ в одну сторону (при условии, что время прохождения туда-обратно все равно), а сервер / клиент ЕЩЕ НЕ может сказать!

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

Может ли промежуточная инфраструктура помочь?

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

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

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

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

Рассмотрим сеть серверов времени , как известно, синхронно, , и клиентская машина .$\theta = \{A, B, C\}$$P$

Пусть будет временем одностороннего полета от машины к машине с возможностью того, что . X Y T X Y ≠ T Y $T_{XY}$$X$$Y$$T_{XY}\neq T_{YX}$

Пустьбыть мерой асимметрии между машиной X и Y .$\Delta_{XY} = |T_{XY} - T_{YX}|$$X$$Y$

Теперь предположим, что асимметрия между двумя синхронными машинами может быть измерена, если синхронные машины согласятся отправлять односторонние сообщения друг другу одновременно. Разница во времени прибытия составляет между этими машинами, то есть:$\Delta$

$\Delta_{AB} = |T_{AB} - T_{BA}|$

$\Delta_{BC} = |T_{BC} - T_{CB}|$

$\Delta_{CA} = |T_{CA} - T_{AC}|$

можно измерить.

Теперь рассмотрим время пролета цепей:

C A $P \rightarrow A \rightarrow B \rightarrow P$ , обозначаемый ,$C_{AB}$

C B $P \rightarrow B \rightarrow A \rightarrow P$ , обозначается .$C_{BA}$

$C_{AB} = T_{PA} + T_{AB} + T_{BP}$

$C_{BA} = T_{PB} + T_{BA} + T_{AP}$

Рассмотрим клиентскую машину для одновременного запуска обеих этих цепей и измеряем разницу во времени прибытия, :$P$$x$

$x = C_{AB} - C_{BA} = \Delta_{PA} + \Delta_{AB} + \Delta_{BP}$

И и известны по ранее упомянутым измерениям, поэтому перемещаем неизвестные в левую часть:Δ $x$$\Delta_{AB}$

$x - \Delta_{AB} = \Delta_{PA} + \Delta_{BP}$

Аналогично, для и можно показать, что:{ C B C , C C B$\{C_{AC}, C_{CA}\}$$\{C_{BC}, C_{CB}\}$

$y - \Delta_{BC} = \Delta_{PB} + \Delta_{CP}$

$z - \Delta_{CA} = \Delta_{PC} + \Delta_{AP}$

Осматривая внимательно, мы отмечаем, что . Левые части содержат значения, известные из измерений, правые части содержат 3 неизвестных в 3 уравнениях.$\Delta_{XY} \equiv \Delta_{YX}$

Решая одновременно,

$\Delta_{AP} = \frac{r + s - t}{2}$

$\Delta_{BP} = \frac{r - s + t}{2}$

$\Delta_{CP} = \frac{t - r + s}{2}$

где,

$r = x - \Delta_{AB}$

$s = y - \Delta_{BC}$

$t = z - \Delta_{CA}$

Если вы контролируете только конечные точки. Ты не можешь Смотри ответ Крейга.

$T_{XY}$

$T_{AB} = T_{BC} = T_{CA} = 0$$\Delta_{AP} = \Delta_{BP} = \Delta_{CP} = 0$

$x = C_{AB}-C_{BA} = \Delta_{PA}+\Delta_{AB}+\Delta_{BP}$

$\Delta_{PA} = |T_{PA} - T_{AP}|$$\Delta_{PA} = T_{PA} - T_{AP}$

$\Delta_{XY} \equiv \Delta_{YX}$

Так что ты можешь сделать? Отправить действительно хорошие часы по почте. ;)

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

Возможно, вам придется учитывать общую относительность и помнить, что одновременность не существует.

$t_0, t_1, t_2, t_3$

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

$t_0$
$t_1$
$t_2$
$t_3$

$\theta = {(t_1 - t_0) + (t_2 - t_3) \over 2}$

$t_1 - t_0$$t_3 - t_2$

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

• Задержка - это краткая задержка в маршрутизаторах при отправке новых [маленьких] пакетов и примерно одинаковая константа на каждом маршрутизаторе. это можно измерить с помощью утилиты traceroute .
• Пропускная способность - это скорость, с которой могут отправляться большие объемы данных, например, «загрузка или время загрузки», а также может измеряться удаленными веб-сайтами «измерения пропускной способности».

$t_1 - t_0$$t_3 - t_2$

Основной алгоритм для повышения точности расчета смещения, используемого в NTP (и может корректировать некоторую степень случайной задержки в сети), состоит в том, чтобы повторять процесс несколько раз и использовать «вершину диаграммы рассеяния клина». это можно увидеть на «алгоритме фильтрации часов» на слайде 10 этого PPT по NTP Дэвида Миллса. см. также алгоритм фильтрации часов по Миллсу. (обратите внимание, что он все еще может использоваться между одним сервером и клиентом, хотя общий код написан для нескольких серверов.) Это часть «алгоритмов смягчения», описанных в архитектуре и алгоритмах NTP .

Если бы мы только могли отправлять пакеты вовремя

Предположения:

$(B+C_2) - T_b = T_f - (B+C_1)$

$T_f - (B + C_2) = (B + C_1) - T_b$

Вот идея, которая звучит абсолютно убедительно для меня и, следовательно, может быть совершенно неверной.

$N_1$$N_2$$C_1$$C_2$$\delta = C_1 - C_2$$d_{1 \to 2}$$d_{2 \to 1}$

$N_1$$T_1^m$$N_2$$T_2^r$$C_2$$D$

$\qquad\begin{align*} T_2^r - T_1^m &= d_{1 \to 2} + \delta \\ T_1^r - T_2^m &= d_{2 \to 1} - \delta \\ D &= d_{1 \to 2} + d_{2 \to 1} \end{align*}$

$\delta$

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