[atlas] probe congestion?
- Previous message (by thread): [atlas] probe congestion?
- Next message (by thread): [atlas] probe congestion?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Paul Vlaar
pvlaar at afilias.info
Wed May 11 13:13:58 CEST 2016
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
- Previous message (by thread): [atlas] probe congestion?
- Next message (by thread): [atlas] probe congestion?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]