[L] Change in osmo-bts[master]: CSD: implement half-rate modes correctly

Attention is currently required from: fixeria, pespin. falconia has posted comments on this change by falconia. ( https://gerrit.osmocom.org/c/osmo-bts/+/38553?usp=email ) Change subject: CSD: implement half-rate modes correctly ...................................................................... Patch Set 2: (4 comments) Commit Message: https://gerrit.osmocom.org/c/osmo-bts/+/38553/comment/9cc638f0_5f775bca?usp… : PS2, Line 26: by emitting two RTP packets : directly back-to-back for UL, and pulling two RTP packets at a time : from the Rx jitter buffer at the needed times for DL. You are correct: if we were implementing a new E1 BTS, there would be no other way to handle the present issue except by buffering the bits and emitting them at the TDM-controlled rate. However, E1 BTS do similar buffering at all times, not just in this one corner case. Consider what happens with all other TCH types besides CSD-HR, i.e., consider CSD-FR and all speech modes. For those "traditional" TCH, osmo-bts (all models, not just trx) emits an RTP packet statistically every 20 ms - but it is not perfect 20 ms, it has TDMA jitter, with the actual time deltas between emitted RTP packets being TDMA*4 or TDMA*5 per multiframe structure. E1 BTS are different in this regard: their internal buffering fully conceals TDMA jitter from the external TDM connection, and the timing of TRAU frames on Abis is perfect 20 ms for each frame. This aspect of osmo-bts (the fact that we normally expose our TDMA jitter in RTP output) is the main reason why I felt it would make no sense to try to replicate the exact behavior of E1 BTS here. Suppose we wanted to artificially delay the second half of CSD-HR frames by 20 ms to make our RTP output more E1-like - would it be a delay of exactly 20 ms per Linux system clock? Or would be 4 TDMA frames? Or 5 TDMA frames? Exactly which FNs would produce an artificial delay of 4 vs 5 frames? There won't be an answer in the specs as we talking about purely artificial delay here. So why delay at all, why not simply emit both packets right away... File src/common/l1sap.c: https://gerrit.osmocom.org/c/osmo-bts/+/38553/comment/f0babc20_9d4822b7?usp… : PS2, Line 1539: 2 Will do. https://gerrit.osmocom.org/c/osmo-bts/+/38553/comment/938ed2ec_7f9c834d?usp… : PS2, Line 1556: else Will do. https://gerrit.osmocom.org/c/osmo-bts/+/38553/comment/3e3f65cd_38cd9886?usp… : PS2, Line 2098: switch (lchan->tch_mode) { Not sure if I agree - let me handle all other feedback first, then I'll get back to this one. -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/38553?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email Gerrit-MessageType: comment Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: Ib35e910df263743cd243f51fb0bd6551ddfcf4c5 Gerrit-Change-Number: 38553 Gerrit-PatchSet: 2 Gerrit-Owner: falconia <falcon(a)freecalypso.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Sun, 27 Oct 2024 22:06:21 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>