Multislot finished and well tested

Holger Hans Peter Freyther hfreyther at
Mon Jul 23 07:12:12 UTC 2012

On Sun, Jul 22, 2012 at 06:14:55PM +0400, Alexander Chemeris wrote:
> I second that - scheduling is a peculiar part and it's important to
> have tests for it. Though I would say it should be more of a manual
> testing to characterize performance and check for corner cases rather
> then autotests.


the problem with manual tests was already described in Andreas's email.
In general one will not have devices of all classes and with manual 
tests it is easy to skip a step or not being able to reproduce a
specific failure.

On the other hand I believe that scheduling can be fully tested
using autotests at first it will help to move the "scheduling" out of
the gprs_rlcmac_rcv_rts_block function into a dedicated allocation
function and the same applies to the deallocation routines that are
inside the gprs_rlcmac_rcv_data_block_acknowledged. Right now TBF
allocation/deallocation is nested and spread across functions,
writing tests requires one to move them to new dedicated functions.

Once the code became testable the easiest test would be to allocate
TBFs by hand, then call a function and observe how the state changes.
The next step would be to read commands from a text file that describe
what is allocated, timedout, acked. The last part is optional but the
previous parts are absolutely necessary.

This PCU needs to work with thousands of subscribers, handle overload
and failures. There are not too many places with thousands of test users
and I really don't want to debug this PCU on a live system. So please
make the code testable and write tests. Again I am happy to help you
in setting up the framework and give advice on writing tests.


PS: NOOB question, what is the meaning of USF==0x7?

- Holger Freyther <hfreyther at>
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

More information about the osmocom-net-gprs mailing list