Attention is currently required from: manawyrm, roox, laforge.
tnt has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-e1d/+/27845 )
Change subject: octoi: differentiate UNDERRUN from SUBSTITUTED in counters
......................................................................
Patch Set 1:
(1 comment)
File src/octoi/frame_rifo.c:
https://gerrit.osmocom.org/c/osmo-e1d/+/27845/comment/757e53ef_2a772371
PS1, Line 141: if (frame_rifo_depth(rifo) == 0) {
I think technically the current frame_rifo_depth is "off-by-one" in the sense that it will return 0 if the frame that's about to be read is the last one.
--
To view, visit https://gerrit.osmocom.org/c/osmo-e1d/+/27845
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-e1d
Gerrit-Branch: master
Gerrit-Change-Id: I5448430b09ec10a16decdfd0a4a40850fe2ed1a6
Gerrit-Change-Number: 27845
Gerrit-PatchSet: 1
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: manawyrm <osmocom.account(a)tbspace.de>
Gerrit-Reviewer: roox <mardnh(a)gmx.de>
Gerrit-Reviewer: tnt <tnt(a)246tNt.com>
Gerrit-Attention: manawyrm <osmocom.account(a)tbspace.de>
Gerrit-Attention: roox <mardnh(a)gmx.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Wed, 20 Apr 2022 12:34:06 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Attention is currently required from: laforge.
fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/27778 )
Change subject: osmo-bts-trx: amr_loop: do not miss C/I samples
......................................................................
Patch Set 2:
(1 comment)
File src/osmo-bts-trx/amr_loop.c:
https://gerrit.osmocom.org/c/osmo-bts/+/27778/comment/fbb624fa_a65b29b1
PS1, Line 53: if (mi != chan_state->dl_cmr)
> I would expect the C/I ratio to stay more or less the same, no matter which codec mode is used. […]
This is a perfectly valid point. I'll add this to the commit message. Indeed, C/I is calculated by checking the training sequence bits, i.e. the burst midamble, which remains the same regardless of the current codec rate.
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/27778
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: Ieb5473ead7200f652b5d0e339e4e252d6567482d
Gerrit-Change-Number: 27778
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Wed, 20 Apr 2022 12:23:23 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
fixeria has submitted this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/27774 )
Change subject: osmo-bts-trx: amr_loop: improve logging in trx_loop_amr_input()
......................................................................
osmo-bts-trx: amr_loop: improve logging in trx_loop_amr_input()
Currently we're logging AMR mode *indexes*, not the actual modes.
Let's make it cleaner for the user by logging both mode and index.
Change-Id: I4feb3a3823799a290a50a48275e45f3331874d1a
Related: SYS#5917, OS#4984
---
M src/osmo-bts-trx/amr_loop.c
1 file changed, 12 insertions(+), 11 deletions(-)
Approvals:
laforge: Looks good to me, approved
pespin: Looks good to me, but someone else must approve
Jenkins Builder: Verified
diff --git a/src/osmo-bts-trx/amr_loop.c b/src/osmo-bts-trx/amr_loop.c
index 5793d03..90b156c 100644
--- a/src/osmo-bts-trx/amr_loop.c
+++ b/src/osmo-bts-trx/amr_loop.c
@@ -37,6 +37,7 @@
{
const struct gsm_lchan *lchan = chan_state->lchan;
const struct amr_multirate_conf *cfg = &lchan->tch.amr_mr;
+ const uint8_t mi = chan_state->ul_ft; /* mode index 0..3 */
int lqual_cb = meas_set->ci_cb; /* cB (centibel) */
/* check if loop is enabled */
@@ -44,7 +45,7 @@
return;
/* wait for MS to use the requested codec */
- if (chan_state->ul_ft != chan_state->dl_cmr)
+ if (mi != chan_state->dl_cmr)
return;
/* count per-block C/I samples for further averaging */
@@ -64,36 +65,36 @@
lqual_cb = chan_state->lqual_cb_sum / chan_state->lqual_cb_num;
LOGPLCHAN(lchan, DLOOP, LOGL_DEBUG, "AMR link quality (C/I) is %d cB, "
- "codec mode=%d\n", lqual_cb, chan_state->ul_ft);
+ "codec mode[%u]=%u\n", lqual_cb, mi, cfg->mode[mi].mode);
/* reset the link quality measurements */
chan_state->lqual_cb_num = 0;
chan_state->lqual_cb_sum = 0;
- if (chan_state->dl_cmr > 0) {
+ if (mi > 0) {
/* The threshold/hysteresis is in 0.5 dB steps, convert to cB:
* 1dB is 10cB, so 0.5dB is 5cB - this is why we multiply by 5. */
- const int thresh_lower_cb = cfg->mode[chan_state->dl_cmr - 1].threshold * 5;
+ const int thresh_lower_cb = cfg->mode[mi - 1].threshold * 5;
/* Degrade if the link quality is below THR_MX_Dn(i - 1) */
if (lqual_cb < thresh_lower_cb) {
LOGPLCHAN(lchan, DLOOP, LOGL_INFO, "Degrading AMR codec mode: "
- "%d -> %d due to link quality %d cB < THR_MX_Dn=%d cB\n",
- chan_state->dl_cmr, chan_state->dl_cmr - 1,
+ "[%u]=%u -> [%u]=%u due to link quality %d cB < THR_MX_Dn=%d cB\n",
+ mi, cfg->mode[mi].mode, mi - 1, cfg->mode[mi - 1].mode,
lqual_cb, thresh_lower_cb);
chan_state->dl_cmr--;
}
- } else if (chan_state->dl_cmr < chan_state->codecs - 1) {
+ } else if (mi < chan_state->codecs - 1) {
/* The threshold/hysteresis is in 0.5 dB steps, convert to cB:
* 1dB is 10cB, so 0.5dB is 5cB - this is why we multiply by 5. */
- const int thresh_upper_cb = cfg->mode[chan_state->dl_cmr].threshold * 5 \
- + cfg->mode[chan_state->dl_cmr].hysteresis * 5;
+ const int thresh_upper_cb = cfg->mode[mi].threshold * 5 \
+ + cfg->mode[mi].hysteresis * 5;
/* Upgrade if the link quality is above THR_MX_Up(i) */
if (lqual_cb > thresh_upper_cb) {
LOGPLCHAN(lchan, DLOOP, LOGL_INFO, "Upgrading AMR codec mode: "
- "%d -> %d due to link quality %d cB > THR_MX_Up=%d cB\n",
- chan_state->dl_cmr, chan_state->dl_cmr + 1,
+ "[%u]=%u -> [%u]=%u due to link quality %d cB > THR_MX_Up=%d cB\n",
+ mi, cfg->mode[mi].mode, mi + 1, cfg->mode[mi + 1].mode,
lqual_cb, thresh_upper_cb);
chan_state->dl_cmr++;
}
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/27774
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I4feb3a3823799a290a50a48275e45f3331874d1a
Gerrit-Change-Number: 27774
Gerrit-PatchSet: 3
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: merged
Attention is currently required from: laforge.
tnt has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-e1d/+/27837 )
Change subject: octoi: slip frames if RIFO runs empty in IP->E1 direction
......................................................................
Patch Set 2:
(1 comment)
This change is ready for review.
Patchset:
PS2:
I'd just drop this TBH ...
Disconnect seems like a better approach as you re-prime everything.
And really this should also never happen. Why is still does is probably some bug or mis-config we haven't traced yet and fixing that should be the proper solution.
--
To view, visit https://gerrit.osmocom.org/c/osmo-e1d/+/27837
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-e1d
Gerrit-Branch: master
Gerrit-Change-Id: Ic2a714fedb9a0698c17ef22447904a803c26ebfc
Gerrit-Change-Number: 27837
Gerrit-PatchSet: 2
Gerrit-Owner: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: manawyrm <osmocom.account(a)tbspace.de>
Gerrit-Reviewer: roox <mardnh(a)gmx.de>
Gerrit-Reviewer: tnt <tnt(a)246tNt.com>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Comment-Date: Wed, 20 Apr 2022 11:52:47 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment