How to calculate Clock Skew of nodes in a distributed system

Click For Summary

Discussion Overview

The discussion revolves around calculating the maximum clock skew of three nodes in a distributed system, each with different clock rates. Participants explore various methods for determining clock skew based on the nodes' tick rates and synchronization intervals with an external time source.

Discussion Character

  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • One participant calculates the maximum clock skew as 1/15000 seconds based on the difference in tick rates between nodes N2 and N3.
  • Another participant suggests that the maximum clock skew will be 200μs every ms, arguing that the 30-second synchronization interval is relevant only if all nodes assume a tick rate of 800 counts/ms.
  • There is a claim that the clock skew could be calculated as -0.37 seconds and 0.19 seconds over 30 seconds based on the tick rates of N1, N2, and N3.
  • One participant challenges the 200μs claim, suggesting it should be 200ms instead, and proposes an alternative calculation leading to a maximum skew of 0.56 seconds between N2 and N3.
  • Another participant emphasizes that if N2 and N3 are aware of their tick rates, they would synchronize correctly within 200μs, leading to a maximum skew of 2.5μs.
  • There is a request for clarification on how the 200μs figure was derived, with a reference to the common factor of 5 in the tick rates.

Areas of Agreement / Disagreement

Participants express differing views on the calculation of clock skew, with no consensus reached on the correct method or final value. Multiple competing approaches and interpretations of the problem are presented.

Contextual Notes

Participants' calculations depend on assumptions about the nodes' knowledge of their tick rates and the relevance of the synchronization interval. There are unresolved mathematical steps and varying interpretations of the clock skew concept.

22990atinesh
Messages
143
Reaction score
1
A distributed system has 3 nodes ##N_1##, ##N_2## and ##N_3##, each having its own clock. The clocks of nodes ##N_1##, ##N_2## and ##N_3## tick 800, 810 and 795 times/ms. The system uses the external synchronization mechanism, in which all 3 nodes receive the real time every 30 seconds from external time source and readjust their clocks. What is the maximum Clock Skew that will occur in this system ?

Attempt: Maximum difference would come between ##N_2## and ##N_3## i.e, ##N_2## - ##N_3## = 15 times/ms = 15000 times/s
Clock Skew = 1/15000 s

Is it the right way to calculate ...
 
Physics news on Phys.org
22990atinesh said:
What is the maximum Clock Skew that will occur in this system ?
Looking at your numbers and assuming that the nodes know about their tick rates, I see a common factor of 5. This means that the maximum clock skew will be 200μs every ms.

The only way the 30s would be relevant is that all nodes believe that they have a tick rate of 800/ms. Then the clock skew in 30s will be \frac{800-810}{810}\cdot 30s = -0.37s and \frac{800-795}{795}\cdot 30s = 0.19s.
 
Svein said:
Looking at your numbers and assuming that the nodes know about their tick rates, I see a common factor of 5. This means that the maximum clock skew will be 200μs every ms.

The only way the 30s would be relevant is that all nodes believe that they have a tick rate of 800/ms. Then the clock skew in 30s will be \frac{800-810}{810}\cdot 30s = -0.37s and \frac{800-795}{795}\cdot 30s = 0.19s.

Can you please elaborate it little bit more How you have calculated clock skew.
First of all : I think Clock Skew should be 200 ms in place of 200 μs.
Secondly: By your method, I'm getting maximum clock skew as 0.56 s by considering ##N_2## and ##N_3##
Thirdly: Can I use this method
Maximum skew in 1 sec between n2 & n3 = (.810 - .795)
= .015 sec
Thus, skew in 30 sec = .015 * 30 = .45 sec
 
Last edited:
22990atinesh said:
Can you please elaborate it little bit more How you have calculated clock skew.
First of all : I think Clock Skew should be 200 ms in place of 200 μs.
  1. I do not think the clock skew should be 200ms each ms...
  2. If N2 and N3 know that they should use 810 and 795 counts/ms, they would be correct each ms.
  3. If they know their counts, in 200μs N1 will have counted to 160, N2 to 162 and N3 to 159. Therefore they are in sync after 200μs.
  4. Worst case is just before 200μs - but it is maximum 2 counts out of 160: 2.5μs.
22990atinesh said:
Maximum skew in 1 sec between n2 & n3 = (.810 - .795)
= .015 sec. Thus, skew in 30 sec = .015 * 30 = .45 sec
I would not have used that method.
 
Svein said:
  1. I do not think the clock skew should be 200ms each ms...
  2. If N2 and N3 know that they should use 810 and 795 counts/ms, they would be correct each ms.
  3. If they know their counts, in 200μs N1 will have counted to 160, N2 to 162 and N3 to 159. Therefore they are in sync after 200μs.
  4. Worst case is just before 200μs - but it is maximum 2 counts out of 160: 2.5μs.
I would not have used that method.

How do you come up with 200 μs, that's what I'm not getting. Can you please elaborate your procedure.
 
22990atinesh said:
How do you come up with 200 μs, that's what I'm not getting. Can you please elaborate your procedure.
You specified 800, 810 and 795 counts per millisecond. I see 5 as a common factor, one fifth of a millisecond is 200 μs. One fifth of the counts are 160, 162 and 159 counts.
 

Similar threads

  • · Replies 6 ·
Replies
6
Views
5K
  • · Replies 1 ·
Replies
1
Views
3K
Replies
1
Views
3K
  • · Replies 1 ·
Replies
1
Views
2K
  • · Replies 26 ·
Replies
26
Views
3K
Replies
1
Views
2K
  • · Replies 2 ·
Replies
2
Views
8K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 1 ·
Replies
1
Views
12K