Commit Graph

6 Commits

Author SHA1 Message Date
Pau Espin 9ff25a3674 ACC: Support ACC ramping based on CPU Load
* Rearrange acc_ramp struct and API to allow other variables

* Move ACC ramp chan-load VTY cmds to an own node
Since we'll be adding more parameters and naming is already quite long,
let's move everything to an own node instead, to keep names smaller as
well as being able to identify them when we add CPU load checks.
Old commands can still be used but are marked as deprecated in favour of
new commands in the created node.

* Add new VTY nodes to configure ACC ramping based on CPU load.

Related: SYS#4939
Change-Id: I1930f5c3af34e648021ffdcd455e2c72821edbd8

WIP: cpuload

Change-Id: I2a74f5f695237d731db467924c1b6609eadce9a9
2021-04-29 18:44:36 +02:00
Pau Espin 88cef63e85 acc: Fix ACC rotate barring highest ACCs too quickly during wraparound
Expected steps (size=4):
6 7 8 9 -> 0 7 8 9 -> 0 1 8 9 -> 0 1 2 9 -> 0 1 2 3 -> 1 2 3 4 -> ...

Befre this patch, for size>2 we got:
6 7 8 9 -> 0 6 7 8 -> 0 1 6 7 -> 0 1 2 6 -> 0 1 2 3 -> 1 2 3 4 -> ...

Which means highest ACCs were barred during more time than others.

Change-Id: I03c298ecb29c4fc5f4c361773f2666588e423ffe
2020-08-27 14:05:14 +02:00
Pau Espin 1e5e7004dc Introduce support for ACC ramping during whole BTS life cycle
Prior to this patch, ACC ramping was only used to go 0->N in the
number of allowed ACCs during BTS startup. It could optionally
dynamically stretch or extend the ramping time based on channel load.

With this patch, ACC ramping is kept alive during the entire time the
BTS is active, and subset of allowed ACCs can now be incresed or
decreased based on channel load. A new VTY command
"access-control-class-ramping-chan-load" is added to configure a lower
and an upper threshold. Channel load under the low threshold will
potentially trigger an increment of the subset size of allowed ACCs,
while a channel load over the upper threshold will potentially trigger
the opposite (a decrease in size).
The time between checks is kept fixed per VTY command (reusing old
"access-control-class-ramping-step-size"), but the "dynamic" option
is deprecated and ignored from now on since it provides nothing valuable
in the new implementation, because the size always dynamically changes
based on channel load (configured thresholds).

Related: SYS#4912
Change-Id: Id17f947c92cdfc0eb9541a9bf066338169caaeb5
2020-07-31 09:56:46 +00:00
Harald Welte c4b25704f5 acc.c: Don't use C99 constructs, this breaks builds on Debian 8
[  160s] acc.c: In function 'get_highest_allowed_acc':
[  160s] acc.c:117:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
[  160s]   for (int i = 9; i >= 0; i--) {
[  160s]   ^
[  160s] acc.c:117:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
[  160s] acc.c: In function 'get_lowest_allowed_acc':
[  160s] acc.c:127:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
[  160s]   for (int i = 0; i < 10; i++) {
[  160s]   ^
[  160s] Makefile:617: recipe for target 'acc.o' failed

Change-Id: I03722854634b2d6d6f1abac7c7553762b5fc6890
2020-07-30 10:40:24 +02:00
Pau Espin deaa6fd624 Introduce support for ACC subset rotation
See updated documentation section in manuals/chapters/bts.adoc regarding
an explanation on how the system works.

Related: SYS#4911
Change-Id: I952c9eeae02809c7184078c655574ec817902e06
2020-07-29 20:09:47 +00:00
Pau Espin 02f2056ccf rename files acc_ramp.* -> acc.c*
With upcoming next commit, the file will contain far more code that
simply ramping, so rename it to be more generic.

Change-Id: I8c368ab87e264439dea4ccf556821a44664cdbb0
2020-07-20 16:21:59 +02:00