https://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-11-09T12:28:38ZOpen Source Mobile CommunicationsOsmoPCU - Bug #1792: 2 MS tests: Issue with TS allocation for DL in PCUhttps://osmocom.org/issues/1792?journal_id=24222016-11-09T12:28:38Zarvind.sirsikar
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Stalled</i></li></ul><p>waiting for review feed back on Gerrit for</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/819/">https://gerrit.osmocom.org/#/c/819/</a></p> OsmoPCU - Bug #1792: 2 MS tests: Issue with TS allocation for DL in PCUhttps://osmocom.org/issues/1792?journal_id=26342016-12-16T10:13:19Zarvind.sirsikar
<ul></ul><p>Current PCU implementation aims at supporting "many MSs with lesser resources"compared to "giving all the resources to fewer MSs".</p>
<p>The patch <a class="external" href="https://gerrit.osmocom.org/#/c/819/">https://gerrit.osmocom.org/#/c/819/</a> tries to give same(rather max)resources to all the MSs. However it is applicable only for lab testing.</p>
<p>Moving this patch to abandoned state as of now. This patch can be merged if necessary for lab testing.</p> OsmoPCU - Bug #1792: 2 MS tests: Issue with TS allocation for DL in PCUhttps://osmocom.org/issues/1792?journal_id=26372016-12-16T11:57:14Zzecke
<ul></ul><p>What would it take to scale this? We should not have a flag that makes it look good in a lab with a a handful of phones while in practice we run into resource conflicts too early.</p> OsmoPCU - Bug #1792: 2 MS tests: Issue with TS allocation for DL in PCUhttps://osmocom.org/issues/1792?journal_id=50032017-08-15T17:40:46Zlaforge
<ul></ul> OsmoPCU - Bug #1792: 2 MS tests: Issue with TS allocation for DL in PCUhttps://osmocom.org/issues/1792?journal_id=50782017-08-17T06:53:20Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>arvind.sirsikar</i> to <i>4368</i></li></ul> OsmoPCU - Bug #1792: 2 MS tests: Issue with TS allocation for DL in PCUhttps://osmocom.org/issues/1792?journal_id=182012020-05-08T16:24:30Zpespin
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>New</i></li></ul><p>There's a test case in AllocTest showcasing this issue in function test_2_consecutive_dl_tbfs().</p>
<p>So once fixed the following assert should pass when checked against == 4:<br /><pre>
OSMO_ASSERT(numTs2 == 3);
</pre></p>
<p>See osmo-pcu.git commit e26ee01d56b4c4c2da6abc6b649cb765d5787b98 for more information.</p> OsmoPCU - Bug #1792: 2 MS tests: Issue with TS allocation for DL in PCUhttps://osmocom.org/issues/1792?journal_id=182552020-05-12T11:55:15Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>4368</i> to <i>pespin</i></li></ul> OsmoPCU - Bug #1792: 2 MS tests: Issue with TS allocation for DL in PCUhttps://osmocom.org/issues/1792?journal_id=213632021-02-19T18:04:15Zpespin
<ul></ul><p>I have been looking at this ticket for a while today, as well as <a class="external" href="https://gerrit.osmocom.org/#/c/819/">https://gerrit.osmocom.org/#/c/819/</a></p>
<p>So the topic here is about whether we want to provide more DL timeslots when allocating TBFs over time (hence more DL-bandwidth optimized), or whether we want to focus on allocating DL timeslots based on capacity penalty on the TRX.</p>
<p>I first tried applying the proposed patch, which basically comes to the following line change in find_multi_slots():<br /><pre>
- if (capacity <= max_capacity)
+ if (rx_window < max_dl_slots)
</pre></p>
<p>When applying the patch, some AllocTest tests allocating lots of TBF cleary drop from 101 expected allocated TBF to a really lower number (I don't remember right now, but something between 7 and 30) due to TFI/USF exhaustion. Given the amount of drop here, I don't think it makes sense to apply the patch, since it would hurt service when number of MS start to rise.</p>
<p>I started giving a try to some possible optimization, which doesn't fix the problem described in this ticket (reproduced in test_2_consecutive_dl_tbfs()), but may help improvidng DL bandwidth allocation in some cases (at the expence of lowering a bit the capacity, from 101->100 in current AllocTest):<br /><pre>
diff --git a/src/gprs_rlcmac_ts_alloc.cpp b/src/gprs_rlcmac_ts_alloc.cpp
index 5f0bcc5..5abd921 100644
--- a/src/gprs_rlcmac_ts_alloc.cpp
+++ b/src/gprs_rlcmac_ts_alloc.cpp
@@ -634,12 +634,17 @@ int find_multi_slots(struct gprs_rlcmac_trx *trx, uint8_t mslot_class, uint8_t *
capacity);
#endif
- if (capacity <= max_capacity)
+ if (capacity < max_capacity)
+ continue;
+ /* On same capacity, prefer higher DL window */
+ if (capacity == max_capacity &&
+ rx_window <= max_dl_slots)
continue;
</pre></p>
<p>I'm still not sure it really improves stuff in lots of cases though, so it's WIP.</p> OsmoPCU - Bug #1792: 2 MS tests: Issue with TS allocation for DL in PCUhttps://osmocom.org/issues/1792?journal_id=213802021-02-22T11:45:38Zpespin
<ul></ul><p>After looking more carefuly at the code aroudn the proposed patch, I noticed the proposal would be wrong afacit because it's comparing 2 bitmask. Instead, the counting of those bitmask should be used:</p>
<pre>
- if (capacity <= max_capacity)
+ rx_count = pcu_bitcount(rx_window);
+ tx_count = pcu_bitcount(tx_window);
+ if (rx_count < max_rx)
+ continue;
+ if (rx_count == max_rx && tx_count <= max_tx)
continue;
- max_capacity = capacity;
+ //max_capacity = capacity;
max_ul_slots = tx_window;
max_dl_slots = rx_window;
+ max_rx = rx_count;
+ max_tx = tx_count;
}
</pre>
<p>However, it seems to suffer from same issues described initialy. More slots maybe assigned to the X first TBFs, but TBF allocation will end up exhausted far too quickly. See for instance in AllocTest when running against this patch with gdb (32 in master's algo vs proposed change in this ticket):<br /><pre>
No USF available
Successfully allocated 7 UL TBFs, algorithm B class 10..10 (UL and DL)
Expected 32 TBFs (got 7), algorithm B class 10..10 (UL and DL)
Assert failed counter == expect_num /home/pespin/dev/sysmocom/git/osmo-pcu/tests/alloc/AllocTest.cpp:671
</pre></p> OsmoPCU - Bug #1792: 2 MS tests: Issue with TS allocation for DL in PCUhttps://osmocom.org/issues/1792?journal_id=213812021-02-22T12:14:22Zpespin
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Rejected</i></li></ul>I tried again writing a version of my own keeping best from both sides:
<ul>
<li>First of all, optimizing based on max capacity</li>
<li>On equal capacity, optimize based on DL num of slots (and on equal num of DL slots, then optimize on UL num of slots).</li>
</ul>
<p>See following changes:<br /><pre>
- if (capacity <= max_capacity)
+ if (capacity < max_capacity)
continue;
+ rx_count = pcu_bitcount(rx_window);
+ tx_count = pcu_bitcount(tx_window);
+ if (capacity == max_capacity && rx_count < max_rx)
+ continue;
+ if (capacity == max_capacity && rx_count == max_rx && tx_count <= max_tx)
+ continue;
+
+ if (capacity == max_capacity) {
+ LOGP(DRLCMAC, LOGL_NOTICE, "PESPIN: updating capcity=%d tx_window=%d rx_window=%d max_dl_slots=%d\n",
+ capacity, tx_window, rx_window, max_dl_slots);
+ }
max_capacity = capacity;
max_ul_slots = tx_window;
max_dl_slots = rx_window;
+ max_rx = rx_count;
+ max_tx = tx_count;
}
</pre></p>
<p>This time, results from exhaustion point of view look better than with original patch, but still the exhaustion of TBFs happens way too early (32 vs 21):<br /><pre>
Allocating UL TBF: MS_CLASS=10/0
No USF available
TBF(TFI=21 TLLI=0xffffffff DIR=DL STATE=RELEASING) free
Successfully allocated 21 UL TBFs, algorithm B class 10..10 (DL and UL)
Expected 32 TBFs (got 21), algorithm B class 10..10 (DL and UL)
Assert failed counter == expect_num /home/pespin/dev/sysmocom/git/osmo-pcu/tests/alloc/AllocTest.cpp:671
backtrace() returned 11 addresses
</pre></p>
<p>That's probably related to the fact that selecting bigger DL num of slots (eg 4 slots for a class 11 MS with 4 PDCH-enabled TRX) ends up allocating USFs on the first PDCHs timeslots always.</p>
<p>So I think it's proven that, based on the fact that we want to optimize in capacity (to avoid exhaustion), the current allocation algo is better than the proposed change in this ticket, at the expense of lossing some DL TS sometimes when allocating TBfs to an MS.</p>
<p>All in all, one can consider the current algo is more fair than the proposal here in the sense that it allows providing service (TBF allocation) to more MS, while the proposal here is more fair only for the set of MS which were provided service (before TBF allocation exhaustion occurs).</p>
<p>Hence, I reject the ticket.</p>