[mat-wg] Atlas UDMs and Probe-Assignments

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
URL: </ripe/mail/archives/mat-wg/attachments/20130726/4b52b749/attachment.sig>