CI: Enable Physim threshold check for tests on Caracal and GH
This MR adds support for configurable timing threshold files in PhySim
tests.
- Introduces a new CMake cache variable PHYSIM_CHECK_FILES to specify
one or more timing threshold files (semicolon-separated).
- Enables optional enforcement of timing thresholds check in PhySim
tests without changing existing test definitions.
- Defines timing thresholds for LDPC encoding/decoding in nr_ulsim,
nr_dlsim and ldpctest on Caracal and GH machines.
Add missing timinig analysis scripts to RHEL9 physim docker image. These files
are now copied from the build stage to /oai-ran/openair1/SIMULATION/tests/,
where they are expected by ctest.
Resolves following issue when running ctest in docker container:
CMake Error: Error processing file: /oai-ran/openair1/SIMULATION/tests/RunTimedTest.cmake
Most (but not all) physical simulators are defined under
openair1/SIMULATION/. Defining physical simulators below there seems to
be the more "obvious" directory anyway, as the physical simulators are
openair1/SIMULATION/tests
Phy(L1) Sim tests => PhySim (tests)
Redirect to files and manual analysis as done in this Dockerfile is not
necessary since we just output all relevant build files to stdout.
Simplify to do the same here.
See: 35361db76b ("build_oai: don't redirect compilations to a file")
Improve MAC docs for MCS and docker for BuildKit usage
See commits for details. The first one is for fixing an omission in
!3281, the second to clarify docker build usage.
Closes: #973
The Dockerfiles are reused for building on different architectures
(amd64/arm64). They differ, though, on some steps for downloading or
installing platform-specific utilities.
This is handled automatically when using BuildKit, which is the default
in docker versions v23.0+. Older docker versions require some special
settings. Explain this in the README.
Closes: #973
As DEBIAN_FRONTEND has been set as environment variable, there is no need to use DEBIAN_FRONTEND=noninteractive inside RUN lines, it is redundant, hence it has been removed.
Libboost went from 1.74.0 to 1.83.0 alongside Ubuntu update.
GCC version is set as default to be more practical.
In Ubuntu22, apt sources were in .list files, in Ubuntu24 they are in .sources files.
Add --break-system-packages for pip installation to use same logic as before, see the pip update 23.0.1 (2023-02-17).
With Ubuntu24 liboai_device requires libpython3.12
Refactor F1 UE context messages, add unit tests
Add encoder+decoder+util functions for F1 UE context messages, and use
them in the stack. The overall goal is to unit test encoder+decoder (to
be sure that what we send is what we receive), and remove any memory
leaks related to F1 handling. Messages that have a unit test:
- F1 UE context setup request/response
- F1 UE context modification request/response
- F1 UE context release request/command/complete
This MR removes almost all remaining memory leaks that are observable in
a "standard" configuration, running SISO in RFsim. In RFsim (without
channel modelling), there are only two memory leaks shown in asan, one
in L1, and one in NGAP.
Speed up docker deployment in CI
- Using docker compose up --wait instead of a custom healthcheck script:
from: https://docs.docker.com/reference/cli/docker/compose/up/
--wait Wait for services to be running|healthy. Implies detached mode.
--wait-timeout Maximum duration in seconds to wait for the project to be running|healthy
- Speeding up the healthchecks by reducing the interval from 1-10s to
0.5s during start period
start_period creates a special period after the start of the container
where the healthcheck is executed every start_interval . During this
time the failures do not count towards the retries counter, but
successes change the status to healthy. This allows container to reach
healthy status much sooner.
- Using init: true to speed up docker compose down/stop
`init: true` initializes the docker container with tini or
alternative: tini is used to collect all the processes and correctly
pass the termination signal to them. This allows the docker container
to be stopped without waiting 10 seconds to kill the container
- Smallest example of this is:
services:
test-init:
image: ubuntu:jammy
command: sleep 10d
This modification aims to improve health status detection by using PRACH IO as
an indicator of the gNB's status (container is marked as "healthy" when the
PRACH IO value in gNB nrL1_stats.log exceeds 0.0 dB.). The new condition accounts
for scenarios where the container may not exit or produce error codes (e.g.,
“sleep” logs or "error code overflow" messages).
CI: Upgrade Aerial version to 25-1
- Update the Nvidia L1 (cuBB) from version 24-3 to 25-1
- Decrease the number of cores dedicated to the OAI gNB; testing showed
it does not need that many
- This is to avoid the Docker image builder from being confused in case we have multiple nvIPC files in `/opt/nvidia-ipc`
- This occurs when we have an MR to upgrade the cuBB image
Set the CMAKE_RUNTIME_OUTPUT_DIRECTORY CMake option during the OAI build
to control the location of runtime target files. This ensures that ctest
can locate necessary executables after they are copied to the target
Docker image.
Add --allowerasing, which will downgrades some packets in order to
satisfy LLVM dependencies.
When building the docker image for clang, CI fails with
Error:
Problem: llvm-18.1.8-3.el9.i686 from ubi-9-appstream-rpms does not belong to a distupgrade repository
- package llvm-toolset-18.1.8-3.el9.x86_64 from ubi-9-appstream-rpms requires llvm = 18.1.8, but none of the providers can be installed
- package llvm-18.1.8-3.el9.x86_64 from ubi-9-appstream-rpms requires llvm-libs(x86-64) = 18.1.8-3.el9, but none of the providers can be installed
- package llvm-18.1.8-3.el9.x86_64 from ubi-9-appstream-rpms requires libLLVM.so.18.1()(64bit), but none of the providers can be installed
- package llvm-18.1.8-3.el9.x86_64 from ubi-9-appstream-rpms requires libLLVM.so.18.1(LLVM_18.1)(64bit), but none of the providers can be installed
- cannot install both llvm-libs-18.1.8-3.el9.x86_64 from ubi-9-appstream-rpms and llvm-libs-19.1.7-2.el9.x86_64 from @System
- package mesa-dri-drivers-24.2.8-2.el9_6.x86_64 from @System requires libLLVM.so.19.1()(64bit), but none of the providers can be installed
- package mesa-dri-drivers-24.2.8-2.el9_6.x86_64 from @System requires libLLVM.so.19.1(LLVM_19.1)(64bit), but none of the providers can be installed
- package mesa-libGL-24.2.8-2.el9_6.x86_64 from @System requires libgallium-24.2.8.so()(64bit), but none of the providers can be installed
- package mesa-libGL-24.2.8-2.el9_6.x86_64 from @System requires libgallium-24.2.8.so(libgallium-24.2.8.so)(64bit), but none of the providers can be installed
- package mesa-libGL-devel-24.2.8-2.el9_6.x86_64 from @System requires mesa-libGL(x86-64) = 24.2.8-2.el9_6, but none of the providers can be installed
- conflicting requests
- problem with installed package mesa-libGL-devel-24.2.8-2.el9_6.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
So when trying to install llvm-toolset from docker/Dockerfile.clang.rhel9,
we have a conflict because this installs 18.1 from ubi-9-appstream-rpms,
but various mesa packets have llvm 19.1.
1. I don't understand why we have mesa installed (no graphics system?)
2. --allowerasing downgrades the relevent mesa package(s)
Alternatively, we would need to select 19.1 when installing
llvm-toolset, but I don't know how to do that.
Dockerfiles hardcoded one copy operation to x86; generalize to capture
ARM as well. Since the target directory cannot have any globs, we need
to manually check the right directory, then move the file.
Note that this is only necessary since we are forced to switch the
compiler, as Ubuntu's default gcc-11 does not work with FlexRIC. When
upgrading to Ubuntu 24, these lines should disappear and asan be
installed as normal. See commit 94497435e7 ("Upgrade CI images to
Ubuntu 22").
Fronthaul xran library update to F release (2. and final step towards M-plane integration)
- xran library support -> both E and F releases
- RU delay profile removed -> not used in neither of the releases
- DU delay profile updated
- one-way delay measurements support is improved/fixed in the F release.
However, not implemented here as it depends on the RU capabilities
Some users of the OAI CI complain that since we build with -Werror, it
is difficult to see all warnings/errors and fix them, necessitating
multiple attempts at times to see all warnings. To allow them to see
more warnings, use ninja option -k10 to keep going after errors, and
show more errors at once.
Integration: `2024.w45`
See merge request oai/openairinterface5g!3097
* !3048 Cleanup and refactoring at gNB initialization
* !3077 Address most thread safety issues in NR UE
* !3089 Improve cross-compile documentation
* !3092 Remove Interop-F1/Accelleran-CU testing pipeline
* !3096 Remove x86-specific instructions from telnet server
* !2949 Better polar decode
* !3070 CI: Add test with 4 DL layers, 60 MHz BW to SA-2x2 pipeline
* !3098 nr rlc: hotfix: test allocation valid before use
* !3090 Add UL PRBs Blacklist section to NR_SA_Tutorial_COTS_UE.md
* !3082 fix blocking bugs in command nr_dlsim -n100 -e27 -s35 -b 273 -R273 -x4 -y4 -z4
* !3100 CI: Remove 5g_l2sim files
* !3024 Set SA mode as default
* !3087 Remove some usage of the old CI sshConnection class
* !3074 CI: cleanup of cls_physim.py
Set SA mode as default
- Set standalone (SA) mode as the default.
- Adjust commands in Docker Compose files by removing --sa flags and
adding --nsa flags where applicable.
- Add a function to verify that only one mode is being used at a time.
- Update all relevant documentation.
The clang build fails with
/oai-ran/openair1/PHY/MODULATION/gen_75KHz.cpp:16:23: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension]
16 | complex<double> t[len];
| ^~~
/oai-ran/openair1/PHY/MODULATION/gen_75KHz.cpp:16:23: note: function parameter 'len' with unknown value cannot be used in a constant expression
So ignore this warning (and make the build pass), since OAI uses VLAs in
various places.
