This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Holger Freyther holger at freyther.de> On 10. Jan 2018, at 11:55, Harald Welte <laforge at 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