Pau Espin
1e00947c29
When both TBFs (Dl, Ul), are detached, ms_detach_tbf() will call ms_start_timer() which will hold a reference of the MS (ms_ref()) and wait for X seconds (VTY config, T=-2030, 60 seconds by default) before unrefing the MS, which will trigger ms_update_status() finally (ref==0) and will in turn call cb.ms_idle(), which will tell the ms_storage to free the MS. This mechanism is used to keep MS objects around for a certain time so that when new TBFs are established, we have cached interesting information about the MS, ready to use. However, in AllocTest, tons of MS are allocated in a loop calling a function (such as test_alloc_b_ul_dl()). In that function, a BTS is allocated in the stack and at the end of the function BTS::cleanup() is called due to implicit destructor, which ends up calling ms_storage::cleanup() which removes all MS from its list and frees them *if they are not idle*. The problem here, is that due to T=-2030, an extra reference is hold and hence the ms is not considered idle (ms_is_idle() checks ms->ref==0). As a result, the MS is never freed, because we don't use libosmocore mainloop here (and in any case, it would take 60 seconds to free it). By setting the timeout of T=-2030 to 0, ms_start_timer will avoid using the timer and will also avoid holding the extra reference, hence allowing ms_storage to free the object during cleanup(). This fix really helps in improving performance for AllocTest specially after MS object contains a rate_ctr. As tons of MS objects were left alive, they stood in the rate_ctr single per-process queue, making the test last crazy amount of time and spending 50% of the time or more iterating the list full of MS related rate counters. Change-Id: I6b6ebe8903e4fe76da5e09b02b6ef28542007b6c |
||
|---|---|---|
| contrib | ||
| debian | ||
| doc | ||
| include | ||
| src | ||
| tests | ||
| .gitignore | ||
| .gitreview | ||
| COPYING | ||
| Makefile.am | ||
| README.md | ||
| TODO | ||
| TODO-RELEASE | ||
| configure.ac | ||
| git-version-gen | ||
| osmoappdesc.py | ||
README.md
osmo-pcu - Osmocom Packet Control Unit
This repository contains a C/C++-language implementation of a GPRS Packet Control Unit, as specified by ETSI/3GPP. It is part of the Osmocom Open Source Mobile Communications project.
The Packet Control Unit is terminating the Layer 2 (RLC/MAC) of the GPRS radio interface and adapting it to the Gb Interface (BSSGP+NS Protocol) towards the SGSN.
The PCU interfaces with the physical layer of the radio interface. OsmoPCU is typically used co-located with the BTS, specifically OsmoBTS. For legacy BTSs that run proprietary sotware without an interface to OsmoPCU, you may also co-locate it with the BSC, specifically OsmoBSC
Homepage
The official homepage of the project is https://osmocom.org/projects/osmopcu/wiki/OsmoPCU
GIT Repository
You can clone from the official osmo-pcu.git repository using
git clone git://git.osmocom.org/osmo-pcu.git
There is a cgit interface at http://git.osmocom.org/osmo-pcu/
Documentation
We provide a user manual as well as a vty reference manual
Please note that a lot of the PCU configuration actually happens inside the BSC, which passes this configuration via A-bis OML to the BTS, which then in turn passes it via the PCU socket into OsmoPCU.
Mailing List
Discussions related to osmo-pcu are happening on the osmocom-net-gprs@lists.osmocom.org mailing list, please see https://lists.osmocom.org/mailman/listinfo/osmocom-net-gprs for subscription options and the list archive.
Please observe the Osmocom Mailing List Rules when posting.
Contributing
Our coding standards are described at https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards
We us a gerrit based patch submission/review process for managing contributions. Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit for more details
The current patch queue for osmo-pcu can be seen at https://gerrit.osmocom.org/#/q/project:osmo-pcu+status:open
Current limitations
- No PFC support
- No fixed allocation support (was removed from 3GPP Rel >= 5 anyway)
- No extended dynamic allocation support
- No unacknowledged mode operation
- Only single slot assignment on uplink direction
- No half-duplex class support (only semi-duplex)
- No TA loop
- No power loop