Change in osmo-bsc[master]: hodec2: fix congestion oscillation bug

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/.

neels gerrit-no-reply at lists.osmocom.org
Wed Jan 6 07:44:08 UTC 2021


Hello Jenkins Builder, 

I'd like you to reexamine a change. Please visit

    https://gerrit.osmocom.org/c/osmo-bsc/+/21989

to look at the new patch set (#2).

Change subject: hodec2: fix congestion oscillation bug
......................................................................

hodec2: fix congestion oscillation bug

When evenly distributing congestion across cells, count the number of
occupied lchans surpassing congestion, and not the overall number of
free lchans -- which disregards congestion thresholds.

Fix the bug shown by test_congestion_no_oscillation.ho_vty added in
Idf88b4cf3d2f92f5560d73dae9e59af39d0494c0.

An example to illustrate what this is about:

Cell A has min-free-slots 2, and has 1 slot remaining free.
Cell B has min-free-slots 4, and has 2 slots remaining free.

If we decide where to place another lchan by counting congested lchans,
as implemented in this patch:
- Another lchan added, cell A ends up with a congestion count of 2: two
  more lchans in use than "allowed".
- Cell B ends up with a congestion count of 3, which is worse than 2.
We decide that cell A should receive the additional lchan, because it
will then have a lower congestion count.  However, that makes cell A
completely occupied, while cell B has two lchans remaining free.

There are two alternative fix variants in consideration:
- count the number of free lchans, but only after reaching congestion.
- calculate the percentage of load surpassing congestion.

When using percentage of remaining lchans, we would see that if cell A
receives another lchan, it would be 100% loaded above its congestion
threshold (2 of 2 remaining lchans in use), but cell B would only be 75%
loaded above its treshold (3 of 4 remaining lchans in use).  So a
percentage comparison would place the next lchan in cell B, leaving the
last lchan of cell A free.

Another option would be to count the number of remaining free lchans
(after the congestion threshold is surpassed), instead of the used ones
above the congestion threshold. But then, as soon as all cells are
congested, configuring different thresholds would no longer have an
effect. I would no longer be able to configure a particular cell to
remain more free than others: once congested, only that cell would fill
up until it reaches the same load as the other cells.

In the field, where all cells likely have the same min-free-slots
settings, this entire consideration is moot, because congestion counts
correspond 1:1 to percentage between all cells and also 1:1 to remaining
free slots. However, when looking at distribution across TCH/F and
TCH/H, it is quite likely that min-free-slots settings differ for TCH/F
and TCH/H, so this is in fact a thing to consider even for identically
configured cells.

Related: SYS#5259
Change-Id: Icb373dc6bfc9819446db5e96f71921781fe2026d
---
M src/osmo-bsc/handover_decision_2.c
M tests/handover/test_congestion_no_oscillation.ho_vty
M tests/handover/test_congestion_no_oscillation2.ho_vty
3 files changed, 11 insertions(+), 30 deletions(-)


  git pull ssh://gerrit.osmocom.org:29418/osmo-bsc refs/changes/89/21989/2
-- 
To view, visit https://gerrit.osmocom.org/c/osmo-bsc/+/21989
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Change-Id: Icb373dc6bfc9819446db5e96f71921781fe2026d
Gerrit-Change-Number: 21989
Gerrit-PatchSet: 2
Gerrit-Owner: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210106/9acbe504/attachment.htm>


More information about the gerrit-log mailing list