About TRX port #0 underflows/overflows
Table of Contents
- About TRX port #0 underflows/overflows
underflow/overflows message means that IQ samples arrive to SDR card too early or too late. This will affect the generated signal and will break air communications.
Troubleshoot
You can use "t cpu" command and check the rx/tx min value. When the value is close to zero (or even negative), it means that your HW is not designed to support such config.
Here an example of good real time performances without underflows/overflow:
You can face 2 different situations. The first one when the rx/tx min value is constantly too low leading to underflow messages every 2 seconds or it can happen intermitently.
CPU clock is not running at expected speed
Here are several way to control CPU frequency and ensure it is running at highest speed and
no frequency throttling will affect the performances.
Note that depending on your Linux flavours, some tweaks may not have any impact.
Check current frequency
First you may check the actual CPU/cores frequency.
For that you may use lscpu command but the provided information may not exactly reflect the real frequency
To have a precise measure, use cpupower utility (Available with kernel-tools package under Fedora):
Here we can see all cores are running at 4.5GHz
Note that you should check that your system is not loaded (Stop lte service) to avoid bad interpretation
Configure CPU governor
make sure that CPU governor is set to performance:
If it is not the case, you should run the script ./lte_init.sh available under /root/enb or /root/ue folder.
Use tuned service
After installing tuned package, you may configure it this way:
Start service
List profiles
Select your profile:
Amarisoft provides a tuned profile. You will find it in ots software package as amarisoft-tuned.profile file. To use it you need to create /usr/lib/tuned/amarisoft directory and copy this file inside as tuned.conf.
Amarisoft product CPU speeds
- callbox classic: cpu clock speed 4.3GHz
- callbox ultimate: cpu clock speed 4GHz
- ue sim box/ue sim box E: cpu clock speed 4.5GHz
BIOS
Note that BIOS can have an impact on CPU frequency and override any OS related config.
CPU mitigations
To speed up your system, you may disable CPU vulnerabilities mitigations that could increase a bit the system performances. This can be done by adding mitigations=off to your system command line in grub (GRUB_CMDLINE_LINUX).
Check memory hardware configuration
For optimal performances, the system should have as much RAM bank as supported memory channels by the CPU.
You can use lsmem command to control it.
- i9 cpu based: 4 DDR channels needed
- i7 cpu based: 2 DDR channels needed
- Runnning CPU intensive other software
- Launching desktop GUI, especially when 3D effects are enabled: you should keep your system in console mode
- Running software in a Virtual Machine (Hypervisor mode)
- Some system driver may block the kernel and cause latency spikes such as (Ex: wifi driver): you may try to disable them to check the impact.
Bellow the output of lsmem for callbox ultimate:
Multi SDR card case
Verify that all SDR cards are using the same FW version.
Under /root/trx_sdr/ folder type "./sdr_util version" and check the FW version of all SDR cards.
Make sure that SDR cards are using the FW version that is compatible the eNB SW.
nder /root/trx_sdr/ folder type "./sdr_util upgarde". If FW version and eNB SW are aligned, it will not trigger a FW upgrade.
Make sure that the PCIe link speed is ok.
Under /root/trx_sdr/ folder type "./sdr_test dma_loopback_test n", "n" is the number of plugged SDR cards. For SDR50, you should get a dma throughput of at least 3.4G per SDR card. For SDR100, you should get a dma throughput of at least 11.3G.
Bellow the output of dma_loopback test for SDR50:Bellow the output of dma_loopback test for SDR100:
Other software interaction
Your system may be overloaded by other programs impacting CPU.
We strongly recommend to avoid:
Latency spikes
To detect if something in the system can cause realtime software to be descheduled by Linux for a significant amount of time and cause latency spikes, you can use cyclictest program.
On Fedora, the program is included in realtime-tests package:
Once installed, you may run following command:
The last column will inform you about the maximum latency detected on each core. Its value is in microseconds and if it goes above ~500 microseconds, you can consider something in your system may stall the Amarisoft real time softwares.