NTP round-trip delay
We all know, that the delay between the NTP server and a NTP client has important influence for the precision of the time. There are a lot of information in the Internet which I did already know, but I was surprised how dramatically this could be.
Since I run my own rubidium disciplined NTP server since this summer I try to adjust my stratum-1 server very accurate. Beside the rubidium NTP server I have also a GPS based and a DCF77 based time source as reference. To adjust these servers I need a reference from the Internet. Located near Vienna in Austria I took stratum-1 server with low RTT. My decision was to take the server from Bundesamt für Eich- und Vermessungswesen (BEV) in Vienna. BEV is also the official time source from Austria.
With a rubidium disciplined NTP server it’s actually possible to adjust this server with an offset to “real time” within a millisecond or so. I realized that the reference couldn’t be adjusted so precisely. Offset was sometimes higher and sometimes lower. So I looked at the GPS based NTP server and I found the same behavior.
Below you can see the offset between November 19th and 24th. The graph show an average value of all 3 NTP server at BEV ( 126.96.36.199, 188.8.131.52 and 184.108.40.206 ). In the image it is listed as 220.127.116.11
We can clearly see that during the first 3 days offset is about zero and than it is much higher ( with a negative value ).
If we do an average calculation of the first 3 days we get -5.8 micro seconds.
Doing the same with the next 3 days we have -37.1 micro seconds. So the difference is more than 31 micro seconds.
As I have the same phenomena on the rubidium server I was sure it was not my hardware. But I couldn’t believe it was a problem of BEV. Finally it’s the official time for Austria. But between me and BEV there is a third component. It’s the network.
Looking at other statistics I found very quick the issue. The round-trip delay changed marginal.
It was during the first 3 days of observation 4.226 milliseconds.
and changed to 4.143 milliseconds during the next days. Which is only 83 micro seconds less.
Very obviously it’s not only the round-trip time. I assume that the delay difference between sending and receiving packets also changed. See also my experiments with ADSL connectivity NTP and ADSL and NTP and ADSL p2.
I have to accept that I have some high precisely time server but I never know how close I am to the real time.