[atlas] probe congestion?

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