On 2014.09.18. 14:32, Jared Mauch wrote:
On Sep 18, 2014, at 6:13 AM, Paul Vlaar <pvlaar@afilias.info> wrote:
On 18/9/14, 12:07 PM, Paul Vlaar wrote:
It seems a bit odd to me that I can't do custom measurements on our server because others are already doing some.
P.S. while I understand this is probably done to protect the server in question, I would like to see a better way to deal with this than just a "hard stop" at 10 measurements. Perhaps a way to negotiate a higher amount of UDMs possible for a given server? As it is now, this feels a like a DoS that is very easy to achieve.
We've been getting more probes up recently, and we even ordered a RIPE Atlas Anchor box so that we can do a decent amount of UDMs on our own servers, but with this limitation in place, I'm fearing disappointment.
There’s some tricks to work around this. The easiest is to have a DNS name that points at the IP, or the RIPE folk have been able to adjust the limit in the past. I have some anycasted IPs I asked them to increase the limit for.
Hi, We have a system-wide setting for "no more than X ongoing measurements against the same target", where X=10 now. One can argue that 10 should be 20 (or a 100, 1000, ...) but there has to be something there. We can make exceptions on this per user. It'd be pretty difficult to administer quotas per target. Instead, our line of thinking at the moment is: * to separate the one-offs from the ongoing measurements; ie. there should be X one-off and X ongoing slots. This would allow users to do ad-hoc measurements even if the destination is otherwise well-measured * to switch to a model where we calculate the expected load on the target, like probes*frequency/time_interval, instead of pure number of measurements (which can have 1..10..100.1000 probes). In this model one could start a new measurement against a target even if there are a 1000 running already, as long as those measurements are not too heavy Let us know what you think about these scenarios! Cheers, Robert