Commit Graph

12 Commits

Author SHA1 Message Date
Pau Espin 9573ccbe2b vty: Print Osmux CID on lchans using Osmux
Related: SYS#5987
Change-Id: I6829949c888c0bcd989311219e10330bc97b2152
2022-09-21 19:29:11 +02:00
Pau Espin 2c4f32b19b cosmetic: vty: Fix formatting of if-else brackets
Change-Id: I7210616bc293913e5efec14eb52aeafb37f1244f
2022-09-21 19:05:30 +02:00
Pau Espin 3d0fbe387f split lchan specific defines and code to its own file
It is really difficult right now to find out where all the different
stuff relative to operation and lifecycle of an lchan is. Let's move
everything to its own file to have all the related defines and logic
together.

Change-Id: Idd855d126c43ac6576c5f3ba7e0b8014127a65e1
2022-08-09 08:38:51 +00:00
Pau Espin 742bb99ed9 Use libosmocore available API to get value_list
This API has been available since 1.0.0, and we actually require
libosmocore >= 1.7.0 nowadays, so it's totally fine using the
libosmocore API and drops the local duplicate.

Change-Id: I95c59b31cf1b08e1d513b589ef386d2dd55f09a2
2022-08-09 08:38:51 +00:00
Philipp Maier 842592c529 bts_trx_vty: prefix bb_trxc mo with [Virtual] for ericsson BTS
The OM2000 model does not have a separate bb_transc MO, however for
compatibilty reasons we have a virtual MO that just mirrors the state of
the TRX mo. We should mark it as [Virtual] in show trx to reflect this
to the user.

Change-Id: I0f5501f6fbc7ce6d5457676b16c7f93f70db5763
Related: OS#5101
2022-08-08 20:09:15 +00:00
Vadim Yanitskiy 1f6a0decee bts_chan_load(): also calculate per-TRX channel load
This is required for the upcoming dynamic channel allocation mode.

Change-Id: I220145238c23135f7e68ca2d474764312ffb66c5
Related: SYS#5460
2022-06-22 05:49:20 +07:00
Michael Iedema a7628d9cf0 stats: new trackers for lchan life duration (v2)
This patch adds two stats which track cummulative lchan lifetime by
type TCH and SDCCH. These new counters will accomplish two things:

1) Provide a glanceable way to see if lchan durations look healthy. When
examining a site, short-lived (<5s) and long-lived (>30s) TCH lchans
are difficult to tell apart. If we only see short-lived TCH lchans,
there is most likely an RF or signaling problem to investigate. This
new counter will expose channel ages in the VTY output

2) Provide a more accurate count for Erlangs per site. Currently, we
are basing Erlangs on active TCH channel counts per stats period. This
method skews high very quickly. Each active TCH in that period
translates into the full 10s of activity. This counter should improve
accuracy by two orders of magnitude.

Change-Id: Ie3771233ecbd4bc24a24fb22c1064a18e7b8b2b0
2022-05-23 02:20:12 -07:00
Pau Espin fa3e40e454 Revert "stats: new trackers for lchan life duration"
This reverts commit 5e2ac29703.

This patch was found to be a troublemaker regarding osmo-bsc
performance, since it's scheduling one timer every 100ms for each
channel. On a BSC with dozens of BTS, each with several TRX, this ends
up in a huge amount of timers scheduled in a tight timeframe, which ends
up in osmo-bsc spending CPU time getting in and out of the poll() main
loop.

Related: SYS#5922
Change-Id: Ibd5123e7f04ae8f4eb8f08b63525527f526f0b2c
2022-05-12 12:49:45 +02:00
Michael Iedema 5e2ac29703 stats: new trackers for lchan life duration
This patch adds two stats which track cummulative lchan lifetime by
type TCH and SDCCH. These new counters will accomplish two things:

1) Provide a glanceable way to see if lchan durations look healthy. When
examining a site, short-lived (<5s) and long-lived (>30s) TCH lchans
are difficult to tell apart. If we only see short-lived TCH lchans,
there is most likely an RF or signaling problem to investigate. This
new counter will expose channel ages in the VTY output

2) Provide a more accurate count for Erlangs per site. Currently, we
are basing Erlangs on active TCH channel counts per stats period. This
method skews high very quickly. Each active TCH in that period
translates into the full 10s of activity. This counter should improve
accuracy by two orders of magnitude.

Change-Id: I1b0670c47cb5e0b7776eda89d1e71545ba0e3347
2022-05-03 11:03:28 +00:00
Oliver Smith 159246f94f Check VTY config against features reported by BTS
* Don't copy features for osmo-bts and nanobts initially, wait until
  BTS reported its features
* Checks for BTS features in VTY cmds: pass if features are not known
  (not yet reported by the BTS), fail if the feature is missing
* Once BTS reports its features, check relevant VTY config parts again

Related: SYS#5922, OS#5538
Change-Id: I7fca42a39a4bc98a6ea8b9cfab28c4bad3a6a0aa
2022-05-02 15:21:28 +02:00
Oliver Smith 2d818b9f2e Always use reported features if available
Instead of sometimes checking against hardcoded BTS model features, and
sometimes against features reported at runtime (which only some BTS
models do):
* copy the hardcoded BTS model features to BTS features initially
* do all checks against BTS features

Related: SYS#5922, OS#5538
Change-Id: Idf2d933aa8b03b1f708e56a08707fe6c620a97aa
2022-04-26 12:06:47 +00:00
Pau Espin c8edaad0bf Split bts_vty.c creating bts_trx_vty.c
Change-Id: I15ec8f71a5d31915162cb3ad75ea77e934fa4887
2021-07-23 13:35:04 +02:00