- gerrit-log - lists.osmocom.org

Change in osmo-bts[master]: osmo-bts-trx: check if scheduling of [dummy] FACCH/H is allowed
by pespin 20 Apr '22

20 Apr '22

Attention is currently required from: laforge, fixeria. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/27836 ) Change subject: osmo-bts-trx: check if scheduling of [dummy] FACCH/H is allowed ...................................................................... Patch Set 2: (1 comment) File src/osmo-bts-trx/sched_lchan_tchh.c: https://gerrit.osmocom.org/c/osmo-bts/+/27836/comment/9157e127_f0e7a0f8 PS2, Line 415: goto send_burst; /* send garbage */ Thanks, for the explanation, it's clearer now. I still lack some better definition of what "garbage" is in this scenario. Is it uninitialized memory? zeroed memory? padding? This should be clarified. -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/27836 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I6f8af140a6ccf3d5fd7b98f6cb5c18e2c5e2f61b Gerrit-Change-Number: 27836 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Wed, 20 Apr 2022 09:58:15 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Change in osmo-bts[master]: osmo-bts-trx: tx_tchh_fn(): make handling of FACCH/H cleaner
by pespin 20 Apr '22

20 Apr '22

Attention is currently required from: laforge, fixeria. pespin has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/27835 ) Change subject: osmo-bts-trx: tx_tchh_fn(): make handling of FACCH/H cleaner ...................................................................... Patch Set 1: (1 comment) File src/osmo-bts-trx/sched_lchan_tchh.c: https://gerrit.osmocom.org/c/osmo-bts/+/27835/comment/97acb6bf_d67a682f PS1, Line 395: msgb_free(msg); /* steal 2nd speech frame */ > Ack, I can update the comment if you find it cleaner. yes please. when I read "steal" here I get confused because it looks like it is planned to be used somewhere/somehow else. -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/27835 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: Ib923b8f5cc1063e9fc18acd2bdd003fd09f4b70f Gerrit-Change-Number: 27835 Gerrit-PatchSet: 1 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Wed, 20 Apr 2022 09:53:50 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: comment

1 0

Change in osmo-bts[master]: osmo-bts-trx: use C/I in the AMR link adaptation loop
by osmith 20 Apr '22

20 Apr '22

Attention is currently required from: fixeria, pespin, dexter. osmith has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/27758 ) Change subject: osmo-bts-trx: use C/I in the AMR link adaptation loop ...................................................................... Patch Set 5: (2 comments) File src/osmo-bts-trx/amr_loop.c: https://gerrit.osmocom.org/c/osmo-bts/+/27758/comment/0d7fa69b_3bdab3df PS5, Line 76: const int thresh_lower_cb = cfg->mode[chan_state->dl_cmr - 1].threshold * 5; is the hysteresis missing here (see thresh_upper_cb)? https://gerrit.osmocom.org/c/osmo-bts/+/27758/comment/68660b10_06858b55 PS5, Line 86: } else if (chan_state->dl_cmr < chan_state->codecs - 1) { just to be sure, is the "else if" here intentional, instead of just "if"? given that dl_cmr is an uint8_t, it looks like with this logic it can only alternate between 0 and 1. -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/27758 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: Ide84bf864f56020c0265cfb9731615d4f7bad7f5 Gerrit-Change-Number: 27758 Gerrit-PatchSet: 5 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: dexter <pmaier(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: osmith <osmith(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: dexter <pmaier(a)sysmocom.de> Gerrit-Comment-Date: Wed, 20 Apr 2022 09:18:02 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Change in dahdi-linux[master]: icE1usb: Fix inverted logic for clock timing source
by manawyrm 20 Apr '22

20 Apr '22

