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/gerrit-log@lists.osmocom.org/.
Harald Welte gerrit-no-reply at lists.osmocom.orgHarald Welte has submitted this change and it was merged. ( https://gerrit.osmocom.org/9513 ) Change subject: bts_agch_enqueue: Decrease queue len hard_limit from 1000 to 100 ...................................................................... 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 --- M src/common/bts.c M tests/agch/agch_test.ok 2 files changed, 3 insertions(+), 3 deletions(-) Approvals: Jenkins Builder: Verified Harald Welte: Looks good to me, approved diff --git a/src/common/bts.c b/src/common/bts.c index 55f4b94..4fa916c 100644 --- a/src/common/bts.c +++ b/src/common/bts.c @@ -533,7 +533,7 @@ 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) { diff --git a/tests/agch/agch_test.ok b/tests/agch/agch_test.ok index 49173a3..4e0a9e1 100644 --- a/tests/agch/agch_test.ok +++ b/tests/agch/agch_test.ok @@ -18,6 +18,6 @@ 32 83 28 83 83 83 50 28 14 28 28 28 Testing AGCH messages queue handling. -AGCH filled: count 720, imm.ass 80, imm.ass.rej 640 (refs 640), queue limit 32, occupied 240, dropped 0, merged 480, rejected 0, ag-res 0, non-res 0 -AGCH drained: multiframes 32, imm.ass 80, imm.ass.rej 12 (refs 48), queue limit 32, occupied 0, dropped 148, merged 480, rejected 0, ag-res 31, non-res 61 +AGCH filled: count 720, imm.ass 80, imm.ass.rej 640 (refs 640), queue limit 32, occupied 101, dropped 0, merged 198, rejected 421, ag-res 0, non-res 0 +AGCH drained: multiframes 16, imm.ass 34, imm.ass.rej 12 (refs 42), queue limit 32, occupied 0, dropped 56, merged 198, rejected 421, ag-res 15, non-res 30 Success -- To view, visit https://gerrit.osmocom.org/9513 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-MessageType: merged Gerrit-Change-Id: I272798c959abec123776d2fa8dad5685ec512fbd Gerrit-Change-Number: 9513 Gerrit-PatchSet: 2 Gerrit-Owner: Pau Espin Pedrol <pespin at sysmocom.de> Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org> Gerrit-Reviewer: Jenkins Builder -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20180608/0faa9bdd/attachment.htm>