Assume a computer has a precise clock which is not initialized. That is, the time on the computer's clock is the real time plus some constant offset. The computer has a network connection and we want to use that connection to determine the constant offset .
El método simple es que la computadora envía una consulta a un servidor horario, señalando la hora local . El servidor horario recibe la consulta en un momento y envía una respuesta que contiene al cliente, que la recibe en un momento . Entonces , es decir, .
Si el tiempo de transmisión de la red y el tiempo de procesamiento del servidor son simétricos, entonces . Hasta donde yo sé,NTP, el protocolo de sincronización de tiempo utilizado en la naturaleza, opera bajo esta suposición.
¿Cómo se puede mejorar la precisión si los retrasos no son simétricos? ¿Hay alguna manera de medir esta asimetría en una infraestructura típica de Internet?
fuente
Respuestas:
Inability to measure asymmetry
No, you can't measure the asymmetry. Consider these two communication diagrams, the first with a negative clock offset and equal delays and the second with no clock offset and entirely asymmetric delays (but the same round trip time).
The important thing to notice is that, from the perspective of both the PC and the server, the two interactions are exactly identical. They receive messages at the same time. They send messages at the same time.
You can create more cases by 'grabbing' the PC timeline and 'sliding' it, holding the message send/receive points fixed relative to their respective timelines. The asymmetries you cause are exactly negated by the clock offset. In fact, you can even make messages go BACKWARDS IN TIME one way (as long as the round trip time is still the same) and the server/client STILL can't tell!
Therefore it is impossible to measure latency asymmetries. In the worst case, where you have no information other than that one way latencies are positive and sum to the round trip time, the accuracy of clock synchronization is limited to the round trip time.
Can intermediate infrastructure help?
Whether or not the intermediate infrastructure can help will be heavily dependent upon your theoretical model of the situation.
If the asymmetry is constant and the intermediate infrastructure is the routers on the communication path between you and the server, then no. Even if each router synchronized their clock with the adjacent router, the errors would compound in the same way as if you had synchronized with the server via communication across the routers.
In the real world you can rely on delays being somewhat symmetric for architectural reasons, repeated synchronizations to reduce asymmetry due to queuing delays (etc), and multiple communication paths to reduce other sorts of asymmetry.
If you put your model's assumptions somewhere in between (because it's interesting to explore model space, of course) I expect the result should also be somewhere in between.
fuente
Consider a network of time servers known to be synchronous,θ={A,B,C} , and a client machine P .
LetTXY be the one way time of flight from machine X to machine Y , with the possibility that TXY≠TYX .
LetΔXY=|TXY−TYX| be the measure of the asymmetry between machine X and Y .
Now, consider that the asymmetry between two synchronous machines can be measured by having the synchronous machines agree to send a one way message to each other at the same time. The difference in the arrival times isΔ between those machines, i.e.:
can be measured.
Now consider the time of flight of circuits:
Consider the client machineP to initiate both of these circuits simultaneously, and measures the difference in arrival times, x :
Bothx and ΔAB are known by previously mentioned measurements, so moving the unknowns to the left hand side:
Similarly, for{CAC,CCA} and {CBC,CCB} it can be shown that:
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,
where,
fuente
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 (delayTXY = 0).
Notice that if you doTAB=TBC=TCA=0 , you get ΔAP=ΔBP=ΔCP=0 .
So what's wrong?x=CAB−CBA=ΔPA+ΔAB+ΔBP
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.
fuente
NTP actually uses 4 time measurementst0,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".
the actual formula isθ=(t1−t0)+(t2−t3)2
note this formula can handle the case where the time from client to servert1−t0 is not the same as from server to client t3−t2 (either shorter or longer).
on networks, delay time is due to two major factors, mainly latency and bandwidth.
in many modern home/business internet connections the upload rate is much smaller than download rates & this would probably affect thet1−t0 vs t3−t2 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.
fuente
If only we could send packets back in time
Assumptions:
fuente
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 nodesN1 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 δ=C1−C2 which is constant for our purposes. Let us furthermore assume that transmission delays d1→2 and d2→1 are constant¹.
HaveN1 send a message timestamped with Tm1 to N2 and let Tr2 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:
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.
fuente