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