Using the new libosmovty features allow for:
* Setting different cpu-affinity masks for each thread in the process,
both at startup through .cfg file as well as changing it at runtime.
* Unified VTY interface to change the scheduling policy of the process
inherited by all osmocom processes enabling the feature.
Depends: libosmocore.git Change-Id If76a4bd2cc7b3c7adf5d84790a944d78be70e10a
Depends: osmo-gsm-masnuals.git Change-Id Icd75769ef630c3fa985fc5e2154d5521689cdd3c
Related: SYS#4986
Change-Id: I3798603779b88ea37da03033cf7737a6e4751d6e
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
Add an enum containing each supported device type (LimeSDR-USB,
LimeSDR-Mini and LimeNet-Micro) plus "unknown", to leave some room for
yet-to-come devices to run with some generic parameters without
rebuilding osmo-trx.
Each device type is assigned a dev_desc structure, and all of them are
put in HashMap, similar to what's already done in UHDDevice.cpp.
Device type is infered from string provided by LMS_GetDeviceInfo(), as
it was already done before in several places. From now on, we only need
to parse the string once since we store the device type after first
during open time.
Later on, more fields will be moved to device-type specific structure,
such as Tx timing offset, clock rate, etc.
Change-Id: I7658615787c5bc41c365bab9c11733b701ac2ae5
Make sure old configs using "logging level lms <level>" are still accepted.
Initialization order of VTY componenets need to be resorted since newly
introduced command requires logging VTY node to be already setup
beforehand.
Change-Id: Ia195a74a62a8a3dd6267fb1359acaa5628208d8e
In the command line options time, filler table/filer burts settings
were a bit difficult to undertand because the number of one-letter
settings was limited. Now, with VTY configuration, there is no reason
to keep it so difficult.
Also, after the previous commit it was no longer posible to enable
random 8-PSK filler bursts. With this patch you can configure all
supported filler bursts in a simple and logical way.
Change-Id: I752eb2c1162d084e8769181f2fcd6c0877663448
The EGPRS switch in the VTY config enables 8-PSK burst detection on
uplink. Enabling it shouldn't turn on filler bursts.
Change-Id: I2786c768e038b769a80c8b78fe58cfa09eb322a9
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
Maximum number of carriers is fixed to 3 channels on a single
physical RF channel in multi-ARFCN mode. For some reason, it
was limited to 5.
Let's fix this, and also follow this limitation in the
following VTY command handlers:
- cfg_multi_arfcn_cmd,
- cfg_chan_cmd.
Change-Id: I66a1462f368458afd313ee6f0bc0abc496dde817
Since I838c21db29c54f1924dd478c2b34b46b70aab2cd we have both TS1
and TS2 synch. sequences, in addition to "default" TS0. Let's
finally introduce the VTY configuration parameter, that can
be used to toggle optional detection of both TS1 and TS2.
Note: we keep this optional because of potentially bad impact on
performance. There's no point in paying the performance penalty
unless upper levels (BTS, PCU) actually make use of it.
Change-Id: I1aee998d83b06692d76a83f79748f9129a2547e8
Related: OS#3054
There are some configuration nodes, which are handled by extenral
libraries, such as libosmoctrl. So, when switching back to the
parent node, this should be kept in mind.
Instead of aborting, let's got to the CONFIG_NODE by default.
Fixes: OS#3250
Change-Id: Ia0600a46d19825806e5aed9257b6c57c3907808b
At this stage, osmo-trx still uses the cmdline parameters top run the
device, but it is already able to parse all the same parameters from a
cfg file through the VTY and filling a trx_ctx structure which will be
later used to drive the device. Device config can be printed in the VTY
with "show trx".
Change-Id: Ie084c1b30b63f91c6e7640832ec1797d9e813832
Up to this point, the logging system, vty and ctrl are initialized and
can be used fine, though they don't have a lot of use yet.
Depends on libosmocore Change-Id Ib79cdb62d45d8c78445c7b064e58eb7e9faeccf9
Related: OS#2184
Change-Id: I08982c37b4f873966304b3cfb38a10ee86eb3dad
Pau Espin
Alexander Chemeris
Martin Hauke
Eric Wild
Harald Welte