# clock synchronization

Is there something I'm not seeing or there is a flow in this algorithm(which everyone is referring to) http://www.mine-control.com/zack/timesync/timesync.html

Assumption 1: When I say a is substracted from b it means "b - a", maybe in the text they actually meant the other way arround? I would guess so. Assumption 2: the synchronization is to get the server clock on the client - If this is the gase shouldn't latency from server to client suffice?

Anyway, he article says: Client sends packet with timestamp t1, Server responds with it's timestamp t2. Client receves this packet at t3. So t3 > t2 > t1

RTT = t1 - t3 (gives a negative value, I guess it should be t3 - t1) latency = RTT / 2 (more or less, again it shoul be positive) client server time delta = t2 - t3 (server timestamp - current time) clock delta = t2 - t3 + RTT/2 (again, gives a negative value, abs again?)

Surely this cannot be... if the client time to server time is the same as the client thrn the clock delta is the RTT or 0 if I do abs (t2 -t3) + RTT/2.

if it is latencies are asymetric then the las calculation gives different results depending where I put abs abs(t2 - t3) + RTT/2 abs(t2 - t3) + abs (RTT/2) t2 - t3 + abs(RTT/2)

• I was trying to solve a slightly different problem (or I understood that the problem they were trying to solve is a different one). This also clears is it up a bit: docs.gamesparks.com/tutorials/real-time-services/… – Sil Oct 8 '18 at 18:10

The industry standard network time protocol (NTP) also takes into account the latency of the server processing. This means there are 4 timestamps, one each for send/receive of client/server. when properly calibrated it would look like: t_cr > t_ss > t_sr > t_cs and t_cr - t_ss == t_sr - t_cs
The offset needed is = (t_ss + t_sr)/2 - (t_cs + t_cr)/2 adding this to the client time will line them up.