[Sionna-RK] Alternate Deployment Modes for Measuring Near-RT / Real-Time Latency Tails

[rcbarke]

Hello all,

I’ve been exploring alternative bare-metal deployment options for Sionna-RK beyond its default dockerized workflow, alongside accelerated traffic-generation approaches, with the goal of evaluating p90/p95 latency tails for 3GPP URLLC traffic profiles (e.g. V2X at ~20 B every 10 ms with 99.99% reliability targets in Rel-18).

In the default dockerized configuration, injecting traffic from UE namespaces or containers introduces several sources of timing variance:

• Linux scheduler and cgroup contention
• Container networking layers and virtual NIC queues
• Timestamping paths that are not hardware-based
• Interaction with the RAN’s own timing regime (slot boundaries, grants, HARQ)

These effects are especially pronounced in CPU-bound 5G simulators (e.g. baseline OAI). Sionna-RK’s shift to GPU-accelerated L1/L2 significantly improves determinism at the PHY/MAC level, but the system is still influenced by host-OS and container-level timing artifacts when measuring latency tails.

In larger operational stacks, we typically address these systems challenges with hardware-timed I/O paths. For example, NVIDIA ACAR leverages GPUDirect RDMA, CPU isolation, hugepages, VFIO/IOMMU, and PTP synchronization to stabilize slot timing and move packets directly from GPU L1/L2 to the RU via a DPU-accelerated 7.2x I/O interface.

Even on DGX Spark, I don’t expect Sionna-RK to match ACAR-class determinism; however, I’m very interested in understanding its achievable upper bound for near-RT latency studies. The Spark’s onboard ConnectX-7 NIC may eventually enable tighter integration in tandem with accelerated SDRs such as USRP X410, though today it does not fully support GPUDirect RDMA.

Have alternate (non-dockerized or partially bare-metal) SRK deployment modes been explored internally for studying latency tails or near-RT effects?

I’m particularly interested in whether Sionna-RK could serve as a middle ground between purely software-defined 5G simulations and fully hardware-timed stacks like ACAR for URLLC-focused research. AODT might be more appropriate presently, though Spark-driven SRK deployment veers towards the necessary hardware.

Thanks in advance,
Ryan

[SebastianCa]

Hi @rcbarke,

As you noted, ACAR and ARC-OTA are the recommended platforms for such commercial-grade use cases. AODT is fully simulated, whereas Sionna-RK enables real-time RF transmission. Sionna-RK’s primary focus is to provide an accelerated research platform with a flexible, software-defined stack for experimentation, rather than deterministic near-RT operation (e.g., the USRP-based RF may cause a jitter already).

In principle, bare-metal installation of Sionna-RK is possible (the required steps can be derived from the Dockerfile installation routines). However, please note that we cannot provide support for such deployments.

[rcbarke]

Hi @SebastianCa,

I greatly appreciate the clarity provided and mirrored the Dockerfile process within local experiments. This confirms the same observations I reached from independent experimentation and I wouldn't expect SRK to fully operationalize. I completely understand and noted jitter across the 7.2x FHI within our B210-based USRP deployments.

We have larger compute intended to host ACAR and ARC-OTA actively en route, so I will place a hold on URLLC exploration until we're rack it. Thanks again for entertaining my inquiry regarding what might be possible within the interim.

[gmarcusm]

Hi @rcbarke,

a few comments on system configuration that are relevant to your description, in case you want to try them:

• linux scheduler and cgroup contention. Linux has only one scheduler, EEVDF, and realtime is already merged into mainline kernel (PREEMPT_RT). You can tweak the settings to improve latency in your specific setup. Cgroup configuration can be handled by docker (eg: see the metrics docs).
• CPU isolation. You can use docker resource constraints to achieve this.
• Hugepages. The kernel linux-image-6.14.0-1013-nvidia-64k provides support for hugepages. You will need to modify the boot command to add the extra required parameters to pass the kernel.
• direct network access. Can be mitigated by instructing docker to use the host network stack (--host) (probably what you mean by partial bare-metal).

Hope it helps,
Guillermo

[rcbarke]

Hi @rcbarke,

a few comments on system configuration that are relevant to your description, in case you want to try them:

• linux scheduler and cgroup contention. Linux has only one scheduler, EEVDF, and realtime is already merged into mainline kernel (PREEMPT_RT). You can tweak the settings to improve latency in your specific setup. Cgroup configuration can be handled by docker (eg: see the metrics docs).
• CPU isolation. You can use docker resource constraints to achieve this.
• Hugepages. The kernel linux-image-6.14.0-1013-nvidia-64k provides support for hugepages. You will need to modify the boot command to add the extra required parameters to pass the kernel.
• direct network access. Can be mitigated by instructing docker to use the host network stack (--host) (probably what you mean by partial bare-metal).

Hope it helps, Guillermo

Hi Guillermo,

Extremely helpful, and very appreciated, thank you! I have a few upcoming demos and am planning to try augmenting the operating system of one of our Sparks for this. I was also able to establish QSFP IPv4 communication to an X410 already. By 'partial bare metal', I was referring to hardware-level driver tricks like DMA or GPU DirectRDMA. Traditionally, I'm not used to interfacing with these through Docker, but hadn't thought to try a bridged private/host network configuration. Thank you for pointing me in this direction!

Speaking broadly, the bit rates we need to achieve for URLLC traffic profiles are modest (usually an aggregate 15-20 Mbps). I was involved in early stage research at a Tier 1 operator for technologies such as telesurgery and autonomous driving, where the answer to achieving the required determinism was "throw fixed function ASIC and GPSDO/PTP timing synchronization at the problem". An effective first stage step, though I'm always interested in ways to make these research questions like physical layer security, reliability, service availability, timing studies, etc. more accessible within the nextG domain. SRK's an amazing platform and may be able to pull this off someday, though I also completely respect that it isn't formally supported today.

Best,
Ryan