Hi Andreas, Thanks for clarifying. If its only a but (that gets fixed eventually) that's fine. And I'm not desperate about the credits yet ... Best, Gilles On 8/11/13, 16:40 , Andreas Strikos wrote:

Hi Gilles,

normally every measurement is allocated equal or less (if we don't have enough) probes than the user has requested. In your case though, due a bug, your measurement got scheduled more than once, so you got more than you requested. If you are low on credits we could give you back the overcharge amount.

Sorry for the inconvenience.

Regards, Andreas

On 11/8/13, 3:46 PM, Gilles Massen wrote:

...

Hi,

I was wondering how the number of allocated probes is determined for a given UDM. Specifically, I set up a recurring UDM with 50 world-wide probes (DNS), but 110 probes were allocated to the test. While I'm certainly flattered that RIPE Atlas deemed the measurement so worthwhile, the credit consumption was somewhat higher than expected... so what is the logic, and am I able to get (at most) what I requested?

best, Gilles

Hi Gilles, after some more investigation I spotted another problem related to the the group measurements. I released a hot fix and this should be fixed now but the initial problem still remains. The frequency, though, of faulty scheduling will be reduced. The initial bug is triggered when we have a network timeout for one of our control messages. In that case another process kicks in and tries to schedule your measurement. Eventually, since we are handling the network timeouts for all of these control messages, the message is delivered and we schedule again your measurement. That situation was handled smoothly before a month, where we did a big change in the whole Atlas machinery in order to allow addition/removal of probes for all UDMs and unfortunately we broke this part. We know how to fix it but it might take a while (~ December). In the meantime if you or any other that is over-credited due to this bug please send us a mail and we can easily reimburse yours credits. I hope this answers your question :) Regards, Andreas On 11/13/13, 7:19 AM, Gilles Massen wrote:

Andreas,

On 11/08/2013 04:40 PM, Andreas Strikos wrote:

...

normally every measurement is allocated equal or less (if we don't have enough) probes than the user has requested. In your case though, due a bug, your measurement got scheduled more than once, so you got more than you requested. As it happened again (this time >350 allocated probes instead of 53) I was wondering what triggers the bug? Is the scheduling of several measurement in one go the culprit? And is there a recommended workaround for the time being?

Best, Gilles

On 11/13/13, 11:58 AM, Gilles Massen wrote:
> Hi Andreas,
>
> On 13/11/13, 19:26 , Andreas Strikos wrote:
>> Hi Gilles,
>>
>> after some more investigation  I spotted another problem related to the
>> the group measurements. I released a hot fix and this should be fixed
>> now but the initial problem still remains. The frequency, though, of
>> faulty scheduling will be reduced.
> Good, thanks for looking into it.
>
>> In the meantime if you or any other that is over-credited due to this
>> bug please send us a mail and we can easily reimburse yours credits.
> I will survive :)
>
>> I hope this answers your question :)
> Well, almost. I'm not entirely clear on how to setup my new measurement
> - considering that I'd want to have about 8 UDMs sharing the same set of
> probes (or a good approximation). Since you fixed it almost entirely,
> but not quite, should I retry the 'setup in one go' or rather do them
> individually and chose the probes from the first UDM?
Try as you used to, with grouping (in one go as you said). As I said, 
the faulty scheduling frequency should be low now.
> best,
> Gilles
>
>
Regards,
Andreas

On 13.11.2013, at 19:26 , Andreas Strikos <astrikos@ripe.net> wrote:

... That situation was handled smoothly before a month, where we did a big change in the whole Atlas machinery in order to allow addition/removal of probes for all UDMs and unfortunately we broke this part. ...

With hindsight(!) this shows that adding and removing probes in existing measurements was probably not such a good design choice, although I supported it in order to allow repleneshing the probe pool of long-running measurements. Maybe it would be better to revisit that design and go for creating new measurements based on existing ones. We could maintain the genesis history, e.g. which measurement was used as a basis for creating the new one. This would allow tracing back the chain. We could also note that a measurement was used as a template for new measurements which allows following the genesis chain forward. This would solve Gert's use case. It is never too late to review a design choice. It may be painful; but if it prevents future pain it may be the right thing to do. Daniel

On 14.11.2013, at 17:47 , Gilles Massen <gilles.massen@restena.lu> wrote:

On 11/14/2013 10:19 AM, Daniel Karrenberg wrote:

...

With hindsight(!) this shows that adding and removing probes in existing measurements was probably not such a good design choice, although I supported it in order to allow repleneshing the probe pool of long-running measurements.

...

From a simple user point of view I have mixed feelings toward that feature: on one hand it would prevent long running measurements from decaying, on the other hand if you run (multiple) measurements on a specific set of probes you might not want them to drift apart.

Don't worry. No matter how we implement it, it will be configurable. e.g.: if the number of probes drops below a configurable threshold one will have the option to stop the measurement or replenish. Or one can do nothing until there is no probe left.

Gilles

-- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473