Hi Joachim, Thanks again for your work and the promising findings! I’ve updated the settings of the NTP simulator (now running at ntp1.testdns.nl) to keep the poll value fixed, and I’ve created a new measurement with 50 probes, each sending 10 packets per interval: https://atlas.ripe.net/measurements/118724341 And indeed — things already look a lot better! So... did we just find a bug? Best, -- Marco -------- Original Message -------- *Subject: *[atlas] Re: Atlas probes not reporting NTP results on ntp0.testdns.nl ? *From: *Joachim Kroß *To: *"Marco Davids (SIDN)" , ripe-atlas@ripe.net *Date: *Thu, 17 Jul 2025 15:30:35 +0200

When multiple packets are sent per sample (default is to send three), those are currently sent back to back. I.e., unless there is packet loss, the second and third request are sent as soon as the response to the previous request has been received. As consequence, the values of the majority of fields in the responses are typically the same, e.g., ref-id, poll, precision, stratum, version, mode, even ref-ts. As such, they are at the top level of the JSON object. And the "result" structure only has the fields that vary between the packets, i.e., the timestamps related to the actual packet transmissions (and derived values).

With the explicitly misbehaving server, however, some of the fields that would typically not change between back-to-back responses, or rather rarely only, _do_ change from one response to the next. E.g., the poll and precision fields. In those cases, there still is an entry at the top level of the JSON object, I guess perhaps derived from the first packet. But then, the result structure would additionally have entries for those types of fields where the value differs from the one at the top level.