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