Atlas UDMs and Probe-Assignments
Hi, 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 reason why this is relevant: if I am going to set up UDMs to replace what TTM does, the idea is to have a reasonable high number of probes, say "50" or "100", and define our Internet reliability as "more than 2/3rd of the UDM probes have been answered without loss", or something like that - taking into account that somewhere on the Internet, things will always be broken, but that's not our responsibility. This falls apart of probes deteriorate after a given time, and a given UDM measurement will use "less and less probes" (so in the extreme, of the 50 initial probes, 30 might be "dead probe" and thus the result is always "0% reliability, more than 50% of the probes can not reach us"), instead of the system keeping the requested number of probes by replacing dead ones... 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
Hi Gert, On 2013.07.25. 14:08, Gert Doering wrote:
Hi,
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.
The reason why this is relevant: if I am going to set up UDMs to replace what TTM does, the idea is to have a reasonable high number of probes, say "50" or "100", and define our Internet reliability as "more than 2/3rd of the UDM probes have been answered without loss", or something like that - taking into account that somewhere on the Internet, things will always be broken, but that's not our responsibility.
Right; the probes are all around the 'net, in all sorts of locations, so it's unlikely that all of them will be successful in your measurement.
This falls apart of probes deteriorate after a given time, and a given UDM measurement will use "less and less probes" (so in the extreme, of the 50 initial probes, 30 might be "dead probe" and thus the result is always "0% reliability, more than 50% of the probes can not reach us"), instead of the system keeping the requested number of probes by replacing dead ones...
Indeed, it's reasonable to expect that over some time period a subset of the probes will no longer participate in your measurement (or in any other measurements). 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. Hope this helps, Robert
Gert Doering -- NetMaster
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
Hi,
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.
Sure. These seem to be different use cases, so the best approach seems to be to support all of them (eventually).
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?
The later one. We didn't really hear (so far) from users that this would be a useful feature. We could develop features to add or remove individual probes to/from existing measurements, through some kind of UI or API calls.
(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?)
See above -- it's very valuable to us to hear such requests from you. Regarding this particular case, keep in mind restarting an older measurement would have its own problems, e.g. it's entirely possible that the same probes cannot be allocated the second time around. That'd lead to all kinds of odd cases. Regards, Robert
Hi, On Fri, Jul 26, 2013 at 11:45:03AM +0200, Robert Kisteleki wrote:
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.
Sure. These seem to be different use cases, so the best approach seems to be to support all of them (eventually).
Well, that's sort of what I tried to express :-) - "it makes sense to have all of these options, as different users need different behaviours". [..]
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?
The later one. We didn't really hear (so far) from users that this would be a useful feature. We could develop features to add or remove individual probes to/from existing measurements, through some kind of UI or API calls.
(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?)
See above -- it's very valuable to us to hear such requests from you. Regarding this particular case, keep in mind restarting an older measurement would have its own problems, e.g. it's entirely possible that the same probes cannot be allocated the second time around. That'd lead to all kinds of odd cases.
For me, when editing "fundamental" options (number of probes, or restarting an already-terminated UDM), basically re-scheduling the UDM from scratch as if newly entered into the system, with a completely freshly allocated list of probes, would be perfectly fine. It still saves on having to re-enter all the data, and being re-assigned a new number. OTOH, for changing things like packet size or number of packets, it would be nice to keep the list of assigned probes. 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
participants (2)
-
Gert Doering -
Robert Kisteleki