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


38

Припустимо, у комп'ютера є точний годинник, який не ініціалізується. Тобто час на годиннику комп’ютера - це реальний час плюс деяке постійне зміщення. Комп'ютер має підключення до мережі , і ми хочемо використати цю сполуку для визначення зміщення постійного .B

Найпростіший метод полягає в тому, що комп'ютер відправляє запит на сервер часу, зазначаючи місцевий час . Сервер часу отримує запит за один раз і відправляє клієнту відповідь, що містить , який отримує його за час . Тоді , тобто .B+C1TTB+C2B+C1TB+C2TC2BTC1

Якщо час передачі мережі та час обробки сервера симетричні, то . Наскільки мені відомо, NTP , протокол синхронізації часу, що використовується в природі, працює на цьому припущенні.B=TC1+C22

Як можна підвищити точність, якщо затримки не симетричні? Чи є спосіб виміряти цю асиметрію в типовій інтернет-інфраструктурі?


2
Є відповідний патент, але хто хоче прочитати ці ...
Рафаель


Перші думки: Мабуть, це неможливо з двома сутностями. Використовуючи (n2) париnсутностей, ймовірна можлива краща синхронізація. Тоді годинник можна використовувати для вимірювання разових поїздок.
rgrig

Ви можете уточнити додаток / контекст чи це переважно теоретичне питання?
vzn

Відповіді:


10

Неможливість вимірювати асиметрію

Ні, ви не можете виміряти асиметрію. Розглянемо ці дві схеми зв'язку, перша з відхиленням відхилення тактових частот та рівними затримками, друга - без зміщення тактової частоти та цілком асиметричні затримки (але той самий час подорожі в обидва кінці).

схема зв'язку

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

Ви можете створити більше випадків, "захопивши" шкалу часу ПК та "пересунувши" її, утримуючи пункти відправлення / отримання повідомлень фіксованими відносно відповідних термінів. Асиметрії, які ви викликаєте, точно заперечуються зміщенням годинника. Насправді, ви навіть можете змусити повідомлення проходити НАЗАД у часі в одну сторону (доки час у зворотній дорозі ще однаковий), і сервер / клієнт НЕ МОЖЕ розказати!

Тому неможливо виміряти асиметрії затримки. У гіршому випадку, якщо у вас немає іншої інформації, крім того, що затримки в одну сторону є позитивними і дорівнюють часу кругової поїздки, точність синхронізації годин обмежується часом кругової поїздки.

Чи може проміжна інфраструктура допомогти?

Чи може допомогти проміжна інфраструктура чи ні, буде сильно залежати від вашої теоретичної моделі ситуації.

Якщо асиметрія постійна і проміжною інфраструктурою є маршрутизатори на шляху зв'язку між вами та сервером, то ні. Навіть якби кожен маршрутизатор синхронізував свій годинник із сусіднім маршрутизатором, помилки складатимуться так само, як якщо б ви синхронізувались із сервером через зв’язок через маршрутизатори.

У реальному світі ви можете розраховувати на те, що затримки є дещо симетричними з архітектурних міркувань, багаторазові синхронізації для зменшення асиметрії через затримки в черзі (тощо) та кілька шляхів зв'язку для зменшення інших видів асиметрії.

Якщо ви розміщуєте припущення своєї моделі десь посередині (оскільки, звичайно, цікаво досліджувати простір моделі), я думаю, що результат також повинен бути десь посередині.


Це має бути відповіддю на ваше запитання . Тут я запитую про більш конкретні умови, де ми можемо отримати допомогу від базової інфраструктури.
Жиль "ТАК - перестань бути злим"

Я додав більше вмісту для вас.
Крейг Гідні

