Approach to system testing for Osmocom stack

Holger Freyther holger at
Wed Jan 10 22:52:59 UTC 2018

> On 10. Jan 2018, at 11:55, Harald Welte <laforge at> 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?


More information about the baseband-devel mailing list