Unbounded AGCH queue in OsmoBTS

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/.

Alexander Chemeris alexander.chemeris at gmail.com
Tue Sep 10 09:55:47 UTC 2013


On Tue, Sep 10, 2013 at 1:21 PM, Holger Hans Peter Freyther
<holger at freyther.de> wrote:
> On Tue, Sep 10, 2013 at 11:41:33AM +0400, Alexander Chemeris wrote:
>> Hi all,
>>
>> An attached is a quick fix for the unbounded queue growth. It uses a
>> hardcoded value for the maximum queue length, which is fine for our
>> load testing, but not flexible enough for the real life usage. We
>> should make the AGCH queue long enough to keep high performance. At
>> the same time, it must not exceed MS timeout or _all_ IMM.ASS messages
>> will miss their target MS's.
>>
>> We could make this parameter user-configurable on a BTS side, but it
>> seems more reasonable to automatically calculate it, depending on the
>> channel combination and timeout values. But this should be done on the
>> BSC side. So the questions are:
>> 1) what is a good way to calculate it?
>> 2) should we configure this queue length over OML, or move the queue
>> from BTS to BSC?
>
> I had a quick look at 12.21 and there doesn't appear to be anything
> for the AGCH. So we will need to calculate the size from the channel
> configuration but this should be fairly easy. The other topic is the
> question of fairnes? The first requests will fill the queue, and then
> we drop most of the requests.

In a flood situation fairness doesn't make much sense, since most of
the requests will be dropped and we will process random requests
anyway. So the best situation for the flood case is actually to have a
very short (zero?) queue to reduce queueing latency. From this point,
Andreas' ide to use a stack instead of a queue makes perfect sense.

> Can you implement the size calculation?

I could, but I think you or Andreas will do this cleaner and with much
less effort. I would rather spend my time on looking for other issues
and implementing new features I have more experience with.


PS While you're here - I remind you that I'm still waiting for the
review of the SMS DB schema update code.

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




More information about the OpenBSC mailing list