Domain Time II Configuration - Server/IEEE 1588-2008 (PTPv2)

IEEE 1588-2008 (PTPv2)

Domain Time II Server
Version 5.2

Domain Time II Precision Time Protocol Support

PTPv2 Precision

A PTPv2 network of hardware clocks on a well-regulated segment can usually synchronize to within a few tens or hundreds of nanoseconds. Software implementations can theoretically achieve the same results, but are subject to limitations of the host operating system. In particular, Windows, Linux, and BSD are not real-time operating systems, and the connecting networks are often congested or have unpredictable or asymmetric performance characteristics. PTPv2 implementations in these environments must estimate delays caused by servicing interrupts, stack traversal, latencies introduced by expiring time slice quanta, and vagaries in the network itself.

By default, when an application tells the operating system to place a packet on the wire, it can know only when the packet left the application, not when the packet finished traversing the operating system layers and was actually placed on the wire. Likewise, incoming packets may suffer delays in the network driver or the operating system before being delivered to the application. This degree of uncertainty produces “jitter,” or small variations in the measured time that are artifacts of the environment rather than the protocol. In addition, any procedure can be preempted, leading to erroneous measurements of elapsed time.

Some operating systems, with assistance from the network driver, can provide a timestamp indicating when a particular packet left or entered the system. Using this information, the application can determine how much extra time was spent handling the packet between the application and the wire. The BSD-style socket options SO_TIMESTAMP or SO_TIMESTAMPNS are used to enable this functionality on BSD or Linux. If the operating system and network driver support SO_TIMESTAMP or SO_TIMESTAMPNS, the measurements of PTPv2 can be significantly more precise than without such support.

Current Windows operating systems do not support SO_TIMESTAMP or SO_TIMESTAMPNS. When Windows adds this support, and when NIC manufacturers add support in their Windows drivers, any application designed to take advantage of the extra information will benefit.

The theoretical limit of precision for Domain Time II using any protocol is the hectonanosecond. A hectonanosecond is 100 nanoseconds, or 1/10th of a microsecond. The real-world behavior of Domain Time II’s implementation of PTPv2 achieves results as good or better than any other supported protocol, and has the potential for even better results when operating system and NIC support become available.

The presence of PTPv2 on a network gives Domain Time II the opportunity to adjust the timing of the system up to 64 times per second. This is not possible with conventional request-response time protocols because the overhead of making requests are prohibitive. With PTPv2 in an optimum environment using continuously variable phase/interphase adjustments, Domain Time II can achieve synchronization within 50 microseconds or better.

Introduction

Domain Time II supports Precision Time Protocol version 2 (PTPv2, IEEE 1588-2008). PTPv2 is designed to be mostly configuration-free. Master clocks on the local segment exchange periodic messages with Domain Time II in order to determine the current time offset.

Domain Time II normally runs in slave-only mode, with PTPv2 providing time samples which Domain Time II uses to manage the machine’s clock. This applies to both Domain Time II Client and Domain Time II Server, each of which requires a reliable time source.
Domain Time II Server allows you to let Domain Time II assume the master clock role. This option should only be enabled if you have no hardware-based PTPv2 grandmaster, or if you need a software-based backup to your grandmaster. PTPv2 is designed to work with hardware-based clocks. Software-based clocks cannot offer the same degree of precision or accuracy as hardware-based clocks.
Domain Time II automatically detects and synchronizes to the best master on the local segment.
PTPv2 has two delay-measurement mechanisms, End-to-End and Peer-to-Peer. Most master clocks can support either, but only one at a time. Domain Time II auto-detects the delay mechanism and uses whichever one the master supports.
When PTPv2 is enabled on Domain Time II, it runs continuously in the background, exchanging messages with the master and collecting statistics. You can see this activity using the Domain Time II control panel applet. At its next regularly scheduled timecheck, Domain Time II coalesces the filtered results of PTPv2’s statistics as a single time sample. You may choose to use the samples without coalescing them, in which case they are filtered along with whatever time sources you have configured.
PTPv2 is a “chatty” protocol. The master clock sends messages on a regular basis. The default frequency is one per second, but most master clocks allow this number to be adjusted, and most administrators choose a higher number. In general, the higher the rate of messages, the more accurately the slave can measure the master’s information but at the cost of increased network traffic.
A standard-compliant PTPv2 node operates using only multicast messages. This means that not only does every node see the master’s messages, but every node sees every request made by every slave, and every reply. Domain Time II tries to reduce this traffic by sending unicast delay requests. If the master clock supports unicast replies, Domain Time II will continue using only unicast with that clock. If the master does not support unicast for delay requests, Domain Time II will fall back to using multicast.
PTPv1 is not supported. PTPv1 and PTPv2 are incompatible. A boundary clock is required to separate v1 and v2 segments. Domain Time II will not recognize or respond to PTPv1 messages.
Domain Time II does not support the experimental PTPv2 authentication mechanisms.

Optimum Environment for PTPv2

The hardware, software, and network environment is critical for PTPv2 synchronization at the sub-millisecond level. This section will help customers hoping to achieve sub-millisecond synchronization across your network of machines:

CPU
The best processors for time synchronization are Intel’s Core i7 line (or later). Earlier chips, even Xeons or other high-powered processors, are not as stable or as precise as the newer chips. The Core i7 line also has an invariant timestamp counter, which allows Domain Time II to measure the passage of time accurately regardless of SpeedStep or other power-saving mechanisms. DTCHECK /cpuid will show you whether or not your processor supports an invariant TSC.
Operating System
In general, XP and 2003 are more predictable than Vista, Windows 7, or Windows 2008. Using PTPv2 with continuously variable phase/interphase, the performance is nearly identical, but with other time protocols, XP and 2003 will outperform the newer operating systems on the same hardware.
Network Switches
The lower the latency in your network switches or hubs, the better. Switches use a store-and-forward technology, which means that packets can be delayed even under ideal circumstances. During times of high traffic, the delay time can quickly soar to unacceptable levels. Even a small delay will affect timing, even though other applications may not even notice it. If you have managed switches, examine the statistics to determine if packets are being delayed. You may also set up a test environment and compare the synchronization accuracy in your test environment vs. your production environment. If the performance suffers in your production environment with identical equipment, suspect underpowered switches.
Other Applications
Most user-mode applications do not affect timing significantly. However, programs that change the system clock resolution, or that overtax the hardware, can degrade performance. If possible, avoid Java-based applications, Flash applications, or any program that exercises the CPU excessively.
Miscellaneous Hardware and Drivers
Drivers for NICs, video, and disk subsystems can cause unpredictable delays in servicing interrupts. Windows timing relies on the regularity and predictability of interrupts. If sub-millisecond timing is critical for your environment, use only the best and fastest hardware.
Virtualization
Any machine running either Hyper-V or VMWare will not perform as well as a stand-alone machine. This applies to both the host operating system and any guests, using any time synchronization protocol. PTPv2 may not help much, if at all, in taming the vagaries of virtualized systems. In fact, the extra overhead of handling the continual PTPv2 network activity may actually result in more interrupt delays among guests, resulting in additional clock drift.
Do not expect sub-millisecond accuracy on any guest operating system. It is realistic to expect your guest’s clocks to remain within 1-25 milliseconds of the true time on average, but there will be spikes and irregularities. A Hyper-V host may actually perform worse than its guests, due to the nature of task prioritization and interrupt handling of the hypervisor.

PTPv2 Configuration Recommendations

Use Hardware Clocks
PTPv2 works best with hardware-based grandmaster clocks. Although you may design a network using only software components, your accuracy will suffer. We recommend careful planning to ensure you have hardware clocks available, and that their capacity is commensurate with your expected load. Your grandmaster manufacturer can help you plan your network.
Specify Fallback Servers
PTPv2 does not start immediately. It must listen to the network to detect the master clock, and must then synchronize to it before providing time samples to the main Domain Time II clock management algorithms. This means that for a brief period after startup, Domain Time II will not be able to use PTPv2 as a time source.
We recommend that you check the box to enable PTPv2, and then also specify a list of alternate servers (either NTP or DT2) to use as fallbacks. This way, when PTPv2 hasn’t synchronized yet or when it fails because the master clock goes offline, Domain Time II will have another source for time.
You may also choose to enable Domain Time II’s statistical filters by checking the “Analyze time samples and choose the best, or average equally good samples” checkbox. When you enable this option, Domain Time II will compare the time samples from PTPv2 with the time samples from your list of NTP or DT2 servers, and determine the best approximation of the true time. Without analysis enabled, you are at the mercy of a single clock that may be either misconfigured or inconsistent in its behavior.

Configurable Options for PTPv2 in Domain Time II

While PTPv2 is designed to operate on the local segment without any configuration by the administrator, Domain Time II nevertheless exposes a few options for customization.

