This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[atlas] probe congestion?
- Previous message (by thread): [atlas] probe congestion?
- Next message (by thread): [atlas] probe congestion?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Bajpai, Vaibhav
v.bajpai at jacobs-university.de
Wed May 11 14:51:44 CEST 2016
> On 11 May 2016, at 13:13, Paul Vlaar <pvlaar at afilias.info> wrote: > > 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 includes three v3 probes. Note, how they show comparable latencies in both measurements unlike v1/v2 probes. Fig. 4 in [a] will tell you the probe ID ranges for each h/w revision. > 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? It’s generally not useful to draw any conclusions from one-off latency measurements. Run them for a longer period to get some representativeness and then look at the distributions of RTTs across the measurement duration. > What if others are using the same probe at the same time? RIPE Atlas does not provide this guarantee. You have to be prepared that your measurements are running in an uncontrolled setting. > 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? Careful vantage point selection and longitudinal measurements will give you reasonable RTT results. >> 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 [a] http://www.sigcomm.org/sites/default/files/ccr/papers/2015/July/0000000-0000005.pdf =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: </ripe/mail/archives/ripe-atlas/attachments/20160511/698922ed/attachment.sig>
- Previous message (by thread): [atlas] probe congestion?
- Next message (by thread): [atlas] probe congestion?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]