Commit c681e0c0 authored by Peter Waher's avatar Peter Waher

Clock synchronization

parent 2fd49164
......@@ -28,19 +28,30 @@ to a relative high degree of accuracy.
Process
------------------------
The Synchronization namespace only defines one simple element: `clock`, which is an element of the simple type `xs:dateTime`. The client sends its time
(in UTC) ct<sub>1</sub> to the clock source, who immediately responds with a `clock` element of its own, with its time (in UTC) st. When the client receives the response,
it notes its own time again (in UTC) ct<sub>2</sub>.
The Synchronization namespace defines one element: `req`, which is used in an `iq get` stanza to request information about the clock of the destination.
It responds with an `iq result` stanza containing an `resp` element. It has a required value containing the current date and time, in the format of
simple type `xs:dateTime`. Note that an arbitrary precision can be used in the decimal part of the second portion of the `xs:dateTime` data type.
Optionally, the `resp` element can also contain information about the high-frequency timer on the destination machine, if one is available. This is done
through the optional attributes `hf` and `freq`. The `hf` attribute contains the number of ticks since the timer started, and the `freq` attribute contains
the number of increments `hf` makes in one second. This high-frequency timer can be used instead of the date and time value, if high-precision synchronization
is required, without knowledge about the exact date and time of day.
**Note**: The reference of the high-frequency timer may change when the clock source restarts, or if another machine responds, such as might be the case if the
clock source is hosted in a cluster or in the cloud.
The client makes a note of its time (in UTC) ct<sub>1</sub> of its internal clock. It then sends a `req` request to the clock source, who immediately responds
with a `resp` element of its own, containing its time (in UTC) st. When the client receives the response, it notes its own time again (in UTC) ct<sub>2</sub>.
![Clock Synchronization](Diagrams/Synchronization.png)
Δt<sub>1</sub>=st-ct<sub>1</sub> is given variation in the network and operating system processes approximately
equal to the latency in the network l plus the difference between the client and souce clocks Δt. The response, which travels in the other direction, can be used to
to calculate Δt<sub>2</sub>=ct<sub>2</sub>-st which is approximately equal to the latency in the network l minus the difference between the client and souce clocks Δt.
The latency l is therefore approximately half of Δt<sub>1</sub>+Δt<sub>2</sub>. The difference in clocks Δt is approximately half of Δt<sub>1</sub>-Δt<sub>2</sub>.
Given variation in the network and operating system processes, Δt<sub>1</sub>=st-ct<sub>1</sub> is approximately equal to the latency in the network l plus the
difference between the client and souce clocks Δt. The response, which travels in the other direction, can be used to calculate Δt<sub>2</sub>=ct<sub>2</sub>-st,
which is approximately equal to the latency in the network l minus the difference between the client and souce clocks Δt. The latency l is therefore approximately
half of Δt<sub>1</sub>+Δt<sub>2</sub>. The difference in clocks Δt is approximately half of Δt<sub>1</sub>-Δt<sub>2</sub>.
To decrease the variation of network and process activity, an average value over a time window should be used. The internal clocks of the client and server can be
considered much more stable than the latency in the network. The bulk of the variance in the measured l and Δt can therefore be attributed to variance in the network,
To decrease the variation of network and process activity, estimated values should be filtered to remove suspected measurement errors due to random events. An average
value over a given window of filtered values should also be used, to decrease error. The internal clocks of the client and server can be
considered as more stable than the latency in the network. The bulk of the variance in the measured l and Δt can therefore be attributed to variance in the network,
as well as concurrent processes and loads on the client and clock source.
Examples
......
Diagrams/Synchronization.png

19.7 KB | W: | H:

Diagrams/Synchronization.png

19.4 KB | W: | H:

Diagrams/Synchronization.png
Diagrams/Synchronization.png
Diagrams/Synchronization.png
Diagrams/Synchronization.png
  • 2-up
  • Swipe
  • Onion skin
This diff is collapsed.
......@@ -4,12 +4,12 @@ Activate Client
group Average results using time window
Client -> Client : <math>ct_1=ClientTime_{UTC}</math>
Client -> Source : clock(ct1)
Client -> Source : req
Activate Source
Source -> Source : <math>st=SourceTime_{UTC}</math>
Client <-- Source : clock(st)
Client <-- Source : resp(st)
Deactivate Source
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment