When measuring one-way delay, clock synchronization between the measurement points is essential. Here you find some basic information on synchronizing clocks and finding the best solution for your needs.
Qosium relies on the system clock in a measurement point in most cases. For measuring one-way delay, this means that the clocks on the measurement points need to be synchronized for good results. Synchronization errors show up in the results. For example, with two-way data, the other direction’s delay can be negative, and the delay to another direction displays high positive delays. Synchronization error can be detected as mirrored delay behavior between the send and received directions.
Below you find the most common synchronization methods with some typical accuracy levels. For more information on different synchronization methods, please reach out to Kaitotek.
Network Time Protocol (NTP) is the most common way to synchronize clocks over a network connection. It’s supported practically by all computers with a network interface. NTP allows you to reach a few milliseconds accuracy at its best, but you need to be prepared to experience an inaccuracy of about 10 ms. Thus, NTP does not suit use cases well where you need to get very accurate delay results.
Essential with NTP synchronization is that you configure NTP to poll time frequently enough. For example, the NTP client (w32time) on Windows defaults to a configuration that polls time from a server rarely after the NTP client had determined it has reached a synchronization. Qosium installer for Windows helps you reconfigure this so that the clock is requested from the NTP server at a maximum of every 16 seconds despite the client’s state. Overall, it is suggested to use maximum polling intervals between 8-30 seconds.
As NTP, Precision Time Protocol (PTP) is a synchronization protocol to be used over a network. PTP is designed for local networks where the network devices need to be synchronized with high accuracy. For example, mobile networks rely on PTP.
PTP allows you to reach tens-to-hundreds microsecond accuracy. The better is the accuracy, the more stable is the network connection. For example, the synchronization accuracy is better in wired networks than over a wireless connection. However, reaching an accuracy level of hundreds of microseconds over a wireless connection is possible by tuning the PTP client settings not to adjust the clock too sensitively.
In addition to the stability of network connection and the configuration of a PTP client, timestamp methods supported by the operating system and the host hardware affect the obtainable accuracy. Timestamp methods come with tradeoffs, for example, between granularity, accuracy, precision, and efficiency.
There are a few open-source PTP implementations available for Linux. Some of them require, for example, hardware timestamping support from the network interface, but some of them work on basically all Linux-based systems with software timestamping. An example of a versatile open-source PTP implementation is PTPd. On Windows, w32time is also possible to be utilized as a PTP client.
Good absolute timing accuracy, about tens of microseconds, can be reached with GNSSGlobal Navigation Satellite System
A general term under which all the different global satellite navigation systems (e.g., GPS, GLONASS, Galileo, BDS) fall.. The key is a GNSS receiver with a PPS (Pulse Per Second) capability. A pulse is sent once a second, starting at the beginning of every new second. Another important aspect is to feed the host machine with the pulse signal. Old-good RS242 serial line communications provide high accuracy while, for example, USB loses the accuracy.
On Linux, the actual time synchronization is then carried out with NTP locally. On Windows, you need a separate driver for managing PPS signal with performance counters.
Global Navigation Satellite System
A general term under which all the different global satellite navigation systems (e.g., GPS, GLONASS, Galileo, BDS) fall.