Slow database access at OpenBSC

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

Andreas Eversberg andreas at eversberg.eu
Sun Jun 23 12:59:27 UTC 2013


hi,

i experienced audio glitches while another phone does location updating:

<0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 05) Sending 0x18 to MS.
<0008> abis_rsl.c:1027 [262421104120913] MEASUREMENT RESULT NR=0
RXL-FULL-ul=-110dBm RXL-SUB-ul=-47dBm R Q-FULL-ul=0 RXQ-SUB-ul=0
BS_POWER=0 L1_MS_PWR=  0dBm L1_FPC=0 L1_TA=0 NOT VALID NUM_NEIGH=0
<0003> bsc_api.c:615 CLASSMARK CHANGE CM2(len=3) CM3(len=4)
dbi access time 95ms
Stalled 96ms
<0008> abis_rsl.c:1027 [262421104120913] MEASUREMENT RESULT NR=1
RXL-FULL-ul=-66dBm RXL-SUB-ul=-47dBm RX -FULL-ul=0 RXQ-SUB-ul=0
BS_POWER=0 L1_MS_PWR=  0dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm
RXL-SUB-dl=-47dB  RXQ-FULL-dl=0 RXQ-SUB-dl=0 NUM_NEIGH=7
dbi access time 50ms
dbi access time 0ms
dbi access time 49ms
dbi access time 58ms
dbi access time 83ms
dbi access time 0ms
dbi access time 0ms
dbi access time 0ms
dbi access time 72ms
<0003> gsm_04_08_utils.c:315 TX CIPHERING MODE CMD
Stalled 319ms
<0008> abis_rsl.c:1027 [262421104120913] MEASUREMENT RESULT NR=2
RXL-FULL-ul=-65dBm RXL-SUB-ul=-47dBm RX -FULL-ul=0 RXQ-SUB-ul=0
BS_POWER=0 L1_MS_PWR=  0dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-47dBm
RXL-SUB-dl=-47dB  RXQ-FULL-dl=0 RXQ-SUB-dl=0 NUM_NEIGH=7
<0003> osmo_msc.c:105 CIPHERING MODE COMPLETE
dbi access time 0ms
dbi access time 69ms
<0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 05) Sending 0x02 to MS.
<0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 05) Sending 0x32 to MS.
dbi access time 66ms
dbi access time 0ms
dbi access time 0ms
<0003> gsm_04_08.c:1249 TX APPLICATION INFO id=0x00, len=4
<0001> gsm_04_08.c:191 (bts 1 trx 0 ts 0 pd 06) Sending 0x38 to MS.
dbi access time 0ms
Stalled 140ms

the total time that openbsc was stalling is 555ms in this case. there
are only 4 subscribers in hlr and counter writing is disabled. is there
any trick to make database access faster?

speeding up the db access does not solve the problem. an async db access
is one solution, but there is other code at openbsc that might require
some time. (e.g. handling of many measurement reports) one solution is
to have an own thread for the audio processing. this thread must access
different interfaces independently from the rest of the openbsc code:

- RTP sockets
- MNCC socket
- TRAU sockets of E1 timeslots

MNCC socket could be split into two sockets: one for signalling, one for
audio traffic. this way it is not required to use queues and signals
between main thread and audio thread. a problem in case of
multithreading is osmo_select_main(). it uses global list of file
descriptors and global rb-tree for timers. one solution would be having
multiple lists and trees for each thread id. this way it is not required
to change timer and file descriptor api.

another solution could be a seperate process, which handles audio only.
i don't really like a sepeate process, since it requires some interface
to openbsc and makes everything more complex. even though i don't like
threads, multithreading seems to be the best solution to me at the moment.

was there any effort to solve the problem or to handle audio? are there
any suggestions about it?

regard,

andreas







More information about the OpenBSC mailing list