мені здається, що це неправильно, і це можна помітити, зазначивши, що хоча час надсилання та прийому ПК однаковий (події верхньої шкали часу збігаються в двох випадках), час сервера відрізняється (нижній рядок у двох випадках) & тому формула, обчислена клієнтом NTP, відрізняється в двох випадках. це можна зрозуміти краще, позначивши значення NTP для у кожному випадку (де t 2 , t 3 - значення, записані в серверний час і відправлені назад клієнту). як у моїй відповіді, протокол часу NTP дійсно може вимірювати та коригувати ( t 1 - tt1,t2,t3,t4t2,t3(t1t0)(t3t2)
vzn

@vzn Часи сервера стосовно t-повідомлень в обох прикладах однакові. Тимчасова шкала сервера, що рухається ліворуч, являє собою різницю початкового переміщення годин. Ефекти початкового переміщення годин та асиметрії затримки виявляються рівнозначними, тому регулювання їх обох у протилежних напрямках дозволяє результату поведінки бути рівнозначним.
Крейг Гідні

Подальше дослідження, клієнт / сервер може сказати, коли їх годинник далеко не синхронізований, принаймні поза часом подорожі. Більше інформації в полікосах та ін., які я наводжу нижче, я цитую, де вони вимірюють різні "односпрямовані затримки", що перевищують невизначеність NTP (яка, здається, менша, ніж час у зворотній час до серверів NTP - тобто ~ 10 мс)
vzn

2

Розглянемо мережу серверів часу , як відомо, синхронний, , і клієнтська машина P .θ={A,B,C}P

Нехай буде час один спосіб польоту з машини X в машині Y , з можливістю того, що T X YT Y X .TXYXYTXYTYX

Нехай бути мірою асиметрії між машиною X і Y .ΔXY=|TXYTYX|XY

Тепер врахуйте, що асиметрію між двома синхронними машинами можна виміряти, домогшись синхронних машин одночасно надсилати одностороннє повідомлення один одному. Різниця у часі прильоту становить між цими машинами, тобто:Δ

ΔAB=|TABTBA|

ΔBC=|TBCTCB|

ΔCA=|TCATAC|

можна виміряти.

Тепер розглянемо час польоту ланцюгів:

, позначений C A B ,PABPCAB

, позначимо через C B A .PBAPCBA

CAB=TPA+TAB+TBP

CBA=TPB+TBA+TAP

Consider the client machine P to initiate both of these circuits simultaneously, and measures the difference in arrival times, x:

x=CABCBA=ΔPA+ΔAB+ΔBP

Both x and ΔAB are known by previously mentioned measurements, so moving the unknowns to the left hand side:

xΔAB=ΔPA+ΔBP

Similarly, for {CAC,CCA} and {CBC,CCB} it can be shown that:

yΔBC=ΔPB+ΔCP

zΔCA=ΔPC+ΔAP

Inspecting carefully, we note that ΔXYΔYX. The left sides contain values known from measurements, the right sides contain 3 unknowns in 3 equations.

Solving simultaneously,

ΔAP=r+st2

ΔBP=rs+t2

ΔCP=tr+s2

where,

r=xΔAB

s=yΔBC

t=zΔCA


How does this circumvent the problem my answer and others have?
Raphael

Well, for one l am using 3 timing serves, not one. And it requires something like 12 messages to be sent - 6 to find the asymmetry between the time servers and 6 to find the asymmetry between the client and the servers. It is not a 1-dimensional solution space because the comprison is between 3 servers and not one. And it does not assume time can go backward.
Bingo

It does rely heavily on 3 perfectly synchronised time servers, the synchronisation of which is left as an exercise for the reader. ^^
Bingo

@Raphael l think l understand your comment now. Time shifting doesn't work because it is more constrained. eg. Time shifting A w.r.t. P doesn't just affect the time between A and P but also the circuts PACP,PABP,PBAP,PCAP, the differences of which are measured and factored into the calculation. Maybe I am still wrong? Not sure :P
Bingo

0

If you only control the endpoints. You can't. See Craig's answer.

Even if you add more machines and a more complex set of computers, like in Bingo's answer, you can reduce to just to machines making the synchronized ones have instantaneous access to the others (delay TXY = 0).

Notice that if you do TAB=TBC=TCA=0, you get ΔAP=ΔBP=ΔCP=0.

So what's wrong? x=CABCBA=ΔPA+ΔAB+ΔBP

ΔPA=|TPATAP|, not ΔPA=TPATAP

And if you use the second, then you can not use the assumption ΔXYΔYX (and if you don't use this, your final equations cancel each other).

So, what can you do? Send a really good clock through mail. ;)

Or, if you have control over all nodes between them, you can check the time to process each packet and calculate the delay between each consecutive pair, that should be symmetrical, if they use the same physical medium both ways.

You may need to account for general relativity, and remember that simultaneity doesn't exist.


“You may need to account for general relativity” No, I don't. I'm perfectly fine with a solution that only works if all the clocks involved are in a fixed frame. There is relativity in a distributed system, but it comes from network latency, not from physics. Its mathematics are completely different.
Gilles 'SO- stop being evil'

-1

NTP actually uses 4 time measurements t0,t1,t2,t3 to compute the "offset". they are the "time points" in the round trip of the packet from client to server back to client but can be regarded as time offsets. its assumed that the time offset can be off between client and server but that both can count local elapsed time offsets accurately.

the client after receiving the return packet has all 4 values and computes the actual offset. once the relative offset is calculated between client and server, the "absolute time" offset can be synchronized ie the client can accurately estimate the servers exact offset measured wrt its local time offset, ie the "delta".

t0 = time [offset] sent at client
t1 = time [offset] recd at server
t2 = time [offset] sent at server
t3 = time [offset] recd at client

the actual formula is θ=(t1t0)+(t2t3)2

note this formula can handle the case where the time from client to server t1t0 is not the same as from server to client t3t2 (either shorter or longer).

on networks, delay time is due to two major factors, mainly latency and bandwidth.

  • latency is the brief delay in routers on sending new [small] packets and is roughly a different constant at each router. it can be measured with the traceroute utility.
  • bandwidth is the rate at which large amts of data can be sent eg "upload vs download time" and can also be measured by remote "bandwidth measuring" web sites.

in many modern home/business internet connections the upload rate is much smaller than download rates & this would probably affect the t1t0 vs t3t2 difference whereas latency may be small or somewhat similar between client-to-server and server-to-client.

a basic algorithm to improve accuracy of calculating the offset used in NTP (and can correct for some degree of random network latency) is to repeat the process multiple times and use the "apex of the wedge scattergram". this can be seen on the "clock filter algorithm" on slide 10 of this PPT on NTP by David Mills. see also clock filter algorithm by Mills. (note it can still be employed between a single server and client although the general code is written to allow multiple servers.) this is part of the "mitigation algorithms" described in NTP architecture & algorithms.


1
The question is specifically about the case where the latency is not symmetric. Taking multiple measures won't tell you anything about the constant component in the asymmetry.
Gilles 'SO- stop being evil'

the question does not actually contain the word "latency". if you want to sketch out what case you actually have in mind in math form instead of words esp wrt the real NTP formulas, it would certainly help. the formulas & algorithms can indeed measure/handle/cover various cases of "latency" and "asymmetry".
vzn

C1 and C2 are the latency values (I called them “delay”, the two words are synonymous in this context).
Gilles 'SO- stop being evil'

C1 and C2 are influenced by latency but are not really equal to it. in a sense the scattergram actually plots latency....
vzn

note (maybe its not totally obvious in above acct) the t1,t2 server values are sent in the return packet from server to client.
vzn

-3

If only we could send packets back in time

enter image description here

B=Tf+TbTf2C1+C22

Assumptions:

(B+C2)Tb=Tf(B+C1)

Tf(B+C2)=(B+C1)Tb


1
This clever solution is ruled out by the assumption of a “typical Internet infrastructure”.
Gilles 'SO- stop being evil'

1
@Gilles I know. :D
Pratik Deoghare

-4

Here is an idea that sounds absolutely convincing to me and might therefore be absolutely wrong in a dumb way.

Consider the following scenario. We have two nodes N1 and N2 with clocks C1 and C2, respectively. For sake of simplicity, let us assume that the clocks run with the same speed; we denote their difference by δ=C1C2 which is constant for our purposes. Let us furthermore assume that transmission delays d12 and d21 are constant¹.

Have N1 send a message timestamped with T1m to N2 and let T2r the current time on C2 upon receiving it (do the same for the other direction). In addition, measure round trip time (on either node) D by sending a message back and forth. Now set up this equation system:

T2rT1m=d12+δT1rT2m=d21δD=d12+d21

As this system consists of three equations, has three unknowns and we know there is a solution, it can be solved. Of course the nodes have to exchange their measurements so that they can both compute the same value for δ (if necessary).

1] I think the assumptions are natural and necessary. They can be justified with the hope that the respective quantities do not change too much for the duration of our synchronisation attempt.


(d12+δ)+(d21δ)(d12+d21)=0. There are three equations and three unknowns, but the family of solutions is 1-dimensional. It's the same problem we had with Ran's now-deleted answer and briefly discussed in chat: time is relative; we can't distinguish between delays in transmission and skewed clocks.
Gilles 'SO- stop being evil'

@Gilles Too bad. We should probably leave one instance of the fallacy for all to see?
Raphael

1
I can restore the wrong answer I wrote. It might be useful due to the comments made by Gilles.
Ran G.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.