Attention is currently required from: laforge. manawyrm has posted comments on this change. ( https://gerrit.osmocom.org/c/dahdi-linux/+/27838 ) Change subject: icE1usb: Fix inverted logic for clock timing source ...................................................................... Patch Set 1: (1 comment) File drivers/dahdi/icE1usb/icE1usb.c: https://gerrit.osmocom.org/c/dahdi-linux/+/27838/comment/45d2edbc_60583764 PS1, Line 694: ieu->cfg.tx.timing = ICE1USB_TX_TIME_SRC_REMITE; REMOTE :) -- To view, visit https://gerrit.osmocom.org/c/dahdi-linux/+/27838 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: dahdi-linux Gerrit-Branch: master Gerrit-Change-Id: If35a5a52c094129c342d0f658f496b488d1826ad Gerrit-Change-Number: 27838 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: manawyrm <osmocom.account(a)tbspace.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Comment-Date: Wed, 20 Apr 2022 09:11:08 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Gerrit-MessageType: comment

1 0

Change in dahdi-linux[master]: icE1usb: Fix inverted logic for clock timing source
by laforge 20 Apr '22

20 Apr '22

laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/dahdi-linux/+/27838 ) Change subject: icE1usb: Fix inverted logic for clock timing source ...................................................................... icE1usb: Fix inverted logic for clock timing source The 'struct dahdi_lineconfig.sync' parameter originates from the 'timing' field of system.conf. dahdi_cfg passes it via the SPANCONFIG ioctl into the kernel. The DAHDI docs say: > source of the master clock. If you choose 0, the port will never > be used as a source of timing. This is appropriate when you know the > far end should always be a slave to you. So if '0' we should use the local clock, and if > 0, the recovered remote clock. Thanks to Christoph Lauter for pointing this out. Change-Id: If35a5a52c094129c342d0f658f496b488d1826ad --- M drivers/dahdi/icE1usb/icE1usb.c 1 file changed, 2 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/dahdi-linux refs/changes/38/27838/1 diff --git a/drivers/dahdi/icE1usb/icE1usb.c b/drivers/dahdi/icE1usb/icE1usb.c index e829b2d..04a7b04 100644 --- a/drivers/dahdi/icE1usb/icE1usb.c +++ b/drivers/dahdi/icE1usb/icE1usb.c @@ -691,9 +691,9 @@ ieu->cfg.tx.mode = ICE1USB_TX_MODE_TS0; if (lc->sync > 0) - ieu->cfg.tx.timing = ICE1USB_TX_TIME_SRC_LOCAL; + ieu->cfg.tx.timing = ICE1USB_TX_TIME_SRC_REMITE; else - ieu->cfg.tx.timing = ICE1USB_TX_TIME_SRC_REMOTE; + ieu->cfg.tx.timing = ICE1USB_TX_TIME_SRC_LOCAL; /* (re-)set to sane defaults */ ieu->cfg.tx.ext_loopback = ICE1USB_TX_EXT_LOOPBACK_OFF; -- To view, visit https://gerrit.osmocom.org/c/dahdi-linux/+/27838 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: dahdi-linux Gerrit-Branch: master Gerrit-Change-Id: If35a5a52c094129c342d0f658f496b488d1826ad Gerrit-Change-Number: 27838 Gerrit-PatchSet: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-MessageType: newchange

1 0

Change in osmo-bts[master]: osmo-bts-trx: check if scheduling of [dummy] FACCH/H is allowed
by fixeria 20 Apr '22

20 Apr '22

Attention is currently required from: laforge, pespin. fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/27836 ) Change subject: osmo-bts-trx: check if scheduling of [dummy] FACCH/H is allowed ...................................................................... Patch Set 2: (1 comment) File src/osmo-bts-trx/sched_lchan_tchh.c: https://gerrit.osmocom.org/c/osmo-bts/+/27836/comment/1c1ccc9b_3eaf849b PS1, Line 414: if (!sched_tchh_dl_facch_map[br->fn % 26]) > How will that random garbage not also be detected as BER, too? Right, sending garbage will of course result in decoding errors on the MS side. So this patch does not guard against sporadic gaps in the Downlink TCH queue. However when tch_dl_dequeue() constantly yields nothing, e.g. when we end up with a codec mismatch, then this additional check saves us from starting misaligned FACCH/H transmission. If we start at a wrong TDMA offset, then all subsequent FACCH frames will be scheduled at wrong offsets and thus none of them will be decoded by the MS. We can of course improve this further by sending a cached SID frame instead of dummy FACCH, or sending a BFI if no SID was cached. But this is a topic for a separate patch. As I said, this is the best we can do for now. Better than sending a constant stream of misaligned FACCH. -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/27836 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I6f8af140a6ccf3d5fd7b98f6cb5c18e2c5e2f61b Gerrit-Change-Number: 27836 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 19 Apr 2022 22:47:19 +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

1 0

Change in osmo-e1d[master]: octoi: slip frames if RIFO runs empty in IP->E1 direction
by manawyrm 20 Apr '22

20 Apr '22

