340 likes | 501 Views
Cyclone Time Technology Deriving Consistent Time Base Using Local Clock Information. Ashok Agrawala Moustafa Youssef Bao Trinh University of Maryland College Park, MD 20742. Some Common Characteristics. Peer-to-Peer Architecture
E N D
Cyclone Time TechnologyDeriving Consistent Time Base Using Local Clock Information Ashok Agrawala Moustafa Youssef Bao Trinh University of Maryland College Park, MD 20742
Some Common Characteristics • Peer-to-Peer Architecture • The scheme relies only on local information or what they can obtain from their immediate neighbors • No central/master clock • Fast convergence
Clock Model • Each node has a local clock which ticks at a constant rate • The clock is stable in that its drift rate does not change rapidly • Local time can be recorded at any instant by reading the clock which is an integer register incremented every tick time • Local time at any node A is represented as • Where • is the current local time at node A at time instant • is the drift rate of the clock at node A, and • is the offset
Assumptions • All nodes are connected in that there is a path from any node to every other node. • The transit time for a message from Node A to Node B, ΔAB, is fixed ( relaxed later). • Each node is capable of timestamping an incoming message with its local clock time to within a clock tick. • Each node is capable of sending a message at a defined local time to within a clock tick • If there is a variability in timestamping operation, this gets lumped into the variability in the transit time
Outline • Introduction • Drift correction scheme (Cyclone) • Results • Virtual Clock Scheme • Conclusions
Scheme 1Drift Correction (Cyclone) • Goal : Correct drift at all nodes • Each node sends a beat message at times it determines from its local information • This message is only a time marker with no other information bits • Each node uses a common constant number whose value is fixed at design time
Two Nodes pA(2) … pA(0) pA(1) Node A Node B pB(2) … pB(0) pB(1)
Algorithm • Initially each node sends the 0th beat at 2. Each node sends the 1st beat at
Algorithm 3. For subsequent beats Node B calculates 4. It sends the (n+1)st beat at Kb πx2B πx1B πxkbB B πBB
Analysis Similarly Therefore
Analysis Matrix Notation Thus at each step we carry out a distributed calculation of As A is a stochastic matrix, this iteration converges with all items in the vector taking the same value. Convergence rate is determined by the second dominant eigen value.
Practical Considerations • Transit delay • We assume it to be a constant. If it has some variability, it will have to be treated as a random variable. In that case the degree of clock synchronization depends on the jitter in the transit delay. • When transit time is much larger than the cycle time, special steps are required in the beginning of the operations • Finite precision • The development above assumed an infinite precision arithmetic and infinite resolution clocks. • These are small perturbations to the calculations but have to make sure that their affects do not accumulate. • Require phase locking.
Outline • Introduction • Drift correction scheme (Cyclone) • Results • Virtual Clock Scheme • Conclusions
Simulation Parameters • Clock Tick Time – 100 ps (10 GHz) • Cycle Time – 125 ms (8000/sec) • Latencies – Random 0 and 80 cycles • Topologies • Chain • Star • Random • Drift rate - ±100 ppm
Simulation Results • Convergence achieved every time • On convergence, jitter 1-2 clock ticks • Long Term Stability • Similar jitter and no drift after 12 hours of simulation time.
Effects of Perturbations • Transit time • Varied by 10% • No more than the transit time change • Stabilizes very fast after that • Clock Drift • Varied again by 10% • Again, a step change results in immediate jitter determined by the change in clock drift • Stabilizes very fast.
Implications • This scheme achieves clock synchrony in that all nodes achieve a common cycle value of p* • The local value pA is different at each node • The beat instants are not synchronized • They do not drift How to achieve a common clock reading ??
Outline • Introduction • Drift correction scheme (Cyclone) • Results • Virtual Clock Scheme • Conclusions
Virtual Global Clock • A clock with parameters • b* and a* We define a scheme such that based only on local information any node can convert its local time to the time at this Virtual Global Clock. Key idea is to use a distributed consensus technique
Assumptions • For the discussion right now we add two additional assumptions: • All connections are bidirectional • Transit time in two directions are the same
Approach • Carry out the first scheme and reach convergence • At convergence we note that • The time when node A sends its nath beat
Two Node Case • As a part of the beat message node A also sends • Its converged cycle length • Current cycle number • Time • Time • A value • A value • Node B sends similar values
Calculations Similar calculations are done by node B Node A can convert its local time to the time at Node B as
Multinode Operations • When this phase starts • For each of its incoming links node A calculates It initializes
Multinode Operations • For each subsequent cycle • It calculates the new values of A and B as averages of incoming values of A and B adjusted to the local scale.
On Convergence • Node A has values It can convert its local clock values to Virtual global clock as
Current Status • Simulation Results confirm the claims • Working on prototype implementations using standard NICs
Concluding Remarks • Use of consensus approach simplifies the clock synchronization • As the scheme only depends on local information it is highly scalable • Primary results to date • Analytic • Simulation • Implementations ? • Appropriate estimators/filters • Practical considerations • Node Failure • Node Joining • …