In a previous article I went over the basics of Handling Clocks in Software. For this article, the theme will be continued as we look at global clock recovery, distributed clock synchronization, and event synchronization.
Global clock recovery
Suppose there are several agents in a complex system. Each one of these will have its own reference clock that gives it a sense of time. An agent's notion of time is given by how many reference clock ticks have passed since startup.
To synchronize actions and share clocks the agents need to have a common, global sense of time. This is easy with a bus system like USB or Firewire, since a bus tends to carry its own clock. However, for distributed, packet-based interconnects, things get harder. The IEEE standards 1588, 1588v2 and 802.1as and the IETF NTP standard are designed to specifically address the problem of distributed global clock recovery.
The first task of the system is to elect one of the agents as the master. It is this agent's clock that will become the common global clock. IEEE 1588 and variants use a peer-to-peer leadership election protocol that tries to elect the highest quality clock amongst the agents. It is guaranteed to elect one, and only one, master.
Once the master is elected, each agent needs to know the following information:
- Is my clock going slower/faster than the global master clock? If so, by how much?
- What is the current time now according to the master clock?
The fundamental method used is to regularly transmit synchronization messages from the master to the other agents. The message contains the global time that the message was sent. The following diagram shows this happening:
The slave knows the outgoing timestamps performed by the master (Tm1, Tm2 and Tm3), as well as the inbound timestamps performed by the slave (Ts1, Ts2 and Ts3). Given these timestamps it can work out the ratio between the master clock and its own local clock. For example, the following calculation performs a measure of the ratio between the two clocks:
Multiple measures of this value can be filtered to average out variations in the transit time. Tracking the value over time will also track any drift in the two clocks involved.
To fully convert between global time and local time, the slave also needs to know its time offset from the master, which means it needs to know the transit time of the sync messages. To do this, the master and slave perform a two way exchange of messages:
Assuming that the transit time is symmetrical then:
So:
Care is needed here, since the timestamps Tm2 and Tm1 are taken with reference to a different clock than Ts2 and Ts1. So the slave needs to make the calculation:
Knowing this transit time allows the slave to work out its offset from the master clock. It now has all the information it needs to convert between global and local time and vice-versa.
In reality, the time synchronization protocols like 802.1as are a bit more complicated than what is portrayed here, but the basic idea is the same.
Event synchronization
Once global clock synchronization is in place. The local agents can convert global time into local time:
This means that two agents can synchronize their actions. Each is given a global time to perform an event. The agents covert this global time to local time and then schedule the event to happen at that time. Of course, the events will not happen at exactly the same time. There will be some synchronization error. This error is comprised of:
- Error due to the global clock recovery
- Error due to variability in the agent's ability to trigger an event at a particular local time.
- Error due to variation in the agent's local clock since the last synchronization
The magnitude of these errors will depend on the communication technology, the synchronization protocol, the accuracy of the message time-stamping between agents and the local event synchronization within the agent.
In the situation where communication is over Ethernet, using IEEE 802.1as for a time synchronization protocol and an XMOS XCore device as the agent, the synchronization error can be less than 150 ns.
Recovery of other clocks based on a global clock
Sometimes there is a need to recover a secondary clock using global time as a reference. This is the case in the IEEE AVB 1722 standard, where a media clock needs to be recovered to transmit audio or video from one endpoint to another.
In this case, the clock is recovered using a control loop as described in my previous article on software clocking. The difference in this case is how the error is detected.
The agent transmitting the clock can also transmit the expected time that certain clock edges should occur. When the slave recovers and outputs a clock, it can track when that edge actually occurs and get a delta between the expected and actual time. The existence of the global clock allows the agents to have a common timebase to calculate the delta.
This delta gives the error term to feed into a P-I-D control loop. However, there is one further “gotcha” to be aware of. The aim is to recover the clock period; that makes the delta between the expected and actual edge time the integrated error and not the proportional error. This means that the proportional error is the rate of change of the delta. Once this is understood, the control loop can be tuned in a standard manner.
