Many articles have been written about the well-known Network Time Protocol (NTP), some of them mention the Precision Time Protocol, which supposedly makes it possible to achieve time synchronization accuracy of the order of nanoseconds (for example, and ). Let's figure out what this protocol is and how such accuracy is achieved. We’ll also see the results of my work with this protocol.
Introduction
"Precision Time Protocol" is described by the IEEE 1588 standard. There are 2 versions of the standard. The first version was released in 2002, then the standard was revised in 2008 and the PTPv2 protocol was released. Backward compatibility has not been maintained.I'm working with the second version of the protocol, it has many improvements over the first (accuracy, stability, as the wiki tells us). I will not make comparisons with NTP, the mere mention of synchronization accuracy, and the accuracy of PTP actually reaches tens of nanoseconds with “hardware” support, indicates an advantage over NTP.
Hardware support for the protocol can be implemented differently in different devices. In fact, the minimum required to implement PTP is the ability of the hardware to put a time stamp on the moment the message was received on the port. The entered time will be used to calculate the error.
Why does the clock get upset?
Errors can come from anywhere. Let's start with the fact that the frequency generators in the devices are different and there is a very low probability that two different devices will work perfectly in time. This can also be attributed to constantly changing environmental conditions affecting the generated frequency.What are we trying to achieve?
Let's say we have a device that operates under ideal conditions, some kind of atomic clock that will not move at all until the end of the world (of course, before the real one, and not the one predicted by the Mayan calendar) and we are given the task of obtaining at least approximately (with an accuracy of 10 -9 sec) same hours. We need to synchronize these clocks. To do this, you can implement the PTP protocol.The difference between a purely software implementation and an implementation with “hardware support”
A purely software implementation will not achieve the promised accuracy. The time elapsed from the moment of receiving a message (more precisely, receiving a signal to receive a message in the device) until the transition to the interrupt entry point or callback cannot be strictly defined. “Smart hardware” with PTP support can set these timestamps independently (for example, chips from Micrel, I’m writing a driver for the KSZ8463MLI).In addition to time stamps, “hardware” support also includes the ability to tune a quartz oscillator (to align the frequency with the master), or the ability to adjust the clock (increase the clock value by X ns each clock cycle). More on this below.
Let's move on to the IEEE 1588 standard
The standard is described on as many as 289 pages. Let's consider the minimum required to implement the protocol. PTP is a client-server synchronization protocol, i.e. At least 2 devices are required to implement the protocol. So, the Master device is an atomic clock, and the Slave device is a clock that must be made to work accurately.Exchange language
Announce message– announcement message, contains information sent by the master to all Slave devices. The slave device can use this message to select the best master (there is a BMC (Best Master Clock) algorithm for this). BMC is not that interesting. This algorithm can be easily found in the standard. The selection is based on message fields such as accuracy, variance, class, priority, etc. Let's move on to other messages.Sync/Follow Up, DelayResp, PDelayResp/PDelayFollowUp– are sent by the master; below we will look at them in more detail.
DelayReq, PDelayReq– Slave device requests.
As you can see, the Slave device is not verbose; the Master provides almost all the information itself. Sending is carried out to Multicast (if desired, you can use Unicast mode) addresses strictly defined in the standard. For PDelay messages have a separate address (01-80-C2-00-00-0E for Ethernet and 224.0.0.107 for UDP). Other messages are sent to 01-1B-19-00-00-00 or 224.0.1.129. Packets differ by fields ClockIdentity(clock ID) and SequenceId(package identifier).
Work session
Let's say the master was selected using the BMC algorithm, or the master is the only one on the network. The picture shows the procedure for communication between the main device and the synchronized one.
- It all starts with Master sending a message Sync and simultaneously records the sending time t1. There are one- and two-stage operating modes. It is very easy to distinguish them: if there is a message FollowUp– then we are dealing with a two-stage implementation, the dotted arrow shows optional messages
- FollowUp the message is sent after Sync and contains time t1. If the transfer is carried out in one stage, then Sync contains t1 in the body of the message. In any case, t1 will be received by our device. At the time of receiving the message Sync timestamp t2 is generated on Slave. Thus we get t1, t2
- Slave generates a message DelayReq simultaneously with t3 generation
- Master receives DelayReq message while generating t4
- t4 is sent to the Salve device in DelayResp message
Online messages
An exchange session like the one shown above can only be successful if the quartz generates perfectly equal frequencies for the devices being synchronized. In fact, it turns out that the clock frequency is different, i.e. On one device, in 1 second the clock value will increase by 1 second, and on another, for example, by 1.000001 second. This is where the clock divergence appears.
The standard describes an example of calculating the ratio of the time elapsed on the Master and on the Slave for a certain interval. This ratio will be the coefficient for the frequency of the Slave device. But there is an indication that adjustment can be carried out in various ways. Let's look at two of them:
- Change the clock frequency of the Slave device (example in the standard)
- Do not change the clock frequency, but for each tick of duration T the clock value will increase not by T, but by T+∆t (used in my implementation)
The second method requires calculation of ∆t. ∆t is a value that will be added to the time value every certain interval. In the figure you can see that while 22 – 15 = 7 seconds passed on the Master, 75+(87-75)/2 –(30+ (37-30)/2) = 47.5 passed on the Slave
Frequency – processor frequency, for example, 25 MHz - a processor cycle lasts 1/(25*10 6) = 40ns.
Depending on the capabilities of the device, the most suitable method is selected.
To move on to the next section, let's express offset a little differently:
PTP operating modes
Looking into the standard, you can find that there is not only one way to calculate delivery time. There are 2 operating modes of PTPv2. This E2E (End-to-End), it was discussed above, the mode is also described P2P (Peer-to-Peer). Let's figure out where to use which method and what is their difference.In principle, you can use any of the modes as desired, but they cannot be combined on the same network.
- In mode E2E delivery time is calculated from messages arriving through many devices, each of which enters the message correction field Sync or FollowUP(if two-stage transmission) the time for which the packet was delayed on this device (if the devices are connected directly, no correction is made, so we will not consider them in detail). Messages used: Sync/FollowUp, DelayReq/DelayResp
- In mode P2P In the correction field, not only the time for which the packet was delayed is entered, (t2-t1) is added to it (you can read it in the standard). Messages used Sync/FollowUp, PDelayReq/PDelayResp/PDelayRespFollowUp
End-to-End Mode
Peer-to-Peer mode
We see that some red arrows have appeared in P2P mode. These are the remaining messages that we have not addressed, namely PDelayReq, PDelayResp And PDelayFollowUp. Here is the exchange of these messages:
Delivery time error
The standard describes the implementation of the protocol in various types of networks. I was using an Ethernet network and receiving messages at the Ethernet level. In such networks, the packet delivery time is constantly changing (especially noticeable when you work with nanosecond precision). Various filters are used to filter these values.What needs to be filtered:
- Delivery time
- Bias
LP IIR (Infinite Impulse Response low-pass) filter(Infinite Impulse Response Filter) described by the formula:
, Where s– coefficient that allows you to adjust the filter cutoff.
Adjustment calculation
Let's move on to the adjustment, to the delta that will have to be added to the second value. The calculation scheme used in my system:
I used a Kalman filter to filter out the strong adjustment jitter due to network interference, I really liked it. In general, you can use any filter you like, as long as it smoothes the graph. IN PTPd, for example, filtering is simpler - the average of the current and previous values is calculated. On the graph you can see the results of the Kalman filter in my driver (the adjustment error is shown, expressed in subnanoseconds on a 25 MHz chip):
Let's move on to regulating the adjustment, the adjustment should tend to a constant, a PI controller is used. IN PTPd The clock offset is adjusted (the adjustment is based on the offset), but I use it to regulate the adjustment (a feature of the KSZ8463MLI). We see that the controller is not configured perfectly, but in my case this adjustment is sufficient:
Result of work
The result is shown in the graph. Clock offset ranges from -50ns to 50ns. Consequently, I achieved the accuracy that is mentioned in numerous articles. Of course, many small features of the implementation remained behind the scenes, but the required minimum was demonstrated.
65 nanometers is the next goal of the Zelenograd plant Angstrem-T, which will cost 300-350 million euros. The company has already submitted an application for a preferential loan for the modernization of production technologies to Vnesheconombank (VEB), Vedomosti reported this week with reference to the chairman of the board of directors of the plant, Leonid Reiman. Now Angstrem-T is preparing to launch a production line for microcircuits with a 90nm topology. Payments on the previous VEB loan, for which it was purchased, will begin in mid-2017.
Beijing crashes Wall Street
Key American indices marked the first days of the New Year with a record drop; billionaire George Soros has already warned that the world is facing a repeat of the 2008 crisis.
The first Russian consumer processor Baikal-T1, priced at $60, is being launched into mass production
The Baikal Electronics company promises to launch into industrial production the Russian Baikal-T1 processor costing about $60 at the beginning of 2016. The devices will be in demand if the government creates this demand, market participants say.
MTS and Ericsson will jointly develop and implement 5G in Russia
Mobile TeleSystems PJSC and Ericsson have entered into cooperation agreements in the development and implementation of 5G technology in Russia. In pilot projects, including during the 2018 World Cup, MTS intends to test the developments of the Swedish vendor. At the beginning of next year, the operator will begin a dialogue with the Ministry of Telecom and Mass Communications on the formation of technical requirements for the fifth generation of mobile communications.
Sergey Chemezov: Rostec is already one of the ten largest engineering corporations in the world
The head of Rostec, Sergei Chemezov, in an interview with RBC, answered pressing questions: about the Platon system, the problems and prospects of AVTOVAZ, the interests of the State Corporation in the pharmaceutical business, spoke about international cooperation in the context of sanctions pressure, import substitution, reorganization, development strategy and new opportunities in difficult times.
Rostec is “fencing itself” and encroaching on the laurels of Samsung and General Electric
The Supervisory Board of Rostec approved the “Development Strategy until 2025”. The main objectives are to increase the share of high-tech civilian products and catch up with General Electric and Samsung in key financial indicators.
07/09/2012, Mon, 10:07, Moscow time
The main problem with next-generation transport networks is that Ethernet technology was originally designed for local area networks and was never intended to carry synchronization signals. In recent decades, circuit-switched networks have been dominated by Synchronous Digital Hierarchy (SDH) technology as a transport medium, based on the transmission of clock signals. But even this reliable and proven technology does not meet the requirements of modern applications.
pages: previous | | 2
Using the Sync Ethernet standard
Ethernet technology was originally developed exclusively for use in local area networks. Methods for linear coding of information at the physical level were selected in accordance with tasks that did not involve transmitting a clock signal. SDH networks initially used NRZ line codes, which are adapted to transmit synchronization at the physical layer of the communication channel. When creating Sync Ethernet technology, the physical layer and coding methods were borrowed from SDH technology, and the second (channel) layer was practically not affected. The frame structure remains unchanged, with the exception of the SSM synchronization status byte. Its meanings were also borrowed from SDH technology.
The principle of synchronization transmission via the Sync Ethernet protocol
The advantages of Sync Ethernet technology include the use of the SDH physical layer structure, and along with this, vast and invaluable experience in designing and building clock network synchronization networks. The identity of the methods has kept the old recommendations G.803, G.804, G.811, G.812 and G.813 relevant in the new technology. Expensive devices - primary reference oscillators (PEGs), secondary master oscillators (MSOs) - can also be used in the new transport network built on the Sync Ethernet standard.
Typical synchronization scheme using Sync Ethernet technology
The disadvantages include the fact that in the entire transmission network, every device must support the new standard, and if there is a device on the line that does not support Sync Ethernet, then all the devices behind this node cannot operate in synchronous mode. Consequently, large material costs are required to modernize the entire network. Another disadvantage is that this method only supports the transmission of frequency synchronization.
Using PTP (IEEE1588v2)
And the last method of transferring synchronization, which has recently become increasingly popular, is the Precise Time Protocol (PTP). It is described in IEEE Recommendation 1588. In 2008, a second version of this document was released, which describes the use of the protocol in telecommunications networks. Precise Time Protocol is quite young, but the time transfer technology itself was borrowed from the Network Time Portocol (NTP) protocol. The NTP protocol in its latest version does not provide the precision required for modern applications, and therefore it remains a good tool for time synchronization, which is widely used in synchronizing servers, distributed databases, etc. But in building a clock network synchronization network, a logical continuation of the NTP protocol is suitable - this is the PTP protocol. The network elements that participate in interaction via the PTP protocol are the following devices: PTP Grand Master and PTP Slave. Typically, the Grand Master takes the timing from the GNSS receiver and, using this information, exchanges packets with the Slave device and constantly corrects time discrepancies between the Grand Master and Slave devices. The more active this exchange is, the higher the accuracy of the adjustment will be. The downside of such active exchange is the increase in bandwidth that is allocated to the PTP protocol. The most important problem in calculating the discrepancy in time intervals is that between the Grand Master and Slave devices there may be “classic” layer 3 routers. The term “classic” in this case is used to emphasize that these devices do not understand anything about the PTP layer 5 protocol.
Delays in the buffers of such routers are quite difficult to manage, and they are random in nature. In order to control these random errors, and also to make the calculation of the time discrepancy between the Grand Master and Slave more accurate, a special parameter was introduced in the PTP protocol - the Time Stamp. This label indicates the time it takes for a packet to pass through the router. If along the entire path from Grand Master to Slave routers have PTP functionality and set a timestamp, then the random error associated with the passage of PTP packets through the IP network can be minimized.
An example of building a synchronization network using the PTP protocol
Comparison of synchronization transfer methods in new generation packet networks
PTP functionality on routers is not required, but is highly recommended when using the PTP protocol. It should be noted that most router manufacturers include this functionality in their devices. An example of constructing a synchronization scheme for a mobile operator is shown in the figure below. The advantage of PTP is that the protocol is designed to transmit all three types of synchronization: frequency, phase and time. The main disadvantage of the protocol is its dependence on the load. When there are congestions on an IP network that are difficult to manage, it is very difficult to ensure strict compliance with the rules for transmitting synchronization across the network.
| Technology | Advantages | Flaws |
| GNSS | Providing frequency, phase and time synchronization. Does not depend on network load. |
Mandatory antenna installation. Impossibility of use in enclosed spaces. Possible interference from other radio devices. Redundancy is only provided by installing a second GNSS receiver |
| Sync Ethernet | Does not depend on network load. Similar to SDH network | Provides only frequency synchronization. Sync Ethernet support is required for all network elements |
| PTP | Providing frequency, phase and time synchronization. | Depends on network load. |
Each method has its own advantages and disadvantages, which are shown in the table. To determine the right approach, it is recommended to consider many criteria that are specific to different networks.
Mikhail Vekselman
pages: previous | | 2
In 2005, work began to amend the IEEE1588-2002 standard in order to expand the possible areas of its application (telecommunications, wireless communications, etc.). The result was a new edition of IEEE1588-2008, which has been available since March 2008 with the following new features:
- Advanced algorithms to ensure nanosecond accuracy.
- Improved time synchronization performance (more frequent transmission of Sync messages is possible).
- Support for new message types.
- Introducing a single-mode operating principle (no need to send FollowUp messages).
- Entering support for the so-called function transparent clocks to prevent the accumulation of measurement errors in a cascade connection scheme of switches.
- Enter profiles that define settings for new applications.
- Possibility of assignment to such transport mechanisms as DeviceNet, PROFInet and IEEE802.3/Ethernet (direct assignment).
- Introducing a TLV (type, length, value) structure to expand the possible scope of the standard and meet future needs.
- Introducing additional optional extensions to the standard.
The principle of operation of systems based on the PTP protocol
In systems that use the PTP protocol, there are two types of clocks: the master clock and the slave clock. The master clock is ideally controlled by either a radio clock or GPS receiver and synchronizes the slave clock. The clock in the end device, whether master or slave, is considered a regular clock; clocks included in network devices that perform the function of transmitting and routing data (for example, in Ethernet switches) are considered boundary clocks.
Rice. 1. According to the PTP protocol, time synchronization of devices is carried out based on the “master-slave” scheme.
The synchronization procedure according to the PTP protocol is divided into two stages. At the first stage, the time difference between the master and slave clocks is corrected - that is, the so-called time offset correction is carried out. To do this, the master device transmits a message for the purpose of synchronizing Sync time to the slave device (message type Sync). The message contains the current time of the master clock and is transmitted periodically at fixed time intervals.
However, since reading the master clock, processing the data, and transmitting it through the Ethernet controller takes some time, the information in the transmitted message is no longer relevant by the time it is received. At the same time, the moment in time at which the Sync message leaves the sender, which includes the master clock (TM1), is recorded as accurately as possible. The master device then transmits the recorded timing of the Sync message to the slave devices (FollowUp message). They also measure as accurately as possible the moment in time when the first message was received (TS1) and calculate the amount by which it is necessary to correct the difference in time between themselves and the master device, respectively (O) (see Fig. 1 and Fig. 2). Then the clock readings in the slave devices are directly corrected by the offset value. If there was no delay in the transmission of messages over the network, then we can say that the devices are synchronized in time.
Rice. 3. Calculation of message delay time in switches.
The delay in transmitting a message in both directions will be identical if the devices are connected to each other via one communication line and nothing more. If there are switches or routers in the network between devices, then there will not be a symmetrical delay in the transmission of messages between devices, since switches in the network store those data packets that pass through them, and a certain order of their transmission is implemented. This feature can, in some cases, significantly affect the delay in message transmission (significant differences in data transmission times are possible). When the information load on the network is low, this effect has little impact, but when the information load is high, this can significantly affect the accuracy of time synchronization. To eliminate large errors, a special method was proposed and the concept of boundary clocks was introduced, which are implemented as part of network switches. This boundary clock is time synchronized with the master clock. Further, the switch on each port is the master device for all slave devices connected to its ports, in which the corresponding clock synchronization is carried out. Thus, synchronization is always carried out according to a point-to-point scheme and is characterized by almost the same delay in message transmission in the forward and reverse directions, as well as the practically unchanged value of this delay from one message transmission to another.
Although the principle based on the use of boundary clocks has shown its practical effectiveness, another mechanism was defined in the second version of the PTPv2 protocol - the mechanism of using the so-called. transparent watch. This mechanism prevents the accumulation of errors caused by changes in the magnitude of delays in the transmission of synchronization messages by switches and prevents a decrease in synchronization accuracy in the case of a network with a large number of cascaded switches. When using this mechanism, the transmission of synchronization messages is carried out from the master to the slave, just like the transmission of any other message on the network. However, when the synchronization message passes through the switch, a delay in its transmission by the switch is recorded. The delay is recorded in a special correction field as part of the first Sync message or as part of the subsequent FollowUp message (see Fig. 2). When transmitting Delay Request and Delay Response messages, their delay time in the switch is also recorded. Thus, the implementation of support for the so-called. transparent clocks included in switches make it possible to compensate for delays that occur directly in them.
Implementation of the PTP protocol
If PTP is required on a system, a PTP protocol stack must be implemented. This can be done subject to minimum requirements for the performance of device processors and network bandwidth. This is very important for implementing the protocol stack in simple and cheap devices. The PTP protocol can be easily implemented even in systems built on cheap controllers (32 bits).
The only requirement that must be met to ensure high synchronization accuracy is that the devices measure as accurately as possible the moment in time at which the message is transmitted and the moment in time when the message is received. The measurement should be made as close to the hardware as possible (for example, directly in the driver) and with the highest possible accuracy. In software-only implementations, the architecture and performance of the system directly limits the maximum accuracy allowed.
By using additional hardware support for timestamping, accuracy can be greatly improved and can be made virtually independent of software. This requires the use of additional logic, which can be implemented in a programmable logic integrated circuit or an integrated circuit specialized for solving a specific task at the network input.
conclusions
The PTP protocol has already proven its effectiveness in many areas. You can be sure that it will become more widespread over the coming years and that many solutions using it can be implemented more simply and efficiently than using other technologies.
KYLAND equipment supporting IEEE 1588v2
technologies
S.Telegin
PTP protocol for synchronizing NGN networks
application issues
IN The article discusses the problem of synchronizing next generation data networks (NGN). IN
As an alternative method of synchronization transfer, the author suggests using the PTP protocol. The characteristics of synchronization systems based on the PTP protocol (IEEE 1588) are presented in comparison with systems using the PXI bus, as well as the NTP protocol.
Synchronization problem in NGN networks
The development of telecommunications technologies and data networks is gradually leading to the construction by telecom operators of converged networks of the next generation (NGN – Next Generation Networks). The main difference between such networks and traditional networks with a synchronous digital hierarchy (SDH) is that for backbone data transmission, along with conventional synchronous channels, they use asynchronous technologies such as Ethernet (Gigabit Ethernet, 10Gigabit Ethernet). The main requirement of telecom operators for next generation networks is the simultaneous transmission of voice, video and data over a single network.
When moving from traditional time multiplexing-based data networks to NGN networks, special attention is paid to the transmission of synchronization signals. Equipment synchronization is necessary primarily for error-free transmission of real-time data – voice and video images. Since Ethernet networks use packet switching, which, due to the statistical properties of the propagation of data packets over asynchronous transmission channels, destroys the initially synchronized data stream, synchronization transmission in NGN networks is a separate task. To transmit synchronous data over packet-switched networks, as a rule, channel emulation with time multiplexing is used, which consists of encapsulating synchronous data in UDP datagrams and their subsequent restoration at the destination node.
FIRST MILE 5–6/2009 |
|
For error-free recovery of transmitted data at the junction of asynchronous and synchronous channels, the equipment must also receive a clock signal. Requirements for clock signal stability vary depending on the specific purpose of the data network. Thus, in operator networks for the provision of telephony and Internet access services, the synchronization requirements are quite soft - 50 ppm (units per million), and in cellular networks, for seamless transition of mobile subscribers from one base station to another, a stability of 50 ppb (units per million) is required. billion).
Methods for synchronizing NGN networks
ITU-T Recommendation G.8261 discusses three main methods for restoring synchronization at the boundaries of a packet-switched transport environment when transmitting a time-multiplexed baseband signal in the form of a channel emulation service. To achieve this, the terminal station equipment must have internetworking capabilities. All subscribers of the packet switched transport environment can receive clock frequency from the synchronization network through the usual centralized distribution (Fig. 1). If the subscriber equipment operates at its own clock frequency (Fig. 2), then at the edge of the packet switching network it is restored in various relative ways, for example, using the SRTS rate matching algorithm. In both cases, the gateway node must have access to the interface with the primary synchronization generator.
technologies
tions (PRC). To do this, the NGN network operator must either build a separate synchronization network or lease it from existing SDH transport network operators.
There are many examples of local hardware synchronization. For example, an inexpensive GPS-based primary synchronization source (PRS) is placed in the station room and the clock frequency is distributed from it using wireless technologies or over conventional dedicated cables, in the Ethernet physical environment, as well as using other original circuits. If building a synchronization network (or using synchronization joints) is impossible or undesirable, then the simplest, but problematic for stability reasons, adaptive method of matching reception and transmission speeds is used (Fig. 3).
The results of the research show that the adaptive method can be used if the subscriber does not have strict requirements for the stability of its clock frequency, otherwise additional hardware smoothing of the recovered clock signal is necessary. An alternative to the adaptive method is the use of the RTP protocol when encapsulating data with time multiplexing into asynchronous data packets (Fig. 4). As experiments have shown, in this case, with high stability of the restored clock signal, the equipment turns out to be weakly sensitive to changes in the frequency at the synchronization source, which is necessary, for example, in cellular networks when switching to a backup clock signal.
PTP protocol
The next stage of development, apparently, will be a separate transmission of network synchronization signals with packet switching
using specially developed protocols (Fig. 5). At the moment, these are the NTP and PTP protocols. These protocols were originally created to synchronize time across different devices on a network, but if clock synchronization is successful, it is also possible to implement clock synchronization algorithms to recover real-time data. NTP (Network Time Protocol) is widely used to synchronize the current time at the application level. In contrast, the Precision Time Protocol (PTP) operates at the second layer of the Open Systems Interconnection (OSI) model. The RTP protocol is described in the IEEE 1588 standard. It is expected that in the future RTP can be used both for high-precision synchronization of the current time and for clock synchronization of equipment. Let's look at this protocol in more detail.
The IEEE 1588 standard assumes that the PTP protocol provides a standard method for synchronizing devices on a network with an accuracy of better than 1 µs (up to 10 ns). This protocol ensures that slave devices are synchronized from the master by ensuring that events and timestamps on all devices use the same time base. The protocol provides two stages for synchronizing devices: determining
Rice. 3 Adaptive Sync
Fig.4 |
Transferring synchronization using RTP |
Fig.5 |
Transferring synchronization using PTP |
FIRST MILE 5–6/2009 |
|
Rice. 6 PTP operation algorithm
control of the master device (1) and correction of the time difference caused by the clock offset in each device and delays in data transmission over the network (2). During system initialization, PTP uses a "best master clock" algorithm to determine the most accurate clock source on the network. Such a device becomes the master, and all other devices on the network become slaves and adjust their clocks to the master device.
The time difference between the master and slave devices is a combination of the clock offset and the delay in transmitting the synchronization message. Therefore, time offset correction must be performed in two steps: calculating the transmission and offset delays, and then correcting them. Let's consider the sequence of synchronizing the clocks of two devices (Fig. 6).
The master begins to correct the clock offset using Sync and Follow-up messages. The Follow-up message specifies the time at which the Sync message (TM1) was sent, measured closest to the transmission medium to minimize error in the timing of the reference source. After the slave device receives the first Sync and Follow-up messages, it uses its clock to stamp the time of arrival of the Sync message (TS1) and compares this time stamp with that received from the master device in the Follow-up message. The difference between these two marks reflects the clock offset T0 plus the message transmission delay from the master to the slave ∆TMS: TS1 – TM1 = T0 + ∆TMS.
To calculate the message delay time and clock offset, the slave device sends a Delay_request message with its TS2 time. The master notes the arrival of this message and responds with a Delay_response message with a TM2 tag. The difference between the two marks is the transmission delay from the slave to the master ∆TSM minus the offset in the slave's sample: TM2 – TS2 = ∆TSM – T0 .
When calculating the message transmission delay, it is assumed that the average data transmission delay in the channel is
on the arithmetic average of propagation delays in different directions of the channel:
TMS + TSM |
|||
Knowing the times TS1, TM1, TM2 and TS2, the slave device calculates the average propagation delay in the data channel:
T = (TS1 − TM1) + (TM2 − TS2). 2
The final clock synchronization occurs after the master sends the second set of Sync (TS3) and Follow-up (TM3) messages. The slave device calculates its clock offset using the formula T0 = TS3 – TM3 – ∆T.
The slave then adjusts its clock according to the calculated values. Because the clock references in each device are unstable and channel delays can vary over time, it is necessary to periodically adjust the slave device's clock.
Features of the PTP protocol implementation
Most PTP implementations have a deviation of less than 1µs, but actual performance varies depending on the application. The PTP protocol in devices is implemented in three ways: software, firmware and hardware. RTP software implementations make it possible to transmit synchronization signals with an accuracy of about 100 μs. To achieve higher accuracy, hardware must be used. Each component that processes a PTP packet after it has been received from the physical media increases the synchronization error. The software side introduces the most error because CPU load and interrupt processing latency affect the speed at which the synchronization request is processed.
When implemented in hardware and software, the most sensitive functions of the protocol, such as recording the timestamp of a PTP packet, are implemented at the Ethernet physical layer, for example, in a separate programmable logic chip. Such methods are the most optimal today, since they do not require too many resources and time to develop the device, allowing an accuracy of about 20 ns to be achieved. In the case of a complete hardware implementation of the PTP protocol, an accuracy of about 10 ns is achievable.
In addition to the implementation method, a number of other factors influence the accuracy of the RTP protocol. For example, the IEEE 1588 standard does not specify the clock frequency between master and slave devices. As a result, lower frequency clocks will have less precise timing resolution, resulting in less accurate timestamps in the clock messages. The stability of the reference oscillator frequency also affects the quality of the protocol implementation. Synchronizing signals obtained using thermostated and temperature-compensated quartz oscillators will be more stable (from
FIRST MILE 5–6/2009 |
|
technologies |
||||||
deviation in parts per billion) than crystal oscillators |
the best alternative for synchronizing distributed systems |
|||||
without thermal stabilization (deviation in parts per million). |
those with submicrosecond accuracy. |
|||||
The quality of device synchronization is also affected by topology |
Thus, PTP is an alternative |
|||||
network logic and traffic uniformity. In a network with a large number |
network synchronization method, which can be dis- |
|||||
broken devices and high load on data transmission channels |
distribution in NGN networks. Compared to those used in |
|||||
the accuracy of the synchronization broadcast will be worse. Therefore for |
currently means of synchronization, this method |
|||||
transmission of synchronization signals is preferably used |
has a number of advantages: |
|||||
create a separate data network. |
The equipment does not require direct access to the synchronization interface |
|||||
PRC implementation, which will allow operators to optimize |
||||||
Comparative characteristics |
expenses for building a network. In this case, the RTP protocol can provide |
|||||
synchronization systems |
print synchronization transfer with submicrosecond accuracy |
|||||
Let us consider the characteristics of synchronization systems using |
tew, which means stability better than 1 ppm is achievable; |
|||||
using the PTP protocol, in comparison with systems with synchronization |
Unlike the adaptive method, to restore synchronization |
|||||
via PXI bus (physical synchronization line) and via protocol |
Ronization requires a highly stable reference oscillator |
|||||
lu NTP (see table). Unlike systems with a physical line |
only in the master device; |
|||||
synchronization, where the accuracy of events is determined by the accuracy |
For synchronization tasks, you can use asynchronous |
|||||
clock signal, in the PTP protocol the determining factor is |
channel with a relatively small throughput capacity |
|||||
there is phase jitter (jitter) associated with random changes |
ity, which significantly reduces the cost of implementation. |
|||||
reduction of inter-packet intervals. Most implementations of the prototype |
It is preferable for this channel to be dedicated. |
|||||
Cola PTP provides an accuracy of less than 1 µs. |
Considering the ease of network deployment |
|||||
Another important value that distinguishes different methods |
Ethernet, sub-microsecond accuracy and performance |
|||||
synchronization, is the waiting time for the synchronization event |
with minimal costs for processing messages, proto- |
|||||
Tia. This is the time between sending an event to the master device. |
PTP count is increasingly used in many industries, especially |
|||||
yours and getting him to follow. Since PTP and |
in industrial automation, metrology, etc. Waiting- |
|||||
NTP for transmission of synchronization messages uses |
Xia that in the future the capabilities of the PTP protocol will expand it |
|||||
there are data packets, the wait for an event is determined by time |
application in telecommunications for synchronization of devices |
|||||
packet wait plus header transmission and processing time |
swarms over packet switching networks. |
|||||
packet and is usually a few milliseconds. IN |
||||||
the difference from them is systems with a physical synchronization line |
Literature |
|||||
wait for a synchronization event for several |
1. Stein Y., Schwartz E. Circuit Extension over IP: The |
|||||
nanoseconds Waiting time for synchronizing event op- |
Evolutionary Approach to Transporting Voice and Legacy |
|||||
defines such a characteristic as the maximum possible |
Data over IP Networks. – RAD Data Communications, 2002. |
|||||
frequency adjustment of the clock signal. |
2. ITU-T G.8261/Y.1361 Timing and synchronization |
|||||
Synchronization systems with a single synchronization bus, |
aspects in packet networks. – ITU_T, April 2008. |
|||||
such as PXI are ideal for high-precision and high-speed |
3. Rodrigues S. Technology options for sync delivery in |
|||||
full synchronization restoration and can be extended |
Next Generation Networks. – 3rd International Telecom |
|||||
renes over distances of up to hundreds of meters using special |
||||||
synchronization modules placed in cassettes. Standard- |
4. Telegin S.A. Application of TDMoIP multiplexing |
|||||
synchronization via Ethernet network using NTP |
rirovaniya for data transmission in transport networks |
|||||
sets millisecond synchronization suitable for |
GSM. – Nonlinear world, 2007, vol. 5, no. 5, p. 270–271. |
|||||
low-speed applications that are not very quality critical |
5. IEEE Std. 1588–2008 IEEE Standard for a Precision |
|||||
synchronization The PTP protocol is a good |
Clock Synchronization Protocol for Networked |
|||||
Comparative characteristics of synchronization systems |
Measurement and Control Systems. – IEEE, July 2008. |
|||||
6. IETF RFC1305 Network Time Protocol (Version 3). |
||||||
Synchronizing |
Protocol |
Protocol |
||||
Specification, Implementation and Analysis. – IETF, |
||||||
modules on PXI buses |
||||||
Temporary |
||||||
<1·107 |
7. Tan E. IEEE 1588 Precision Time Protocol Time |
|||||
permission |
||||||
events, ns |
Synchronization Performance. Application Note 1728.– |
|||||
National Semiconductor, October 2007. |
||||||
expectations |
||||||
8. Hamdi M. Neagoe T. A Hardware IEEE-1588 |
||||||
Implementation with Processor Frequency Control. – |
||||||
adjustments |
Arrow Electronics, August 2006. |
|||||
FIRST MILE 5–6/2009 |
|
