Multislot finished and well tested

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/osmocom-net-gprs@lists.osmocom.org/.

Alexander Chemeris alexander.chemeris at gmail.com
Mon Jul 23 08:15:06 UTC 2012


Hi Holger,

On Mon, Jul 23, 2012 at 9:12 AM, Holger Hans Peter Freyther
<hfreyther at sysmocom.de> wrote:
> 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.
>
> well,
>
> 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.

This system is exactly what I meant. What I'm saying is that (1) those
test doesn't always have OK/FAIL result, they may rather have numeric
performance results, and (2) this framework is useful not only for
regression testing, but for the allocation algorithm hacking/tuning.

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

This is a special value which in means "free", i.e. it's not allocated
to any mobile if we use dynamic allocation (IIRC). And if we use PRACH
channel instead of RACH, then USF 7 is used to mark places for Access
Bursts.


-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru




More information about the osmocom-net-gprs mailing list