I noticed a discrepancy between the output of my own tool and RIPE Atlas. My tool reports the offset as a negative value, while RIPE Atlas shows a positive one. For example: https://atlas.ripe.net/measurements/115803954/results Any thoughts? -- Marco
Seems the server is off about 70 seconds. ntpdate -q 185.214.140.14 server 185.214.140.14, stratum 1, offset -71.553067, delay 0.10294 7 Jul 12:50:31 ntpdate[126673]: step time server 185.214.140.14 offset -71.553067 sec Similar from various other sources. On 07.07.25 14:47, Marco Davids (SIDN) via ripe-atlas wrote:
I noticed a discrepancy between the output of my own tool and RIPE Atlas.
My tool reports the offset as a negative value, while RIPE Atlas shows a positive one.
For example: https://atlas.ripe.net/measurements/115803954/results
Any thoughts?
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
Oh, sorry, I missed that your point was about the sign of the offset... On 07.07.25 14:52, via ripe-atlas wrote:
Seems the server is off about 70 seconds.
ntpdate -q 185.214.140.14 server 185.214.140.14, stratum 1, offset -71.553067, delay 0.10294 7 Jul 12:50:31 ntpdate[126673]: step time server 185.214.140.14 offset -71.553067 sec
Similar from various other sources.
On 07.07.25 14:47, Marco Davids (SIDN) via ripe-atlas wrote:
I noticed a discrepancy between the output of my own tool and RIPE Atlas.
My tool reports the offset as a negative value, while RIPE Atlas shows a positive one.
For example: https://atlas.ripe.net/measurements/115803954/results
Any thoughts?
On Mon, Jul 07, 2025 at 02:47:12PM +0200, Marco Davids (SIDN) via ripe-atlas <ripe-atlas@ripe.net> wrote a message of 130 lines which said:
I noticed a discrepancy between the output of my own tool and RIPE Atlas.
My tool reports the offset as a negative value, while RIPE Atlas shows a positive one.
Old problem with Atlas: https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/thread/VRCMUVH2CQ...
On 07-07-2025 14:57, Stephane Bortzmeyer via ripe-atlas wrote:
Old problem with Atlas:
https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/thread/ VRCMUVH2CQZBI7BTQUHGYMIBG5VMMJE2/
Stephane, I think Marco's problem is a different one from yours. I looked into the data from the Atlas measurement, and it looks like they might be calculating the offsets incorrectly -- either they're dropping the sign or using an wrong, inverted formula. As far as I know, that shouldn’t be happening. See more details on this jupyter notebook: https://github.com/gmmoura/atlas-offset/blob/main/offset.ipynb /giovane
I noticed a discrepancy between the output of my own tool and RIPE Atlas.
My tool reports the offset as a negative value, while RIPE Atlas shows a positive one.
For example: https://atlas.ripe.net/measurements/115803954/results
Any thoughts?
Looking at the code, it seems that the Atlas NTP measurement computes the offset with exactly the opposite sign compared to the NTP RFCs. I never noticed before.
Smells like a bug bounty bounty for Marco, huh? ;-)
Am 08.07.2025 um 17:20 schrieb Philip Homburg <pch-atlas-ml@u-1.phicoh.com>:
I noticed a discrepancy between the output of my own tool and RIPE Atlas.
My tool reports the offset as a negative value, while RIPE Atlas shows a positive one.
For example: https://atlas.ripe.net/measurements/115803954/results
Any thoughts?
Looking at the code, it seems that the Atlas NTP measurement computes the offset with exactly the opposite sign compared to the NTP RFCs.
I never noticed before.
Hi Philip,
Looking at the code, it seems that the Atlas NTP measurement computes the offset with exactly the opposite sign compared to the NTP RFCs.
I never noticed before.
Thanks. Since we are on it, the timestamps are _correct_ , so any user can still compute the offset based on the data Question: how does Atlas computes the `precision` field? I had someone telling on the NTP pool that `Precision from RIPE Atlas probes looks rather low to me (4x10E-6).` Thanks, /giovane [0] https://community.ntppool.org/t/site-to-evaluate-ntp-servers/3931/2
In your letter dated Wed, 9 Jul 2025 09:47:19 +0200 you wrote:
Question: how does Atlas computes the `precision` field?
I had someone telling on the NTP pool that `Precision from RIPE Atlas probes looks rather low to me (4x10E-6).`
Looking at the code, the precision field is just copied from the reply that was received from the server. Unless there is a decoding error.
how does Atlas computes the `precision` field?
I believe the format_8bit() function in the probe's ntp.c is responsible for the conversion [1]. 4x10E-6 would be an NTP precision value of -18 (3.815 us), which isn't great nowadays, but I think not completely out off whack. [1] https://github.com/RIPE-NCC/ripe-atlas-software-probe/blob/57515ad8a4a84f19a... On 09.07.25 09:47, Giovane C. M. Moura via ripe-atlas wrote:
Hi Philip,
Looking at the code, it seems that the Atlas NTP measurement computes the offset with exactly the opposite sign compared to the NTP RFCs.
I never noticed before.
Thanks. Since we are on it, the timestamps are _correct_ , so any user can still compute the offset based on the data
Question: how does Atlas computes the `precision` field?
I had someone telling on the NTP pool that `Precision from RIPE Atlas probes looks rather low to me (4x10E-6).`
Thanks,
/giovane
[0] https://community.ntppool.org/t/site-to-evaluate-ntp-servers/3931/2
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe- atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/ mailman-3-migration/
participants (6)
-
Carsten Schiefner -
Giovane C. M. Moura -
Marco Davids (SIDN) -
Philip Homburg -
ripe＠nurfuerspam.de -
Stephane Bortzmeyer