Attention is currently required from: dexter.
laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/pysim/+/28160 )
Change subject: pySim-shell: extend walk() so that we can also have an action of ADF or DF
......................................................................
Patch Set 4: Code-Review+1
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/28160
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: Iabcd78552a14a2d3f8f31273dda7731e1f640cdb
Gerrit-Change-Number: 28160
Gerrit-PatchSet: 4
Gerrit-Owner: dexter <pmaier(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Attention: dexter <pmaier(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 31 May 2022 19:31:38 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
Attention is currently required from: neels.
pespin 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/f17d4834_4dba7144
PS1, Line 233: case NM_OC_RADIO_CARRIER:
> The situation you are trying to catch ("the trx is enabled, just after trx_is_usable() starts to ret […]
"You should be using that one only in that case"
I meant:
"You should be using only that one in that case".
Sorry the order I used before could be confusing ;)
--
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: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 31 May 2022 17:16:16 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: neels.
pespin 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/ae278fd7_d1352524
PS1, Line 233: case NM_OC_RADIO_CARRIER:
> Pau, I'd appreciate very much if you could confirm which signals should […]
The situation you are trying to catch ("the trx is enabled, just after trx_is_usable() starts to return true." || "the trx is disabled, just after trx_is_usable() returns false.") is precisely what S_NM_RUNNING_CHG I itnroduced recently is for. You should be using that one only in that case (you also need to do the checks for the BBTRANSC also, since trx_is_usable() checks both RCARRIER and BBTRANSC).
Please have a look at the commit messages I posted above, they contain a couple examples on how to use the signal.
--
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: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 31 May 2022 17:14:40 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
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:
> I guess this is to update when ts_is_usable (trx_is_usable()) changes. […]
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