Long response times using one-off measurements with old probes
Hi, I would like to point you to a discussion on the DNS-OARC mailing list: https://lists.dns-oarc.net/pipermail/dns-operations/2018-December/018196.htm... One of the operators at .ca noticed that old probes report way higher response times using DNS CHAOS queries (300% or more) (see also [3]). After some digging, we came to the conclusion that this has to do with the fact that he is carrying out “one-off” measurements. When carrying out the same query for a longer time, we cannot observe this delay. The issues seems to be that one-off measurements are scheduled at probes using a different library than measurements that run for a longer period (“eooqd” instead of “eperd”). Some small additional delays have been documented before on the RIPE Atlas website and in research papers [1, 2], but the big delay with one off measurements was new to me. Also to others? Is our assumption correct that the scheduler is the culprit? Moritz [1] https://dl.acm.org/citation.cfm?doid=2805789.2805796 [2] https://clarinet.u-strasbg.fr/~pelsser/publications/Holterbach-ripe-atlas-sh... [3] https://atlas.ripe.net/measurements/18086197/#!probes
On 2018/12/14 15:03 , Moritz Muller wrote:
Some small additional delays have been documented before on the RIPE Atlas website and in research papers [1, 2], but the big delay with one off measurements was new to me.
Also to others? Is our assumption correct that the scheduler is the culprit?
So far my investigation shows that the measurement actually takes that long. Why is not clear at the moment, but it doesn't seem to be anything external to the probe. It also doesn't seem to be interference from other measurements. Philip
Not sure if I understood you right. So you think that it doesn’t have anything to do with the probes themselves, but the round trip time is actually that long? Moritz
On 14 Dec 2018, at 15:08, Philip Homburg <philip.homburg@ripe.net> wrote:
On 2018/12/14 15:03 , Moritz Muller wrote:
Some small additional delays have been documented before on the RIPE Atlas website and in research papers [1, 2], but the big delay with one off measurements was new to me.
Also to others? Is our assumption correct that the scheduler is the culprit?
So far my investigation shows that the measurement actually takes that long.
Why is not clear at the moment, but it doesn't seem to be anything external to the probe. It also doesn't seem to be interference from other measurements.
Philip
On 2018/12/17 11:46 , Moritz Muller wrote:
Not sure if I understood you right. So you think that it doesn’t have anything to do with the probes themselves, but the round trip time is actually that long?
No. The extra time is caused by the measurement code. The actual round trip time is only part of the time that is measured. It is not clear what the code is doing during that time or why that time is included in the reported time. Philip
participants (2)
-
Moritz Muller -
Philip Homburg