Since there's now a rate counter, we can drop log level for those events
which can be bursty and hence print lots of output in short periods of
time, which may affect performance. This way setting them to INFO it's
enough to avoid getting them in stderr unless explicitly configured by
the user (for instance to debug stuff), while still allowing a good
enough level to be enabled for other targets such as gsmtap.
Related: OS#4679
Change-Id: I000f7112e35ac68d3d922444f78468b1ea74cbba
This way i most usual rate_ctr related internal logging is disabled by default
(notice), and it can b eeasily enabled by switching the category to info
or debug.
Change-Id: Id6c36432da7e7ce673c585bcae6772a695028ec5
This ones together with rate counters already available in lower layers
allows to understand better the source of the problem with stalled tx
bursts.
Change-Id: Ia34f7e7d780ad1e12f24638a07f05fe91f2afea5
This allows checking if there's timing issues on the downlink side
between osmo-bts-trx and osmo-trx. This counter is useful to find
information about osmo-bts-trx 'fn-advance' setting, since this counter
basically counts if burstrs from it arrived too late to osmo-trx.
Change-Id: Id6df00da81f6d6884f4dddc5a2c4b354dca3af97
RadioInterface ones will be added in next commit, so let's differentiate
the structs required for each one.
Change-Id: Ib0e142a1dd4bedefdb4c5f15c34132da872c0975
For instance, use in VTY:
"ctr-error-threshold tx_underruns 5 per-second"
If the condition becomes true (eg 5 underruns happened in one sec), the
statement inside OSMO_MAX would become -1, but it was being handled as
an unsigned when doing the OSMO_MAX internal comparison. As a result,
OSMO_MAX((unsigned)-1, 1) was returning -1 (unsigned) stored in
threshold_timer_sched_secs which then became and int -1, which was
handled by osmo_timer_schedule as a 0, hence having an immediate
trigerring all the time.
While at it, make threshold_timer_sched_secs unsigned since it doesn't
make sense to have it as signed anyway.
Change-Id: I6ea3d64dff189a5bc924e72d846e02d50536a8ea
After discussion in [1] and further look at the code, it became obvios
rx_underrun events are not happening in general for any SDR (don't
exist), so let's drop that counter. Instead, add Tx Dropped Packet counters,
which were not accounted prior to this commit.
[1] bde55afd29
Change-Id: Iff1535c219a4695a511d383d7c4b06ef6eff959d
Take the chance to improve text with author, SPDX tag and fix incorrect
copyright dates.
Related: OS#3515
Change-Id: Ic745312ed07db205b1cdc0f2fa130000319354c5
osmo-trx will validate over time that those thresholds are not reached.
If they are reached, osmo-trx will die. As a result, osmo-bts-trx will
notice and will end up notifying the BSC about it (for instance because
it will also restart its process).
For instance:
"""
ctr-error-threshold rx_drop_events 2 minute
ctr-error-threshold rx_underruns 10 second
"""
In those cases above, osmo-trx will die if rate_ctr rx_drop_events went
to a value higher than 2 per minute, or it will die to if rx_underruns
went higher than 10 per second.
Change-Id: I4bcf44dbf064e2e86dfc3b8a2ad18fea76fbd51a
Introduce a unified implementation-agnostic interface for radioDevice to
signal SDR error counters to upper layers and manage them.
This patch only implements counters for osmo-trx-lms (other devices will
show all counters unchanged during time).
Sample use through VTY:
"""
OsmoTRX> show rate-counters
osmo-trx statistics 0:
device:rx_underruns: 0 (0/s 0/m 0/h 0/d) Number of Rx underruns
device:rx_overruns: 0 (0/s 0/m 0/h 0/d) Number of Rx overruns
device:tx_underruns: 0 (0/s 0/m 0/h 0/d) Number of Tx underruns
device:rx_drop_events: 4 (0/s 2/m 3/h 0/d) Number of times Rx samples were dropped by HW
device:rx_drop_samples: 513 (0/s 196/m 425/h 0/d) Number of Rx samples dropped by HW
"""
Change-Id: I78b158141697e5714d04db8b9ccc96f31f34f439
Vadim Yanitskiy
Pau Espin
Martin Hauke