Attention is currently required from: roox, laforge, tnt. manawyrm 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 1: Code-Review-1 (1 comment) Patchset: PS1: Looking at the unit tests: ``` TEST: correct_order, starting at FN: 0 RIFO_IN(0000000000000000000000000000000000000000000000000000000000000000, 0)=0 RIFO_IN(0101010101010101010101010101010101010101010101010101010101010101, 1)=0 RIFO_IN(0202020202020202020202020202020202020202020202020202020202020202, 2)=0 RIFO_IN(0303030303030303030303030303030303030303030303030303030303030303, 3)=0 RIFO_IN(0404040404040404040404040404040404040404040404040404040404040404, 4)=0 RIFO_IN(0505050505050505050505050505050505050505050505050505050505050505, 5)=0 RIFO_IN(0606060606060606060606060606060606060606060606060606060606060606, 6)=0 RIFO_IN(0707070707070707070707070707070707070707070707070707070707070707, 7)=0 RIFO_IN(0808080808080808080808080808080808080808080808080808080808080808, 8)=0 RIFO_IN(0909090909090909090909090909090909090909090909090909090909090909, 9)=0 RIFO_OUT(0000000000000000000000000000000000000000000000000000000000000000)=0 RIFO_OUT(0101010101010101010101010101010101010101010101010101010101010101)=0 RIFO_OUT(0202020202020202020202020202020202020202020202020202020202020202)=0 RIFO_OUT(0303030303030303030303030303030303030303030303030303030303030303)=0 RIFO_OUT(0404040404040404040404040404040404040404040404040404040404040404)=0 RIFO_OUT(0505050505050505050505050505050505050505050505050505050505050505)=0 RIFO_OUT(0606060606060606060606060606060606060606060606060606060606060606)=0 RIFO_OUT(0707070707070707070707070707070707070707070707070707070707070707)=0 RIFO_OUT(0808080808080808080808080808080808080808080808080808080808080808)=0 RIFO_OUT(ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff)=-2 ``` This doesn't seem quite right? There are some other oddities in there. -- 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: 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: roox <mardnh(a)gmx.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: tnt <tnt(a)246tNt.com> Gerrit-Comment-Date: Tue, 19 Apr 2022 22:19:47 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 0

Change in osmo-bts[master]: osmo-bts-trx: check if scheduling of [dummy] FACCH/H is allowed
by laforge 20 Apr '22

20 Apr '22

Attention is currently required from: fixeria, pespin. laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/27836 ) Change subject: osmo-bts-trx: check if scheduling of [dummy] FACCH/H is allowed ...................................................................... Patch Set 2: (1 comment) File src/osmo-bts-trx/sched_lchan_tchh.c: https://gerrit.osmocom.org/c/osmo-bts/+/27836/comment/3cc5b332_27d1e2c3 PS1, Line 414: if (!sched_tchh_dl_facch_map[br->fn % 26]) > "Why first try to send dummy stuff" - where? This is not the case. […] How will that random garbage not also be detected as BER, too? -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/27836 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I6f8af140a6ccf3d5fd7b98f6cb5c18e2c5e2f61b Gerrit-Change-Number: 27836 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Tue, 19 Apr 2022 21:48:40 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: comment

1 0

Change in osmo-e1d[master]: octoi: slip frames if RIFO runs empty in IP->E1 direction
by laforge 20 Apr '22

20 Apr '22

