Precision Time Protocol (PTP) is a relatively new protocol that was developed to improve the time synchronization accuracy that is obtainable over a Local Area Network (LAN). Specifications for PTP are defined in the IEEE-1588 standard. In PTP terminology, the Grandmaster is the distributor of accurate time and the Slave is the receiver of this time. The Slave synchronizes itself to the Grandmaster.
The most common network timekeeping protocol is the Network Time Protocol (NTP). In NTP terminology, the Server is the distributor of accurate time and the Client is the receiver of this time. The Client synchronizes itself to the Server.
With NTP you can get client synchronization accuracies in the millisecond range. With PTP you can get slave synchronization accuracies in the nanosecond or microsecond range. Synchronization accuracy depends not just on the PTP Grandmaster, but also on the network topology such as switch and slave hardware.
Products listed below can be configured as a IEEE-1588/PTP Grandmaster Clock. Here are the timestamp resolution and accuracy specifications:
|Model||Timestamp Resolution||Timestamp Accuracy to UTC (RMS)|
Network Time Server
|8 nanoseconds||30 nanoseconds|
Network Time Server
|8 nanoseconds||10 microseconds (typical)|
|8 nanoseconds||10 nanoseconds|
|8 nanoseconds||25 nanoseconds|
The Grandmaster user interface allows you to modify the TTL Value (time-to-live value) in order to accomplish this. You will also need to modify the TTL Value on your PTP Slave.
The main difference is in the synchronization accuracy that can be achieved. With software timestamping as typically implemented (software-only approach), you can see slave synchronization accuracies between 10 and 100 microseconds. You can achieve this level of accuracy with commonly used network hardware such as standard switches, and computers with software PTP slaves.
With hardware timestamping as implemented on a Sonoma it is possible to achieve time synchronization accuracies of 30 nanoseconds with an 8 nanosecond resolution. However, in order to get this level of accuracy, both the Grandmaster and the Slave must be capable of hardware timestamping. This means you will need to purchase specialized hardware to install in each Slave. In addition, network switches must configured as transparent clocks or boundary clocks.
PTP Version 2 has been designed to span over a WAN. However, performance is dependent on the network configuration. For example, a network switch would need to be configured as a transparent clock or boundary clock in order to realize the superior synchronization capability. Otherwise, synchronization of PTP becomes equivalent to NTP.
Yes. All Sonoma, Meridian, Tycho II, Tempus LX, and Unison Time Servers are capable of operating PTP. PTP is a relatively low-cost option that can be installed by you at any time. All that is needed from you is the Ethernet address (MAC) and we can supply a software key and instructions for turning on PTP. For older products, you may need to upgrade your software first.
The Precision Time Protocol (PTP) is a relatively new protocol (compared with NTP). As such, there are fewer options available for you to use for PTP Slave software. The options that do exist range from software-only solutions to software with hardware timestamping solutions. For further information click here.
Over 2000. But it depends on various settings and configurations that can increase or decrease the number of slaves that Sonoma can support. Consider the following:
1. If using a Boundary Clock, the Sonoma only interfaces with the network switch Boundary Clock. In this case the capacity is limited by the Boundary Clock switch.
2. When using a Transparent Clock, the capacity is limited by the frequency of the delay requests and the sync rate. Sonoma will be able to provide all the slaves with the Sync Packets and Announce Packets. But, there will be a limit for processing delay requests issued by the slaves. Our implementation requires about 10 microseconds to handle a delay request / response. The delay request is used to calculate the slave-to-master delay. If your network is static the delay should not change and the Sonoma will announce to the slave to use 32-second delay request interval.
Even though the slaves randomize the delay request packets, the request can come in simultaneously. What happens if delay requests show up simultaneously? In this case, the Sonoma will not issue a delay response. The slave will then randomize the delay request interval and issue the request again. Some slaves will log a notification that a delay response was not received.