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 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

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.

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.

Dear all, Thank you for highlighting the issue with NTP offset calculation. We have identified it and are working on a fix, which we expect to issue in an upcoming release. In the meantime, our suggestion towards users is to use the reported timestamps in the measurement results to perform the RFC-compliant offset calculation. We apologise for any inconvenience caused. Best regards, -- Marios Mavropoulos Papoudas Software Engineer - RIPE Atlas RIPE NCC On Wed, 9 Jul 2025 at 11:22, via ripe-atlas <ripe-atlas@ripe.net> wrote:

...

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/

----- 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/