laforge has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-e1d/+/27837 ) Change subject: octoi: slip frames if RIFO runs empty in IP->E1 direction ...................................................................... octoi: slip frames if RIFO runs empty in IP->E1 direction If the RIFO runs dry, it means somehow the E1 side is pulling frames faster than the IP side delivers them, and we need to insert/invent frames to re-gain sync and avoid a situation where we perpetually substitute frames. There is some danger in doing this as there are two situations where this can arise: 1) clock drift as explained above 2) packet loss > RIFO depth _without loss of sync_. In this case the clocks run at the same speed, but more 100ms of packets were lost. As we unconditionally assume '1', we damage our clock sync in '2'. This probably needs some additional analysis, i.e. look at the current rate of frames inserted into the FIFO to differentiate '1' from '2'. Change-Id: Ic2a714fedb9a0698c17ef22447904a803c26ebfc --- M src/octoi/e1oip.c M src/octoi/e1oip.h M src/octoi/frame_rifo.c M src/octoi/octoi.c 4 files changed, 19 insertions(+), 4 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-e1d refs/changes/37/27837/1 diff --git a/src/octoi/e1oip.c b/src/octoi/e1oip.c index 6a5a240..38a22b5 100644 --- a/src/octoi/e1oip.c +++ b/src/octoi/e1oip.c @@ -44,7 +44,8 @@ #include "e1oip.h" static const struct rate_ctr_desc iline_ctr_description[] = { - [LINE_CTR_E1oIP_UNDERRUN] = { "e1oip:underrun", "Frames missing/substituted in IP->E1 direction"}, + [LINE_CTR_E1oIP_UNDERRUN] = { "e1oip:underrun", "Frames underrun / slipped in IP->E1 direction"}, + [LINE_CTR_E1oIP_SUBSTITUTED] = { "e1oip:substituted", "Frames substituted in IP->E1 direction"}, [LINE_CTR_E1oIP_OVERFLOW] = { "e1oip:overflow", "Frames overflowed in IP->E1 direction"}, [LINE_CTR_E1oIP_RX_OUT_OF_ORDER] = { "e1oip:rx:pkt_out_of_order", "Packets out-of-order in IP->E1 direction"}, [LINE_CTR_E1oIP_RX_OUT_OF_WIN] = { "e1oip:rx:pkt_out_of_win", "Packets out-of-rx-window in IP->E1 direction"}, diff --git a/src/octoi/e1oip.h b/src/octoi/e1oip.h index 1a184d2..c0d3ed3 100644 --- a/src/octoi/e1oip.h +++ b/src/octoi/e1oip.h @@ -15,6 +15,7 @@ enum e1oip_line_ctr { LINE_CTR_E1oIP_UNDERRUN, + LINE_CTR_E1oIP_SUBSTITUTED, LINE_CTR_E1oIP_OVERFLOW, LINE_CTR_E1oIP_RX_OUT_OF_ORDER, LINE_CTR_E1oIP_RX_OUT_OF_WIN, diff --git a/src/octoi/frame_rifo.c b/src/octoi/frame_rifo.c index 94758e9..effe78d 100644 --- a/src/octoi/frame_rifo.c +++ b/src/octoi/frame_rifo.c @@ -131,13 +131,22 @@ /*! pull one frames out of the RIFO. * \param rifo The RIFO from which we want to pull frames * \param out Caller-allocated output buffer - * \returns 0 on success; -1 on error (no frame available) */ + * \returns 0 on success; -1 if no frame available; -2 if RIFO depth == 0 */ int frame_rifo_out(struct frame_rifo *rifo, uint8_t *out) { uint32_t next_out_bucket = (rifo->next_out - rifo->buf) / BYTES_PER_FRAME; bool bucket_bit = bucket_bit_get(rifo, next_out_bucket); int rc = 0; + if (frame_rifo_depth(rifo) == 0) { + /* if we don't have any RIFO depth at all, our jitter buffer has + * run empty and most likely there is some fundamental clock sync problem + * somewhere. In order to prevent perpetual substitution of frames from + * now onwards, we slip/insert one frame here by _not_ advancing next_out + * or next_out_fn and telling the caller to insert a frame */ + return -2; + } + if (!bucket_bit) { /* caller is supposed to copy/duplicate previous frame */ rc = -1; diff --git a/src/octoi/octoi.c b/src/octoi/octoi.c index 8585f0d..5f4c2f9 100644 --- a/src/octoi/octoi.c +++ b/src/octoi/octoi.c @@ -127,10 +127,14 @@ for (int i = 0; i < fts; i++) { uint8_t *cur = buf + BYTES_PER_FRAME*i; rc = frame_rifo_out(&iline->e1t.rifo, cur); - if (rc < 0) { - iline_ctr_add(iline, LINE_CTR_E1oIP_UNDERRUN, 1); + if (rc == -1) { + iline_ctr_add(iline, LINE_CTR_E1oIP_SUBSTITUTED, 1); /* substitute with last received frame */ memcpy(cur, iline->e1t.last_frame, BYTES_PER_FRAME); + } else if (rc == -2) { + iline_ctr_add(iline, LINE_CTR_E1oIP_UNDERRUN, 1); + /* substitute with all-FF frame */ + memset(cur, 0xff, BYTES_PER_FRAME); } } iline_stat_set(iline, LINE_STAT_E1oIP_E1T_FIFO, frame_rifo_depth(&iline->e1t.rifo)); -- 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: 1 Gerrit-Owner: laforge <laforge(a)osmocom.org> Gerrit-MessageType: newchange

1 0

Change in osmo-bts[master]: osmo-bts-trx: check if scheduling of [dummy] FACCH/H is allowed
by fixeria 20 Apr '22

20 Apr '22

Attention is currently required from: pespin. Hello Jenkins Builder, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-bts/+/27836 to look at the new patch set (#2). Change subject: osmo-bts-trx: check if scheduling of [dummy] FACCH/H is allowed ...................................................................... osmo-bts-trx: check if scheduling of [dummy] FACCH/H is allowed Currently (without this patch) if tch_dl_dequeue() yields nothing we're scheduling dummy FACCH/H *regardless* if it's permitted to start at the given TDMA FN or not. This may result in misaligned FACCH transmission, so the MS will not able to decode anything and will report BER>0. With this patch applied we a) schedule FACCH if it's allowed to start at the current TDMA FN; b) send whatever was in the burst buffer (garbage) if FACCH/H is not permitted. This is the best we can do without introducing additional complexity. Ideally the upper layers should guarantee that the queue is never empty, but currently this is not the case. Change-Id: I6f8af140a6ccf3d5fd7b98f6cb5c18e2c5e2f61b Related: SYS#5919, OS#4823 --- M src/common/scheduler.c M src/osmo-bts-trx/sched_lchan_tchh.c 2 files changed, 9 insertions(+), 1 deletion(-) git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/36/27836/2 -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/27836 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I6f8af140a6ccf3d5fd7b98f6cb5c18e2c5e2f61b Gerrit-Change-Number: 27836 Gerrit-PatchSet: 2 Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: newpatchset

1 0

2026

2025

2024

2023

2022

gerrit-log