This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
ipse gerrit-no-reply at lists.osmocom.orgipse has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/15807 ) Change subject: osmo-bts-trx/scheduler: refactor Uplink measurement processing ...................................................................... Patch Set 3: Vadim, I think your idea is good, just implementation is suboptimal, which is solvable. Let's see what the options are. > > If that's because of each burst affecting two frames [...] > > 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). > > > why not just have an avg counter per frame and add values to them accordingly? > > Because a) we allocate a frame (actually, a L1SAP primitive) _after_ decoding of bursts, not before; Can we pass the values along until the frame structure is allocated? > b) before decoding, we don't know whether this is a FACCH or a TCH frame. We know this by looking at stealing bits which can be done before decoding. Not sure if this is helpful without looking deep into the code. > > If there is something I missed why the above can't be done and we do need to store values [...] > > 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. Not sure I follow you here. Why a different interleaving period prevents us from calculating the average? > > 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? > > 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. First of all, moving a few contiguous bytes is much faster than allocating dynamic memory. Secondly, there are other data structures that could be used - e.g. circular buffers. Given that we know we don't need more than 8 historical points, implementing a circular buffer logic should be quite simple and require no memory allocation. -- To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/15807 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-bts Gerrit-Branch: master Gerrit-Change-Id: I6bc511223069f66b49109d3267bee7bd89585713 Gerrit-Change-Number: 15807 Gerrit-PatchSet: 3 Gerrit-Owner: fixeria <axilirator at gmail.com> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <axilirator at gmail.com> Gerrit-Reviewer: ipse <Alexander.Chemeris at gmail.com> Gerrit-Reviewer: laforge <laforge at osmocom.org> Gerrit-Reviewer: pespin <pespin at sysmocom.de> Gerrit-Comment-Date: Mon, 21 Oct 2019 17:05:50 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: No Gerrit-MessageType: comment -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20191021/a81569b3/attachment.htm>