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