Interestingly, measurements that don't yield _any_ results at all (i.e.,
not even "no response" or some explicit error condition) are marked as
"Failed". That status is documented, but I had never seen it before.
As far as I could see so far, when the evntp command is run as part of
an actual probe, data is indeed generated as well. It can be found in
the spool directory. And it disappears regularly from that directory,
suggesting that it is being transmitted to the infrastructure. In turn
suggesting, and supporting Marco's hypothesis, that something on the
infrastructure side may be subsequently dropping the data.
One thing I noted with this explicitly misbehaving server:
When a probe sends multiple packets per interval (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
between responses, 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
transmission (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
response packet. But then, the result structure would additionally have
entries for those types of fields in a response where the value differs
from the one at the top level.
Obviously speculating, and certainly not foregoing a deeper look by RIPE
Atlas staff, but maybe the infrastructure discards such probe reports
for whatever reason.
It seems the explicitly misbehaving server has been replaced by a more
sane one (albeit apparently not synchronized), so one cannot at this
time follow up on the above hypothesis. E.g., a measurement where only a
single packet is being sent per interval should succeed as it wouldn't
have the same type of values at different levels of the JSON structure.
On 14.07.25 18:09, Marco Davids (SIDN) via ripe-atlas wrote:
FWIW:
I compiled the probe and couldn't find anything out of the ordinary:
./busybox evntp -6 -c 3 -w 4000 ntp0.testdns.nl
RESULT { "dst_name":"ntp0.testdns.nl", "ttr":109.453445,
"dst_addr":"2a02:2308:20:0:216:3eff:fe85:f45c",
"src_addr":"2001:1c00:c081:ed00:201:c0ff:fe06:3551", "proto":"UDP",
"af": 6, "li": "no", "version": 4, "mode": "server", "stratum": 1,
"poll": 128, "precision": 1.19209e-07, "root-delay": 0, "root-
dispersion": 0, "ref-id": "XFUN", "ref-ts": 3961497676.014892578,
"result": [ { "origin-ts": 3961497975.998575211, "receive-ts":
3961497976.014892578, "transmit-ts": 3961497976.014945984, "final-ts":
3961497976.027197838, "rtt": 0.028570, "offset": -0.002033 }, { "poll":
256, "precision": 3.72529e-09, "ref-ts": 3961497676.041306019, "origin-
ts": 3961497976.027345181, "receive-ts": 3961497976.041306019,
"transmit-ts": 3961497976.041354656, "final-ts": 3961497976.051036835,
"rtt": 0.023643, "offset": -0.002139 }, { "poll": 256, "precision":
1.49012e-08, "ref-ts": 3961497676.063885689, "origin-ts":
3961497976.051280022, "receive-ts": 3961497976.063885689, "transmit-ts":
3961497976.063924313, "final-ts": 3961497976.072422028, "rtt": 0.021104,
"offset": -0.002054 } ] }
./busybox evntp -6 -c 1 ntp1.testdns.nl
RESULT { "dst_name":"ntp1.testdns.nl", "ttr":479.530349,
"dst_addr":"2a05:f480:1800:2898:5400:5ff:fe7c:8c82",
"src_addr":"2001:1c00:c081:ed00:201:c0ff:fe06:3551", "proto":"UDP",
"af": 6, "li": "no", "version": 4, "mode": "server", "stratum": 1,
"poll": 1024, "precision": 7.45058e-09, "root-delay": 0, "root-
dispersion": 0, "ref-id": "XFUN", "ref-ts": 3961497821.676918507,
"result": [ { "origin-ts": 3961498121.667407990, "receive-ts":
3961498121.676918507, "transmit-ts": 3961498121.676956654, "final-ts":
3961498121.687090874, "rtt": 0.019645, "offset": 0.000312 } ] }
-----
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/
