Attention is currently required from: pespin. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bsc/+/28205 ) Change subject: fix performance for chan_counts and all_allocated stats ...................................................................... Patch Set 2: (1 comment) File src/osmo-bsc/chan_counts.c: https://gerrit.osmocom.org/c/osmo-bsc/+/28205/comment/56910c2f_b8b7bf9b PS1, Line 233: case NM_OC_RADIO_CARRIER: Pau, I'd appreciate very much if you could confirm which signals should be used. Here is what I am trying to do: What i need is to call chan_counts_trx_update(trx) when: - the trx is enabled, just after trx_is_usable() starts to return true. (So we need to wait until after the opstart ACK is received and the state changed) - the trx is disabled, just after trx_is_usable() returns false. I noticed this from BSC_Tests.TC_ctrl_trx_rf_locked. Is there also an rf_locked on the BTS level? In that case we probably also need the BTS level obj_class, indeed. And there should then probably also be a ttcn3 test for that? I find it quite hard to understand how to detect when a TRX actually becomes active or inactive. Particularly because of different BTS models apparently doing things differently. For lchans and timeslots it is relatively obvious, because of the bts-model agnostic timeslot_fsm and lchan_fsm. For TRX and BTS levels it's not so easy. After a long while of looking and testing, I finally came up with this signal that works. Before, I tried to put the counting in nm_rcarrier_fsm_becomes_enabled(), which did not work, so that's why I doubt that S_NM_RUNNING_CHG is the right signal (or maybe i am confusing the signals). The counting has to happen right after trx_is_usable() returns the new state, and before anything else happens. BTW if we nail those state transitions, we might be able to get rid of that periodic bsc_update_connection_stats(); when writing that code i already tried to pinpoint these state changes and gave up in the end. But, all of this is not critical. When we miss some state update, there will still be the periodic verification that fixes errors once per second. So we are now "just" discussing how to avoid harmless errors in the log. Even if this patch misses some state changes, the counts will be correct, just not immediately. All the state changes on lchans where it is important to immediately update the counts are covered by this patch. Still, it would be great to understand which signals are correct. -- To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/28205 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bsc Gerrit-Branch: master Gerrit-Change-Id: I580bfae329aac8d4552723164741536af6512011 Gerrit-Change-Number: 28205 Gerrit-PatchSet: 2 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 31 May 2022 17:08:52 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: comment