Bug #5552
closed
no overall limit of paging requests at BSC level
Added by laforge about 2 years ago.
Updated over 1 year ago.
Description
It seems we don't have any maximum queue depth for paging requests from the MSC. I've created a TTCN3 test that sends 100 new paging requests per second, and I can see the per-BTS paging queue grow to > 4000 entries, associated with the BSC spending all the CPU cycles it can get in _paging_request
Paging: 4004 pending requests, 16 free slots
I think there shold be some upper limit for the per-BTS paging queue at the BSC.
It may make sense, once reached the threshold of the maximum amount of allowed requests, to try to drop one of the in-retransmission-state requests in the queue, and accept the new one.
- Related to Bug #5553: dynamic T3113 has no reasonable upper bound added
Maximum paging length is already implemented since the last bunch of osmo-bsc paging improvements. See paging.c _paging_request():
#define MAX_TX_DELAY_TIME_SEC 60
[...]
/* don't try to queue more requests than we can realistically handle within MAX_TX_DELAY_TIME_SEC seconds */
if (paging_pending_requests_nr(bts) > paging_estimate_available_slots(bts, MAX_TX_DELAY_TIME_SEC)) {
rate_ctr_inc(rate_ctr_group_get_ctr(bts->bts_ctrs, BTS_CTR_PAGING_OVERLOAD));
return -ENOSPC;
}
Some stuff we may want to improve here:
- Make "MAX_TX_DELAY_TIME_SEC 60" configurable through VTY. This may be useful to configure it so that it matches some paging timeout config at the MSC?
- When the queue is full, instead of dropping it, remove the first non-initial (retrans) entry from the list, then add this new paging req.
- Status changed from New to In Progress
- % Done changed from 0 to 50
- Status changed from In Progress to Feedback
- % Done changed from 50 to 90
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
Also available in: Atom
PDF