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/ripe-atlas@ripe.net/
[atlas] Feature-suggestion: "round-robin" probes
- Previous message (by thread): [atlas] Routing glitch between BSNL and F Root
- Next message (by thread): [atlas] Feature-suggestion: "round-robin" probes
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Alexander Mayrhofer
alexander.mayrhofer at nic.at
Fri Apr 27 12:20:59 CEST 2012
Hello, i'm figuring how RIPE atlas could be most useful for assisting in monitoring our Ancast Network, and came up with the following idea: The Atlas network has a big advantage over other monitoring /measurement networks, which is obviously its sheer size (and topological diversity). Rather than using the Atlas network for pure performance measurements, i would love to be able to use Atlas for reachability measurements (and understand which Anycast location attracts traffic from which region, and how this changes over time). These reachability / topology discovery measurements do not need to be nearly as frequent as the performance measurements, but should utilize all available probes. So, instead of being able to use 10 probes to run a continous performance test (say, DNS query every 300 seconds), i would rather like to be able to use a very high number of probes (best case: "all"), but have each of the probe eg. perform just one traceroute per day (or, even once per week would be enough). This would give me an excellent overview about the topology, but is not possible using the current limits of the UDMs. However, instead of allowing users to allocate measurements to a much higher number of probes, this functionality would also be possible be adding some "probe round-robin" feature to the control infrastructure, for example "randomly allocate a new set of probes every xx seconds". If that feature would exist, i could implement the above reachability test with the following parameters: Test: traceroute Number of probes: 10 Measurement interval: 3600 Swap probe-set interval: 10800 (NEW feature) (which would re-allocate new probes every 3 hours, theoretically working through all 1500 probes about every month?). An obvious alternative would be functionality where i could "queue" "single-shot" measurements for the whole network (since chances are low i would get every probe if they are randomly assigned). comments? Suggestions? Alternatives? Alex Mayrhofer Head of R&D nic.at
- Previous message (by thread): [atlas] Routing glitch between BSNL and F Root
- Next message (by thread): [atlas] Feature-suggestion: "round-robin" probes
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]