Attention is currently required from: laforge, pespin.
1 comment:
Patchset:
I'm not sure I am following your explanation 100% but it sounds really like this kind of change. This sounds like a kludge on top of a kludge on top of a kludge.
Well, the main problem here is indeed inability of fake_trx.py to generate NOPE.ind. I agree that it's more a kludge rather than a proper solution to make trxcon generate NOPE.req and convert them to NOPE.ind. But it was the quickest and the easiest solution [0] I came up with back in 2021, when adding TTCN-3 testcases for features like the interference reporting, which do rely on NOPE indications.
[0] https://gerrit.osmocom.org/q/I1c7f1315b8ef44f651efd6a22fb5b854f65c0946
What we shold be doing is make sure that the fake_trx setup looks more like a real setup - both towards trxcon as well as towards osmo-bts-trx.
Ideally, yes. But I am afraid we have reached the limit of what we can do with this "quick testing hack" implementation. Back in 2020 I tried to implement [1] proper burst queueing a few years ago, but we ended up with serious performance regressions when running ttcn3-bts-test and had to revert [2] these patches.
[1] https://gerrit.osmocom.org/q/Ie66ef9667dc8d156ad578ce324941a816c07c105
[2] https://gerrit.osmocom.org/q/If29b4f6718cbc8af18fe18a5e3eca3912e8af01e
Maybe the real solutoin is to replace fake_trx.py with an implementation that doesn't have scalability/performance issues, if needed in C?
It's indeed an option. I am all for it, but this does not sound like something I could quickly hack on during one working day. This would definitely require several days of work. If you think it's worth spending time on this right now, I would be happy to start rewriting from Python to C. Not sure though given the current amount of pending work.
While writing the above part I realized that making fake_trx behave like a real transceiver with its own clock and queues, we would *have* to use fn-advance in trxcon. This will make testing the MS side GPRS implementation impossible, because proper Uplink timings are crucial for proper RLC/MAC operation.
IMO, for now we can live with "a kludge on top of a kludge on top of a kludge". All I am trying to achieve with this patchset is simplifying life for those (mostly Pau and me) who need to test patches quickly and conveniently, without having to connect to the physical MS SDR setup in Sysmocom's office.
To view, visit change 33165. To unsubscribe, or for help writing mail filters, visit settings.