1 / 34

Cyclone Time Technology Deriving Consistent Time Base Using Local Clock Information

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

ludwig
Download Presentation

Cyclone Time Technology Deriving Consistent Time Base Using Local Clock Information

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Cyclone Time TechnologyDeriving Consistent Time Base Using Local Clock Information Ashok Agrawala Moustafa Youssef Bao Trinh University of Maryland College Park, MD 20742

  2. 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

  3. 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

  4. Two Nodes

  5. 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

  6. Outline • Introduction • Drift correction scheme (Cyclone) • Results • Virtual Clock Scheme • Conclusions

  7. 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

  8. Two Nodes pA(2) … pA(0) pA(1) Node A Node B pB(2) … pB(0) pB(1)

  9. Algorithm • Initially each node sends the 0th beat at 2. Each node sends the 1st beat at

  10. Algorithm 3. For subsequent beats Node B calculates 4. It sends the (n+1)st beat at Kb πx2B πx1B πxkbB B πBB

  11. Analysis Similarly Therefore

  12. 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.

  13. 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.

  14. Outline • Introduction • Drift correction scheme (Cyclone) • Results • Virtual Clock Scheme • Conclusions

  15. 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

  16. 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.

  17. Convergence Time for Different Network Topologies

  18. 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.

  19. Transit Delay and Convergence

  20. Latency Perturbations

  21. Drift Rate Perturbation

  22. 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 ??

  23. Outline • Introduction • Drift correction scheme (Cyclone) • Results • Virtual Clock Scheme • Conclusions

  24. 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

  25. Assumptions • For the discussion right now we add two additional assumptions: • All connections are bidirectional • Transit time in two directions are the same

  26. Approach • Carry out the first scheme and reach convergence • At convergence we note that • The time when node A sends its nath beat

  27. 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

  28. Calculations Similar calculations are done by node B Node A can convert its local time to the time at Node B as

  29. Multinode Operations • When this phase starts • For each of its incoming links node A calculates It initializes

  30. 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.

  31. On Convergence • Node A has values It can convert its local clock values to Virtual global clock as

  32. Current Status • Simulation Results confirm the claims • Working on prototype implementations using standard NICs

  33. Comparisons

  34. 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 • …

More Related