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

Holger Hans Peter Freyther holger at freyther.de
Mon Jun 24 05:53:29 UTC 2013


On Sun, Jun 23, 2013 at 02:59:27PM +0200, Andreas Eversberg wrote:
> 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.

fork (syscall) the mgcp mgw and make the NITB a call-agent. This way all
the audio will flow in a different process like it is done in the real
BSC right now.

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

I looked into libdbi once[1] and saw that every SELECT actually
spawns multiple PRAGMA calls to figure out the column types. On the
congress we should use a patched libdbi sqlite3 driver that is caching
the result of the pragma..

cheers
	holger

[1] http://sourceforge.net/mailarchive/message.php?msg_id=26808928




More information about the OpenBSC mailing list