On 10. Jan 2018, at 11:55, Harald Welte
<laforge(a)gnumonks.org> wrote:
Hi Holger,
Sure, I understand. However, it is definitely a part
that we're very
much looking forward to have :)
me too... I dislike not having made progress here.
One might also think of a more structured format to
return the data, but
that could always added later. One could e.g. print a XML or JSON
snippet that's easier to parse/consume by whoever processes it.
Good point. There is nothing that prevents us opening a file/socket/pipe
from the lua code and writing out something. We would need to write out
complete XML/JSON documents (and likely multiple of them) or define a
framing ourselves..
What I also believe is very important is some kind of
rate limiting /
staggering when starting up. We know a single-BTS setup will for sure
fail lots of LU if you stat 1k MS at the same time. So there should be
some kind of provision to say something "start 1000 MS at a rate of 10
per second". I wouldn't go for more elaborate schemes, but simply a
single linear rate/slope.
Makes sense.
Yes, I think it's ok to focus on the
"tester" side and not on the IUT
(implementation under test) side. So we assume that the user will
somehow bring up the [virtual] cellular network before excuting the load
test. One preferred way of doing this is - I agree - by reusing those
parts from osmo-gsm-tester.
Good. I will leave this part.
Now of course '/bin/sleep' is a much simpler
program to start, but the
overhead of the python "orchestration" doesn't change with the resource
footprint of the program started.
Thanks for looking at the process creation. I was concerned of Python's
IO model to read from 2.5k FDs but apparently it has epoll. Computers are
powerful and a single python process could be fine here...
okay. That reduces some degrees of the freedom. Where to put it? Into the
OsmocomBB sources? Osmo GSM tester even if it might not share much code?
holger