diff options
| author | Pau Espin Pedrol <pespin@sysmocom.de> | 2018-06-08 15:48:01 +0200 |
|---|---|---|
| committer | Pau Espin Pedrol <pespin@sysmocom.de> | 2018-06-08 17:00:53 +0200 |
| commit | a1a2556c2ae56399a0d24ff19c521c2a182cd31c (patch) | |
| tree | 62f5badfe1d7ab12c3b798194c938a634315ca9b /src/common/bts.c | |
| parent | ef1356c06ccfde74ceeeed4fd9df16d6e09fdf32 (diff) | |
bts_agch_enqueue: Decrease queue len hard_limit from 1000 to 100
In a prod setup, complete channel saturation at the bsc was detected,
and Immediate Assignments were not being answered by the MS once sent by
the BTS.
Further investigation showed that the BTS was all the time printing
messages like this:
"bts.c:540 AGCH: too many messages in queue, refusing message type 0x3f, length = 1001/10"
So it seems the AGCH queue was becoming incredibly full (1000, hard
limit triggered the log), while acgch_queue.max_length was set to 10.
As a result, most probably the Immediate Assignments being sent to the
MS are super old in time, and the MS doesn't known about them anymore
once they are receivied, so no answer is sent back.
Let's try to avoid that by decreasing the hard limit so we never reach
that big queue_len scenario.
The number 100 is selected from data gatherered in agch_test.c which
prints a table of max_length values based on different setups. Some
values can reach around 80 messages, so let's use a slightly bigger hard
limit.
Related: SYS#2695
Change-Id: I272798c959abec123776d2fa8dad5685ec512fbd
Diffstat (limited to 'src/common/bts.c')
| -rw-r--r-- | src/common/bts.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/common/bts.c b/src/common/bts.c index 55f4b945..4fa916ce 100644 --- a/src/common/bts.c +++ b/src/common/bts.c @@ -533,7 +533,7 @@ static int try_merge_imm_ass_rej(struct gsm48_imm_ass_rej *old_rej, int bts_agch_enqueue(struct gsm_bts *bts, struct msgb *msg) { - int hard_limit = 1000; + int hard_limit = 100; struct gsm48_imm_ass_rej *imm_ass_cmd = msgb_l3(msg); if (bts->agch_queue.length > hard_limit) { |