Dear Andreas,

I went through the multislot allocation algorithm and cleaned and structured the code in testable parts that take over parts of the allocation and I have added a unit test for some of the allocation cases (UL first, then DL.. e.g. due a RACH burst and then DL single, UL and DL update).

Today morning I added a testcase that tests all PDCH combinations and all MS Classes and verifies that an allocation takes place and that the DL and UL first_common_ts do match. For (xxOxOOxO) and MS_Class=5 this assert is wrong. The alloc/AllocTest of the sysmocom/allocation-cleanups branch should show you this condition.

While reading the code I noticed the following things. Could you please explain why these are problems or no problems.

* select_first_ts (it exists after the refactoring). It initializes i and compares it but it will never increment it. This means that the code can look at PDCHs _outside_ of the tx_range.

* first_common_ts handling. When assigning the DL tbf we pick a first_common_ts but when the actual UL assignment happens there might not be a free USF on the Uplink and at that point the phone might not listen on the TS we think.

* Sum for Rx+Tx is not used. I see that in update_rx_win_max you modify the window to make some room.

* select_ul_slots. "i" is not incremented in all cases which could potentially lead to using slots outside of the tx_range. For the MS Type == 1 handling you could introduce a different variable that counts how many slots were used?

it would be nice if we could fix that during the 30C3.

holger