More anchors involved in DNSMON measurements
Dear DNSMON users, Due to the growth of numbers in active RIPE Atlas anchors, we started involving more anchors from outside our service region in DNSMON measurements. This has a natural effect on the visualisations: the newly involved anchors don't have a measurement history yet, so they show up as "no data" before the addition. We're introducing these changes gradually for the monitored zones so the changes are not yet visible everywhere. Regards, Robert Kisteleki
Hi Robert,
Due to the growth of numbers in active RIPE Atlas anchors, we started involving more anchors from outside our service region in DNSMON measurements. This has a natural effect on the visualisations: the newly involved anchors don't have a measurement history yet, so they show up as "no data" before the addition.
thanks for the heads up and good to see the measurement network is growing! Could you please elaborate a bit on how you select the anchors per TLD/domain monitored and what your thoughts re stability (of the anchor set over time) and comparability (of the sets used for one domain vs another) are? I wonder whether it would scale to run all measurements from all the anchors and then only "customize" the covering set for the display. -Peter
On 2014.07.15. 10:12, Peter Koch wrote:
Hi Robert,
Due to the growth of numbers in active RIPE Atlas anchors, we started involving more anchors from outside our service region in DNSMON measurements. This has a natural effect on the visualisations: the newly involved anchors don't have a measurement history yet, so they show up as "no data" before the addition.
thanks for the heads up and good to see the measurement network is growing! Could you please elaborate a bit on how you select the anchors per TLD/domain monitored and what your thoughts re stability (of the anchor set over time) and comparability (of the sets used for one domain vs another) are? I wonder whether it would scale to run all measurements from all the anchors and then only "customize" the covering set for the display.
-Peter
Hi Peter, all, For consistency reasons we're trying to involve the same set of anchors for monitoring each zone. This will probably not scale forever, but we'll try to do this as long as we can. Earlier we've heard from operators that they'd appreciate if we used a wider set of anchors, eg. add more from outside the EU. So this time we added the following: 1) us-sea-as2914, Seattle, ID 6065 2) us-dal-as7366, Dallas, ID 6067 3) us-atl-as2914, Atlanta, ID 6066 4) us-mia-as2914, Miami, ID 6062 5) uy-mvd-as28000, Montevideo, ID 6054 6) za-jnb-as10474, Johannesburg, ID 6053 7) tn-tun-as5438, Tunis, ID 6051 8) au-mel-as38796, Melbourne, ID 6044 9) au-bne-as4608, Brisbane, ID 6055 10) ru-mow-as47764, Moscow, ID 6046 The number of anchors is expected to grow to an unknown (but hopefully high) number, meaning there has to be a cutoff at some reasonable point. Indeed some anchors are more stable than others. That's not a new phenomenon, I believe it happened to TTM boxes as well. As for what to do with anchors that consistently fail or are down for along time: we don't have a policy defined yet. I'd expect that if a particular anchor proves to be useless for this purpose, then we'll remove it from the pool. (But, after how long? 3-6-12 months, 1 year? We're happy to receive advice from the community about this.) Hope this helps, Robert
On 15.07.14 14:01 , Robert Kisteleki wrote:
... Indeed some anchors are more stable than others. That's not a new phenomenon, I believe it happened to TTM boxes as well. As for what to do with anchors that consistently fail or are down for along time: we don't have a policy defined yet. I'd expect that if a particular anchor proves to be useless for this purpose, then we'll remove it from the pool. (But, after how long? 3-6-12 months, 1 year? We're happy to receive advice from the community about this.)
This discussion shows that RIPE Atlas has reached a scale that makes it necessary to devise quite dynamic ways of "calibrating" measurements. The number of anchors will soon grow such that this is also necessary for anchors. Personally I believe that in the long run it will be necessary to provide calibration data that can be used to interpret the results of measurements and to dynamically change the pools of probes used for specific measurements. For instance, if a probe/anchor suddenly shows an increase in the variance of all its results this may be a network phenomenon or a measurement artefact. In any case it *may* be reason to disregard or scale the results when using them in specific measurements and studies. I am currently working on this. This is slow work because it is not straightforward and also because I have had some unexpected other duties in the governance area. Daniel
Hi Robert,
For consistency reasons we're trying to involve the same set of anchors for monitoring each zone. This will probably not scale forever, but we'll try to do this as long as we can.
sounds good.
Earlier we've heard from operators that they'd appreciate if we used a wider set of anchors, eg. add more from outside the EU. So this time we added the following:
[...] indeed, making the measurements less Euro centric is appreciated.
Indeed some anchors are more stable than others. That's not a new phenomenon, I believe it happened to TTM boxes as well. As for what to do with anchors that consistently fail or are down for along time: we don't have a policy defined yet. I'd expect that if a particular anchor proves to be useless for this purpose, then we'll remove it from the pool. (But, after
Well, if an anchor becomes unstable in some sense, it's probably useless for the whole project? My question was more aiming at the stability of the set of anchors as such rather than the operational stability of individual anchors. Thanks for the clarifications. -Peter
Peter Koch wrote: [...]
Well, if an anchor becomes unstable in some sense,
Which reminds me that I should follow up on the individual probes' stability aspect, both the small ones as well as anchor ones. But I presume this discussion is better placed in the general list? Wilfried
[...]
-Peter
participants (4)
-
Daniel Karrenberg -
Peter Koch -
Robert Kisteleki -
Wilfried Woeber