Let's start with PTPv2 first as Q-SYS follows the AES67 standard which utilizes PTPv2 for time synchronization.
PTPv2 (IEEE -) utilizes a hierarchical selection algorithm known as the Best Master Clock Algorithm (BMCA) to determine the best PTPv2 clock within a network. Devices capable of acting as a PTPv2 grandmaster, such as Q-SYS cores, external grandmaster clocks, certain Cisco switches, and AES67-enabled Dante devices, employ BMCA based on the following properties, in the specified order:
Q-SYS Designer Software allows modification of Priority 1 and Priority 2 values to adjust the grandmaster of the PTP clock domain, so we primarily focus on these two values when it comes to the PTP grandmaster clock election.
Here is a scenario: There is a Core-110f (core1) on the network performing PTPv2, and this is the only device on the network utilizing PTPv2. Since it is the only device on the network, it will be elected as a PTPv2 leader, and there is no doubt about it.
The PTPv2 grandmaster will periodically send out a PTPv2 Announce Message (Q-SYS core sends this out every 2 seconds), and the grandmaster will also send out Sync Messages (Q-SYS core sends this out every 0.125 seconds) to the network.
Let's introduce another Core-110f (core2) to this network participating in the PTPv2 domain with a lower Priority 1 value (higher priority). In theory, the newly added Core-110f (core2) will be elected as the grandmaster.
This is correct. Core2 will eventually get elected as the grandmaster clock. In this article, we will focus on this grandmaster election process.
When core2 is added to the network, both cores will advertise themselves as the leaders of the PTPv2 domain, potentially causing clock drift events if there are clock followers on the network. However, there is no need to worry about it. Both cores will evaluate the other core's PTP properties to decide whether they should continue to be the grandmaster or stop sending out PTP Announce Messages and Sync Messages.
So, how do cores evaluate the other core's PTP properties?
The answer lies in the PTP Announce Message. The PTP Announce Message includes the PTP properties, and here is a sample PTP Announce Message.
In the scenario above, after core1 finishes comparing the PTP properties, it will become a clock follower and no longer send out Announce Messages and Sync Messages.
PTPv1 is an older PTP protocol released in . Although Q-SYS utilizes PTPv2, understanding how PTPv1 works is important, as Audinate/Dante uses PTPv1.
It's also crucial to note that if there's a Software Dante Receiver/Transmitter in the design, the Q-SYS core will participate in the PTPv1 domain as well.
While we've learned that in PTPv2, PTP clocks compare properties by checking the PTP Announce Message, in PTPv1, there's no such thing as a PTP Announce Message, as it was introduced in PTPv2.
So, how do cores evaluate each other's PTP properties in PTPv1?
The answer lies in the PTPv1 Sync Message, and here's a sample:
This packet includes a flag named PTP_EXT_SYNC and two fields named grandmasterPreferred and grandmasterClockStratum.
The PTP_EXT_SYNC field indicates whether the device derives its clock from an external word clock from its host equipment to tune its onboard VCXO.
The grandmasterPreferred value indicates whether the device generating the PTPv1 Sync Message is one of the preferred PTPv1 grandmasters on the network. A value of 1 signifies that it is one of the preferred PTPv1 clocks on the network, whereas a value of 0 indicates that it is not one of the preferred PTPv1 clocks on the network.
The grandmasterClockStratum value in the PTPv1 Sync Message denotes the PTPv1 priority within the network. A lower value suggests a higher likelihood of the device being elected as a PTPv1 grandmaster. The grandmasterClockStratum value actually derives from the localClockStratum value. They are the same if the device itself is a grandmaster clock instead of a boundary clock. For example, let's suppose a Q-SYS 110f core named core2 has both QLAN and Software Dante components in the design, is clocking to another PTPv2 grandmaster on LAN A (core1), and is acting as a PTPv1 grandmaster on LAN B.
In the diagram above, core2 is functioning as a boundary clock and has different grandmasterClockStratum value and localClockStratum value. It will have its own localClockStratum value derived from its user-configured PTP priority values, while the grandmasterClockStratum value is derived from its PTPv2 master's localClockStratum value, which is core1.
I believe we now have a good understanding of the three most important values in the PTPv1 grandmaster election process. Next, we will dive into how the election occurs.
In PTPv1, devices always first consider the PTP_EXT_SYNC flag. If a PTPv1 clock has this flag set to True, the device will become the PTPv1 clock leader.
If there is more than one PTPv1 clock that is clocking to an external word clock, or if there are no clocks syncing to an external word clock, the devices will then consider the grandmasterPreferred value. If one or more preferred PTPv1 clocks exist on the network, non-preferred PTPv1 clocks will not participate in the clock election, regardless of their lower grandmasterClockStratum values. Only among preferred PTPv1 clocks will the election proceed by comparing the grandmasterClockStratum values.
Open Dante Controller > Clock Status and check the Preferred Leader option.
Q-SYS cores cannot be selected as a Preferred Leader in Dante Controller. If the PTP Priority 1 value of a Q-SYS core is less than or equal to 127, it will automatically designate itself as a Preferred Leader.
In conclusion, unlike PTPv2, PTPv1 doesn't have an Announce Message and uses the PTP_EXT_SYNC flag, grandmasterPreferred value, and the grandmasterClockStratum value in the Sync Message to announce its eligibility to become a PTP grandmaster and its clock priority.
PTPv1 (IEEE -) uses similar properties as PTPv2 listed at the beginning of this article, so lowering the Priority 1 and Priority 2 values in Q-SYS Designer Software will lower the localClockStratum value.
The lower the grandmasterClockStratum value, the higher the chance the device will get elected as a PTPv1 grandmaster.
Precision Time Protocol (PTP) is a protocol to synchronize clocks in a computer network, similar to Network Time Protocol (NTP).
NTP is accurate, under ten milliseconds. PTP, however, is accurate up to less than a microsecond and is measured in nanoseconds. Why would you want this? NTP is fine for network clients such as desktops, laptops, or network monitoring. PTP is useful in scenarios where very accurate timing is required. For example:
PTP can be used in these scenarios. One advantage of PTP is that if you already have Ethernet or IP, you can use your existing network for time synchronization. PTP can run directly over Ethernet or on top of IP with UDP for transport.
PTP is an IEEE/IEC standardized protocol defined in IEEE , with multiple versions of PTP. The first version is from , specified in IEEE -. PTP Version 2 (PTPv2) was announced in IEEE -. This version is not backward compatible with the - version. We now also have IEEE -, known as PTPv2.1. This version is compatible with PTPv2 and adds some additional features.
Each industry has different requirements, which is why, besides the standard, there are different profiles. Here are some examples:
There are differences in how PTP is implemented between these profiles. For example:
And there are other differences, such as how often they send messages, the clock types they support, etc.
When we want to synchronize clocks accurately up to nanoseconds, we have to deal with delays. For example:
When one clock transmits the current time, it can be outdated the moment it is received by another clock. Luckily, PTP has a way to deal with this. Delay is inevitable, but we can measure, and PTP can compensate for it.
PTP works best when your hardware supports it. A NIC with PTP support has its own onboard clock, which is used to timestamp messages. You can run PTP in software without hardware support, but your OS will have to take care of timestamping. This negatively affects delay.
There are multiple options where you can timestamp. The closer to the physical layer, the more reliable and less delay you’ll see.
PTP uses the same epoch as Unix time (1 January ) but is based on International Atomic Time (TAI). The abbreviation is from the French name (Temps Atomique International). It’s not based on UTC. One of the reasons is that UTC is subject to leap seconds. PTP communicates the offset between TAI and UTC so that UTC can be calculated from the PTP time.
To ensure clocks are synchronized correctly, PTP must measure the delay between two clocks. We have two clock roles. The time source has the master role, and the time receiver is the slave.
Because of the insensitivity of using slavery as a technical analogy, the IEEE g- amendment replaces the terminology “master” and “slave”. The master will be replaced by “timeTransmitter” and the slave will be replaced by “timeReceiver”. It will take time until all network devices, manuals, and marketing material will be updated. To prevent confusion, I will use the master/slave terminology for now and will update the new terminology in the future when it is more common.PTP synchronizes clocks by exchanging a couple of timestamped messages and storing the time we send and receive these messages. A slave clock calculates its delay and offset and updates its clock accordingly. Let’s look at how PTP synchronizes clocks. I’ll use a simple example with two clocks:
The master clock is at 9:00:00. The slave clock thinks it’s 9:00:10, so we have a 10-second offset. To keep it simple, we’ll imagine we have a one-second delay to transfer packets from the master to the slave clock.
The master periodically sends a sync message. Let’s say it sends a sync message at exactly 09:00:00. This moment is the T1 value. We now have two options:
California Triangle contains other products and information you need, so please check it out.
In my example, we use the two-step message exchange.
The slave clock stores the time it received the sync message as the T2 value. Its local clock believes it is 09:00:12. The slave clock now knows there is a 10-second difference between its local clock and the master clock. However, it can’t update itself yet because it doesn’t know how long it took to get a message from the master to the slave clock.
To synchronize itself correctly, it has to calculate two values:
Here are the two formulas to calculate these two values:
delay = ((t2 - t1) + (t4 - t3)) / 2offset = ((t2 - t1) - (t4 - t3)) / 2We have seen T1 and T2, but we haven’t seen T3 and T4 yet.
When the slave clock receives the follow-up message, it sends a delay request message. As the name implies, this message is used to determine the delay between the master and slave clock. The slave clock stores the time it sent this message as the T3 value. From the slave clock’s perspective, at 09:00:12.
Because of our one-second delay, the master clock receives it at 09:00:03. The master clock stores this moment as T4.
The master clock replies immediately with a delay response message that includes the T4 value. The slave clock now has four timestamps:
The slave clock can now calculate the offset relative to the master clock. The offset calculation assumes that the delay in propagating the message from the master to the slave clock is the same as the other way around. This is not always the case on Ethernet networks, though.
Let’s put everything in the delay and offset formula. Everything starts with 09:00, so we’ll focus on the seconds. Let’s start with delay. Here is the formula to calculate delay:
delay = ((t2 - t1) + (t4 - t3)) / 2Let’s add our numbers:
delay = ((11 - 0) + (3 - 12)) / 2Let’s break it down:
(11 - 0) = 11
(3 - 12) = -9
11 + -9 = 2
2 / 2 = 1The delay is calculated as one second. Now, we’ll calculate the offset. Here is the formula:
offset = ((t2 - t1) - (t4 - t3)) / 2Let’s add our numbers:
offset = ((11 - 0) - (3 - 12)) / 2Let’s break it down:
(11 - 0) = 11
(3 - 12) = -9
11 - -9 = 20
20 / 2 = 10The calculated offset is 10 seconds. The slave clock updates itself, offsetting its clock by 10 seconds. Network delay can change over time, so the master clock will keep sending sync messages.
PTP has different clock types. Here is an overview:
There are four clock types:
Besides the clock type, each interface can have the master (M) or slave (S) role. The master sends timing information, and the slave synchronizes itself. Depending on the clock type, an interface can have the master or slave role. It’s also possible that a clock has the master role on one interface and the slave role on another interface.
Let’s look at the different clock types.
The grandmaster clock (GMC) is the primary source of time in PTP and is responsible for root timing reference. This clock is connected to a reliable time source, such as GPS or an atomic clock. All other clocks synchronize directly or indirectly with the grand master clock. The grandmaster clock always has the master role on its interface(s).
The ordinary clock (OC) runs PTP on only one of its interfaces. This interface can have the slave or master role. This is usually an end device that needs its time synchronized.
The boundary clock (BC) runs PTP on two or more interfaces. It can synchronize one network segment with another. The upstream interface that connects to the grandmaster clock has the slave role. The downstream interface that connects to other clocks has the master role.
A boundary clock sits between the grandmaster clock and other boundary or ordinary clocks. Each interface can connect to a different VLAN to synchronize time in different VLANs. Adding boundary clocks to the network also has a scalability advantage because it prevents all ordinary clocks from having to talk with the grandmaster clock directly.
Each boundary clock syncs with an upstream clock and distributes time based on its local clock. This means that each clock depends on the quality of all upstream clocks. The more boundary clocks you add, the higher the chance your clocks are not as accurate anymore. Because of this, using boundary clocks is only suitable for networks with a small number of switches.
Transparent clocks (TC) were introduced in PTPv2, and their goal is to forward PTP messages. They can’t be a source clock like a grandmaster or boundary clock. They can forward PTP messages within a VLAN but not between VLANs.
The transparent clock can sit between the grandmaster clock and an ordinary clock. When we forward a PTP message through the transparent clock, the delay increases, which must be compensated. The transparent clock measures this delay and adds it to the correction field of a PTP message. This added time is called the residence time.
There are two transparent clock types:
Let’s check them out.
The end-to-end (E2) transparent clock sits between the grandmaster and the ordinary clock and transparently forwards PTP messages. Here’s what it looks like:
We see the same messages as those discussed in the clock synchronization section. The blue arrows indicate the time it takes for the transparent clock to forward these messages. This adds delay, and it must be compensated. Transparent clocks keep track of the time it takes to forward a PTP message. This is called the residence time (RT). Transparent clocks add this time in the correction field of PTP messages so that the ordinary clock can compensate for the delay.
The idea behind the peer-to-peer transparent clock (P2P) is that it’s better to calculate the delay for each interface than end-to-end. The P2p transparent clock calculates the delay from:
Here’s what that looks like:
When a grandmaster clock sends a sync (and follow-up) message, the transparent clock forwards these messages to the ordinary clock. It also sends a peer delay request message to the grandmaster clock and receives a peer delay response message. The same peer delay message exchange occurs with the ordinary clock. This allows the transparent clock to figure out the delay on both interfaces. It also keeps track of the residence time and adds this in the correction field of PTP messages.
Why would you pick E2E transparent clocks or P2P transparent clocks? Take a look at this picture:
Above, we have a hierarchical network with PTP clocks. Imagine we have 500 ordinary clocks. If the transparent clocks were all E2E, the grandmaster clock would receive 500 delay request messages from all ordinary clocks. This doesn’t scale well.
With P2P transparent clocks, peer delay messages are only sent between one upstream or downstream clock. Peer-to-peer is more efficient because the delay is calculated on a single link, not end-to-end. Also, the ordinary clocks won’t send delay messages directly to the grandmaster clock.
How do we define which clock becomes the master? We compare announce messages to determine which clock is the most accurate. We use the following order of items to determine the best master clock:
When the BMC algorithm finishes, the master clock sends sync messages at regular intervals. When a current master clock recognizes a new best master clock, it stops sending sync messages (or announce messages when using IEEE -), and the new clock takes over as master.
The Best Master Clock Algorithm (BMCA) will be renamed to Best TimeTransmitter Clock Algorithm (BTCA) because of the reasons explained in the master/slave terminology. I will use BMCA throughout this lesson until the new terminology is more common and used on Cisco switches.Throughout this lesson, I explained some of the PTP messages. It’s useful to have a complete overview of all PTP messages and their function. There are two message types:
Let’s check out both.
Event messages are time-critical. These are used to measure the time delay between clocks and are timestamped.
General messages are not time-critical and don’t have timestamps. They are used to maintain PTP’s operation and manage the state of clocks.
Enough theory for now. Let’s look at PTP in action.
Want more information on PTP Grandmaster Clock? Feel free to contact us.