Forgot to mention explicitly: Obviously, the more packets per cycle, the higher the likelihood for "field duplication" between responses in the same cycle. For three packets per cycle, it was low enough for at least some cycles to not have the duplication of the poll field. On 18.07.25 11:40, via ripe-atlas wrote:
Hi Robert,
The intentionally misbehaving server is now under a different name/IPv6 address.
https://atlas.ripe.net/measurements/118255807/ -> one packet per interval -> no obvious missing entries in the data (~300 total) https://atlas.ripe.net/measurements/118255806/ -> three packets per interval --> only 15 entries, while a similar number as for 118255807 were expected https://atlas.ripe.net/measurements/118255906/ -> ten packets per interval -> complete fail
I note that those results that _are_ being reported for the measurement with three back-to-back requests per interval (118255806) all have the "poll" field "duplicated" at least once in the "result" substructure ("duplicated" in the sense discussed earlier). "Duplication" of, e.g., "precision" or "ref-ts", is present in the results for that measurement, so likely not an issue.
Locally, I got 250 entries for each of those measurements (vs. 303 for 118255807 from Atlas), but due to how I got them, likely a few were missed.
On 18.07.25 10:18, Robert Kisteleki wrote:
Hi,
(I understand there were many more messages about this recently, somewhat skipping ahead...)
I executed these just now against the same target(s), and results look good: https://atlas.ripe.net/measurements/118369580 <https://atlas.ripe.net/ measurements/118369580> https://atlas.ripe.net/measurements/118370167 <https://atlas.ripe.net/ measurements/118370167>
If I understand correctly things changed on the server side as well, but I'm not 100% sure we can conclude the issue was there to begin with? If so, we can work together and do some controlled experiments - observing closer what the probes get and whether they pass those results along. There is a chance we could improve handling of bad responses, or perhaps there's a bug that eats up good but unexpected responses.
Cheers, Robert
On 10-07-2025 18:01, Marco Davids (SIDN) via ripe-atlas wrote: > Dear list, > > If anyone knows, or is able to figure out, why most (but not all) Atlas > probes don’t report results for NTP measurements to ntp0.testdns.nl <http://ntp0.testdns.nl>, I’d > appreciate your insights. > > Examples: > > https://atlas.ripe.net/measurements/116922622/ <https:// atlas.ripe.net/measurements/116922622/> > > https://atlas.ripe.net/measurements/116946257/ <https:// atlas.ripe.net/measurements/116946257/> > > https://atlas.ripe.net/measurements/116830921/ <https:// atlas.ripe.net/measurements/116830921/> > > Ping works: > > https://atlas.ripe.net/measurements/116921717/ <https:// atlas.ripe.net/measurements/116921717/> > > Thanks in advance. > > > ----- > To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe- atlas.ripe.net/ <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/ <https://www.ripe.net/membership/mail/mailman-3- migration/>