Time Synchronization Errors Caused by Network Asymmetries
The accuracy that can be achieved by time synchronization protocols like NTP or PTP is not affected by the absolute propagation delay of the network packets. The packet delays can be measured and compensated as long as the delay is constant, i.e. it doesn't vary over time, and the delay is the same for packets that are sent and received.
So generally, time synchronization (or monitoring of the time synchronization accuracy) across a network can be more or less accurate, depending on the network characteristics.
The example below shows how an asymmetric network affects the resulting accuracy.
The first image below shows a small network on the left side which contains a GPS controlled NTP server, and two PCs as NTP clients. All devices are internally connected via router/switch 1 with usual LAN connections.
The router also connects the small LAN to the internet via a usual ADSL line that provides a high download speed (from the internet to the LAN), but only a limited upload speed (from the LAN to the internet), so all packets from the internet to the LAN are propagated much faster than the packets from the LAN to the internet. This is called asymmetric packet delay.
On the right side there's a monitoring system which is also disciplined by a GPS receiver, and is connected to the internet via router/switch 2 which has a symmetric connection providing the same data rates for upload and download. Thus, the packet delays for outgoing and incoming packets are in the same range at this side.
Within the LAN on the left there is no delay asymmetry between the individual devices, so the client PCs can synchronize very precisely with the NTP server, and since the NTP server is controlled by GPS, the time on all yellow devices on the left side can be adjusted very accurately.
Also the monitoring system on the right side is controlled by GPS, so the monitoring system also has a very accurate time. However, when it sends a request packet to the NTP server on the left side then each request (blue line) arrives at the LAN at full speed via the fast ADSL download path, while each response towards the internet and the monitoring system (green line) is propagated slower on the slow ADSL upload path (red line).
As a consequence, for the monitoring system it looks like the time provided by the NTP server on the local LAN is off by a significant offset, even though in reality this isn't the case. The range of the imaginary time offset depends on the ratio of the upload and download speed of the ADSL path which connects the left LAN to the internet.
For example, if the imaginary time offset caused by the network asymmetry was about 5 milliseconds, the monitoring system would report that the NTP server on the local LAN was wrong by 5 ms, even if in reality this is not the case because of the GPS Control the time on the local LAN is very precise. Only the network path used for monitoring causes an imaginary error.
The second image below shows basically the same situation as above, but now the NTP server on the LAN gets its time from a public NTP server on the internet instead of a local GPS receiver.
The network asymmetry, which only affected the monitoring system in the first example, now also affects the time on the local NTP server.
The ADSL network path is the same, therefore the ratio of upload and download speeds is the same and thus the resulting imaginary time offset is the same in both cases.
However, while from the monitoring system's point of view each request packet is fast and each reply packet is slow, this is exactly the opposite for the NTP server on the local LAN when it queries the public NTP server: each request packet is slow, and each reply packet is fast. As a result, the size of the imaginary time offset is the same, but it has just the opposite sign.
For example, if the asymmetry of the ADSL network causes an offset of 5 ms, the time on the local NTP server may incorrectly differ from that of the public NTP server by +5 ms.
Unfortunately, the local NTP server is unable to detect this systematic timing error caused by network asymmetry. If the offset could be detected, it could easily be compensated for. However, detection is only possible if another accurate time source is available, e.g. a GPS receiver. For the monitoring system, the imaginary offset is exactly the opposite, so it would be -5 ms, and from the monitoring system's perspective, the +5 ms and -5 ms offsets cancel each other out.
So in this case the monitoring system would erroneously report a time offset close to 0 for the local NTP server, even though in reality the NTP server's time is off by 5 ms.
A Possible Solution
A possible solution would be to be able to specify a time compensation value associated with an IP address range. For example:
- If the source IP of an incoming NTP packet is not on your local subnet, apply a specific asymmetry compensation.
- If the destination address of an outgoing NTP packet is not on your local subnet, apply the same specific asymmetry compensation, but with inverse sign.
- If the packet comes from or goes to your local subnet, don't apply any asymmetry compensation.
To our knowledge, such a configuration option has never been implemented, even though this was already proposed back in 2014:
— Martin Burnicki martin.burnicki@meinberg.de, last updated 2024-01-31
127.0.0.1