Enable/Disable
PTPv2 must be enabled as a timesource on Domain Time II before it can be used for synchronizing the clock.
Delay Mechanism
The default operation of Domain Time II is to detect the delay mechanism used by the master clock. The options are:
1. Auto-detect
2. Peer-to-Peer (Default Profile 00-1B-19-00-02-00)
3. End-To-End (Default Profile 00-1B-19-00-01-00)
4. Delay mechanism disabled
Unicast Support
The default operation of Domain Time II is to test the master clock for unicast support and use unicast if possible. The options are:
1. Auto-detect (default)
2. Always use unicast
3. Never use unicast (default profile-compliant)
IPv6 Scope
The default operation of Domain Time II’s support for PTPv2 over IPv6 is to listen and send on the site-local scope. You may override this to specify link-local scope instead.
PTPv2 Domain

Networks of clocks using PTPv2 are separated into logical “domains,” or groups of clocks. Nodes will only respond to messages sent to their domain. The domain is specified by a number, and the default domain is 0 (zero). Any number between 0 and 127 inclusive is a valid domain number. If you change this setting on your master clock, you must change each Domain Time II machine to match.
Specifying Master Clocks
Domain Time II is a software-based implementation of PTPv2. The default operation according to the standard is for Domain Time II to discover and synchronize with the best master clock available on the local segment. If that clock goes offline and another clock assumes the master role, or if another clock claims to be more authoritative, Domain Time II will begin synchronizing to the new master automatically. The standard behavior is sometimes undesirable. A user could bring up a new master clock on the network that, either by intention or mistake, assumes the master role without providing better time.
Domain Time II optionally allows you to override the automatic selection of master clock by specifying the IP address(es) of the master(s) to which you are willing to synchronize. When you override the automatic selection of master clock, Domain Time II only pays attention to the IP addresses you specify; messages from other IP addresses are silently discarded.
Note: Because PTPv2 nodes automatically choose a master according to the algorithm specified in the standard, specifying a list of machines for synchronization may result in no server being available because the other nodes may elect a master that you have chosen to ignore. Use this option with caution.

PTP Default Profiles

IEEE 1588-2008 Annex J specifies two default profiles, or operating constraints, for use with PTPv2. The profile identities are 00-1B-19-00-01-00 (the default End-to-End profile), and 00-1B-19-00-02-00 (the default Peer-to-Peer profile). Please refer to IEEE 1588-2008 for the exact specifications.

The profiles are identical except for the method of delay measurement specified. Domain Time II uses all the default values as specified in the profiles, and meets or exceeds the minimum requirements for each profile. Nevertheless, Domain Time deviates from the standard in a few particulars:

Both default profiles assume PTPv2 components will either use only multicasts for exchanging messages, or will negotiate unicast transmission on a case-by-case basis using the management mechanism described in Table 34 of the standard (REQUEST_UNICAST_TRANSMISSION).
Domain Time II does not negotiate unicast transmission using REQUEST_UNICAST_TRANSMISSION. The management mechanism of the standard is awkward, liable to error, does not scale well, and requires renegotiation for each slave with each master for each type of message.
Despite not supporting REQUEST_UNICAST_TRANSMISSION, Domain Time II does offer the use of unicast messages for delay measurement. By default, Domain Time II will test each newly-selected master clock by sending it both unicast and multicast delay request messages. If the master responds to the unicast request by sending a unicast reply, Domain Time II will continue using unicast with that server.
In order to be standard-compliant, Domain Time II offers the ability to choose one of the two default profiles. Additionally, Domain Time II offers the ability to automatically detect the proper profile to use, or to disable delay measurement entirely. Automatic detection is the default configuration. This means that each slave does not need to be preconfigured to match the hardware grandmaster (which typically can support both delay mechanisms, but only one at a time).
Delay request frequency (the interval at which each slave is supposed to measure the delay using one of the two delay mechanisms) is normally controlled by the master clock when using End-to-End delay. The interval is sent as part of the master’s regular packets. Peer-to-Peer delay, however, uses the master’s announce frequency times an implementation-dependent multiplier to derive the delay request frequency.
Domain Time II allows you to override this automatic request frequency and specify a fixed interval.
Domain Time II uses the standard-specified Best Master Clock (bmc) algorithm to choose the best available clock. By default, Domain Time II operates in slave-only mode, so only another clock on the network can become the master.
If you allow Domain Time II Server to function as a master clock on your network, you may specify the amount of time Domain Time II should wait before deciding that no better clock is available. The default settings for Domain Time II ensure that it will not assume the master role while any hardware-based grandmaster is operating on the network.

Proceed to the Timings page

Back to the Obtain the Time page