IEEE-1588 synchronization

IEEE-1588 synchronization

In continuation of time-synchronization article series, conceptually, IEEE-1588 synchronization is as simple as if you were asking the time from somebody and (s)he replying after looking at his/her watch. You would then correct your watch accordingly. This is simply:

Time to be set = Time told + some delay
But this simplicity just ends here.

Let us look at some of the issues we would face in the above scheme:

  1. To be very precise, you might want to calculate the exact delay it took him/her to tell you the time.
  2. In addition compensate for the time it would take you to set your own watch accordingly.
  3. What if this person is 4 km away and fastest way he can tell you the time is writing it on a piece of paper and sending through a homing pigeon? (No other source available)
  4. For calculating above delays whose time would you consider? Your own watch is not working as expected and you of course cannot borrow that person’s watch and there is no other reference.
  5. You definitely have no way of knowing when this carrier started flying towards you or if he lost his way in between, once or more, and took some breaks too.
  6. You probably want to send your own pet homing pigeons, to fly to him and back, to get an idea of flying latency by dividing this time by half.
  7. And if the delay you finally approximate is significantly more than the preciseness with which you want to set the time in your watch? Is it even possible?
  8. Maybe you plan to average out these delays over several trips to get a better approximation.
  9. Would your calculations be generic enough to give you the correct result, if this homing pigeon were to be replaced with a homing-duck or on the contrary if this person can tell you the time directly by calling on your phone?
  10. Wouldn’t your averaging process get skewed if you got no intimation of this abrupt change in carrier? Is there a way to know looking at the time-stamp? What if it is just a gradual but continuous slip?
  11. How would you conclude that your time is finally set and accurate w.r.t. that person? There is no second/third reference.
  12. Would you set your watch only once or correct it at every instance of the pigeon’s flight?
  13. Would you benefit by employing more than one flying carriers?

These questions are not an exaggeration of the situation, because in the computer networks the IEEE 1588 synchronization protocol aims at providing nanosecond accuracy even when the packets that are carrying the time-stamp data have millisecond latencies and sudden, random variations in delay, PDV (Packet Delay Variation), due to congestion, link failures and in addition the dynamic route changes, that remain invisible to the communicating nodes at two ends.

Let us now see how IEEE 1588v2 (version 2) works and accomplishes synchronization. The next figure is what you would commonly see no matter where you start reading about this technology because it depicts the idea very neatly:

IEEE-1588 synchronization

(Source: RTA Automation)

There are various interesting things to note in this figure:

  1. There are two time-lines (Master on left and Salve on right hand side) that depict the time in their respective clocks at any instant.
  2. Slave is a system that wants to synchronize its time with the Master clock. Master may be any system that is itself a very precise clock or getting synchronized from somewhere else.
  3. Slave clock (as you can see on top) starts from a garbage value (30) which is un-important and ir-relevant as it has to finally correct this time.
  4. It is also unimportant “when” the slave wants to synchronize with master. Slave system can boot-up at any time and wish to synchronize no matter what time it is.
  5. In IEEE-1588 synchronizaion, a Master system sends “Sync” messages (periodically) to the interested slaves. These are a type of PTP (Precision Time Protocol) messages that are sent over the IP protocol and contain the time-stamp (t1) when this packet left the master (like when the homing pigeon starts flying).
  6. This Sync Message reaches the slave system at time (t2). Note here that t1, t2 are not comparable with each other as they come from different clocks running independently, at least one of which (slave) contains a garbage value to start with. The only thing common between them is that both are the same physical quantity i.e. TIME. Also, we have discussed before that, it is not wise to say that slave is behind or ahead of master until we know for sure that slave is not faster or slower than the master. Otherwise no matter how much precisely we correct the slave clock, it will drift off.
  7. Once the Sync message has reached, the slave has two time-stamps t1 and t2. The slave can set its own time as equal to t1, but then it would not have accounted for the network delay (the time it took pigeon to fly to you) and a mere subtraction of these two would not give any meaningful information as both these clocks started at different unrelated and unknown times.
  8. In order to estimate this network delay, the slave sends a “Delay-Request” message back to the master at time t3, and the master replies to this with a “Delay-Response” message containing its own time t4, giving slave four different time-stamps to calculate the delay between master and slave, i.e. a set of {t1, t2, t3, t4}
  9. There is a concept of “Follow-up” message, but I will defer it for a later discussion.


...that's not all folks!

To continue reading the article, please Login/Register

(c) AVChrono 2021, All Rights Reserved

AV Chrono

Back to top
You cannot copy content of this page
%d bloggers like this: