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

Two Nodes

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 1 Drift 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 Node A Node B  A (0)  A (1)  A (2) …  B (0)  B (1)  B (2) …

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

Algorithm 3. For subsequent beats Node B calculates 4. It sends the (n+1)st beat at B KbKb π xkb B π x2 B π x1 B πBBπ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  s (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.

Convergence Time for Different Network Topologies # Nodes Convergence time in Seconds StarChainBidirectionalRandom N/A N/A N/A

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.

Transit Delay and Convergence

Latency Perturbations Node ID 0.01%0.10%1% CTJ % %0.008%0.055% %0.007%0.064% %0.008%0.074% %0.008%0.072% %0.007%0.083% %0.008%0.073% %0.007%0.072% %0.008%0.083%

Drift Rate Perturbation Node ID 100 PPM10 PPM1 PPM CTJ % %0.001%0.000% %0.001%0.000% %0.001%0.000% %0.002%0.000% %0.001%0.000% %0.002%0.000% %0.001%0.000% %0.001%0.000% %0.001%0.000%

Implications This scheme achieves clock synchrony in that all nodes achieve a common cycle value of  The local value  A 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 –  * and  * 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 n a th beat

Two Node Case As a part of the beat message node A also sends –Its converged cycle length –Current cycle number –Time –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

Comparisons CTTIEEE-1588NTPGPSTTPSERCOS Spatial extentGeneralA few subnetsWide area Local bus Communication s GeneralNetworkInternetSatelliteBus or starBus Target accuracySub-microsecond Few millisecondsSub-microsecond StyleDistributedMaster/slavePeer ensembleClient/serverDistributedMaster/Slave Resources Small network message and computatio n footprint Moderate network and computatio n footprint Moderate computatio n footprint Moderate Latency correction Yes ConfiguredNo Drift CorrectionYes No Protocol specifies security No (V2 may include security) YesNo AdministrationSelf organizing ConfiguredN/AConfigured Hardware? For highest accuracy No RF receiver and processor Yes Update intervalConfigured~2 seconds Varies, nominally seconds ~1 second Every TDMA cycle, ~ms

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 …