<p style="white-space: pre-wrap; word-wrap: break-word;">Hi Alexander,</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">Could you explain why the result is no correct?</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">because in the current code we merely pass measurements of the last burst to L1SAP, see:</p><p style="white-space: pre-wrap; word-wrap: break-word;">https://git.osmocom.org/osmo-bts/tree/src/osmo-bts-trx/scheduler_trx.c#n1228<br>https://git.osmocom.org/osmo-bts/tree/src/osmo-bts-trx/scheduler_trx.c#n1256</p><p style="white-space: pre-wrap; word-wrap: break-word;">https://git.osmocom.org/osmo-bts/tree/src/osmo-bts-trx/scheduler_trx.c#n1439<br>https://git.osmocom.org/osmo-bts/tree/src/osmo-bts-trx/scheduler_trx.c#n1468</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">If that's because of each burst affecting two frames [...]</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Exactly! A TCH/F or FACCH/F frame is interleaved over 8 consecutive bursts (228 even numbered bits of the first 4 bursts and 228 odd numbered bits of the last 4 bursts), a TCH/H (speech) frame is interleaved over 4 consecutive bursts (114 even numbered bits of the first 2 bursts and 114 odd numbered bits of the last 2 bursts), and a FACCH/H frame is interleaved over 6 consecutive bursts (114 even numbered bits of the first 2 bursts, all bits of the middle 2 bursts, and 114 odd numbered bits of the last 2 bursts).</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">why not just have an avg counter per frame and add values to them accordingly?</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Because a) we allocate a frame (actually, a L1SAP primitive) _after_ decoding of bursts, not before; b) before decoding, we don't know whether this is a FACCH or a TCH frame.</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">If there is something I missed why the above can't be done and we do need to store values [...]</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Averaging on the fly _could_ be implemented for TCH/F and FACCH/F by having two separate measurement buffers, but definitely not for TCH/H and FACCH/H because they have different interleaving periods.</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">why not use an array? We know that we need 8 values max, so why not allocate an array of 8 elements to avoid linked list operations?</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">We basically need a LIFO stack, so we push new measurements on top of it and remove old ones from the tail every time we decode a new frame. It should be possible to implement this using an array, so doing a lookup (i.e. just referencing by index) will be much faster, but then pushing a new set of measurements will be slower as we would need to shift the existing measurements right (copy arr[i] to arr[i + 1]) every time we receive a burst. Given that we're pushing new measurements much more often than we average them, I would not go for that. Alternatively, we could use a FIFO stack and always push to the end. Then we still would need to shift the measurements left (by copying arr[i] to arr[i - 1]) as soon as we decode a new frame.</p><p style="white-space: pre-wrap; word-wrap: break-word;">So I still think that traversing through a linked list is not that bad. And having the measurement history in general gives us a bonus: we can easily lookup TDMA frame number of the first burst instead of using ugly formulas or the block mapping tables from 3GPP 45.002. Also, I've got a few optimization ideas: 1) we can combine averaging and squashing into a single function, so that would be done in a single iteration; 2) TDMA frame number lookup can also be combined into the averaging function; 3) we can use a talloc pool, so malloc() will not be a problem anymore.</p><p><a href="https://gerrit.osmocom.org/c/osmo-bts/+/15807">View Change</a></p><ul style="list-style: none; padding: 0;"></ul><p>To view, visit <a href="https://gerrit.osmocom.org/c/osmo-bts/+/15807">change 15807</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/c/osmo-bts/+/15807"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: osmo-bts </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-Change-Id: I6bc511223069f66b49109d3267bee7bd89585713 </div>
<div style="display:none"> Gerrit-Change-Number: 15807 </div>
<div style="display:none"> Gerrit-PatchSet: 3 </div>
<div style="display:none"> Gerrit-Owner: fixeria <axilirator@gmail.com> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder </div>
<div style="display:none"> Gerrit-Reviewer: fixeria <axilirator@gmail.com> </div>
<div style="display:none"> Gerrit-Reviewer: ipse <Alexander.Chemeris@gmail.com> </div>
<div style="display:none"> Gerrit-Reviewer: laforge <laforge@osmocom.org> </div>
<div style="display:none"> Gerrit-Reviewer: pespin <pespin@sysmocom.de> </div>
<div style="display:none"> Gerrit-Comment-Date: Sun, 20 Oct 2019 17:52:37 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>
<div style="display:none"> Gerrit-Has-Labels: No </div>
<div style="display:none"> Gerrit-MessageType: comment </div>