On 11/5/16 12:46, Bajpai, Vaibhav wrote:
This is known [a, b]. RTT timestamps are applied in user-space.
As such, if a probe is loaded with multiple measurements, the
user-space time stamping will be delayed. These delays will
be more pronounced on v1/v2 probes.
Wow, this sounds pretty bad. The actual result is really huge, look at
the differences here:
- as part of a 6-fold one-off UDM using the same probe set:
https://atlas.ripe.net/measurements/3793146/#!probes
- as a one-off UDM as well, but with manual spacing of 20s in between
scheduling the next of the set of 6 UDMs:
https://atlas.ripe.net/measurements/3793054/#!probes
This seems like a bug to me. The time between scheduling one-off
measurements using the same probe is of influence on the RTT? How can I
trust the RTT at all now? What if others are using the same probe at the
same time?
All scheduling, including one-offs are centrally managed, no? Why can't
the Atlas scheduler make sure that probes don't get loaded with more
than one UDM at a time? I'm no longer trusting any of the RTTs now. Can
this also happen with periodical UDMs?
v3 probes reduce the impact of user-space timestamping. As such, v3
probes are more suitable for latency measurements that require
high precision accuracy. RIPE atlas system tags can be used to
separate probes by h/w version.
Aha. I'll have a try using just v3 probes.
Thank you for the PDFs BTW, I will read those when I have more time.
~paul
