Hi, On Fri, Jul 26, 2013 at 10:46:21AM +0200, Robert Kisteleki wrote:
On 2013.07.25. 14:08, Gert Doering wrote:
I'm wondering about something, maybe one of you can enlighten me here.
I have set up a few UDMs (... to eventually get out of Atlas what we had with TTM). A small one with only 10 probes is now showing that actually only 7 probes return data - two more have returned data at some point in the past - "Jul 06, 06:11" in one case - while the 10th assigned problem seems to have never sent anything.
(This is UDM 1002000, the "dead" probe is #2760 in AS 3292).
The question coming from this is: how do probes get assigned to UDMs, and will dead probes get replaced eventually? Or is the assignment done statically at the beginning of the UDM?
The scheduler selects probes when the UDM is started. This is a one-off operation, and takes into account the UDM specification, probe settings and a few other inputs in order to figure out which probes to invite into the measurement.
OK. This is how it looked like, but thanks for confirming (and since the "rate of deterioration" isn't that bad right now, it's not a serious problem yet :-) ). [..]
We have a feature on our backlog to help this: defining and using "low thresholds" for the number of participating probes (you can already set and see this on the UI, but it doesn't really do anything yet). The idea is that you can ask for X probes, and also say that if the number falls below Y then "something" should happen. We imagine that the "something" can be: * notify me * stop the measurement * stop the measurement and schedule a new one with the same parameters * try to swap out non-functioning probes with new ones * (or something else)
I expect that we can start working on this feature this year.
Yes, that would be very nice to have. Both variant 3 and 4 would solve the (potential) problem for us - I don't particularily care to stick to "the same probes all the time", just having "enough working ones" is important. The difference would be, of course, if someone runs long-running trends and you stop/start (variant 3) and re-schedule all the probes, their experiment might be ruined - so for them, variant 4 would be better.
Hope this helps,
It does, thanks! While at it... :-) - I noticed that the measurements I set up were a bit over the top (read: eating up way more credits than my single probe is creating, and also eating up more than "+1m" can replenish). So I wanted to adjust the test parameters slightly - reduce the number of packets from "5" to "3", reduce the number of probes from "100" to "50", etc. - and the user interface won't let me do that. Is this a local browser / operator problem, or an "this is just not supported by the software and maybe never will" missing feature? Of course I can delete the measurement and create a new one, but that would get a new number - so for using this as external reference, with the results being queried and plotted by local scripts, it would be helpful to have a persistent measurement number ("1013617") even if I need to adjust parameters. (Uh, and I just find that I can't seem to restart one of the UDMs either if I ever stop it - intentional, or ui/operator error?) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279