Hi all,
We are setting up a dedicated on-prem Proxmox VE 8.2 cluster (3x Lenovo ThinkCentre M70q Tiny nodes running kernel 6.8.4-3-pve) to host local services for automated front-desk reception terminals.
As part of deploying an on-prem visitor management system backend across unprivileged LXC containers (Debian 12), we're hitting an odd latency issue when streaming real-time WebRTC video feeds from physical check-in cameras to the containerized processing worker.
Here is the setup:
- PVE nodes connected via a dedicated 10GbE DAC interconnect for cluster/corosync traffic, and a separate 1GbE management/VLAN bridge (vmbr0.50).
- LXC container has veth interface bridged to vmbr0.50 with static IP.
- Inside the LXC, an OpenCV/GStreamer service handles RTSP/WebRTC badge and face verification.
The problem:
When a terminal opens the WebRTC stream to start guest badge capture, dmesg inside the host intermittently logs:
vmbr0.50: port 3(veth104i0) entered disabled state
vmbr0.50: port 3(veth104i0) entered forwarding state
and the video feed stutters for ~400-800ms before recovering. If we run the exact same container directly on a bare-metal Debian host (no bridge), frame capture is rock solid (<15ms latency).
We tried:
1. Disabling checksum offloading on both the physical NIC and veth (ethtool -K vmbr0 tx off rx off sg off).
2. Increasing rx-usecs and tx-usecs ring buffers.
3. Switching from standard Linux bridge to Open vSwitch (OVS) bridge on PVE.
Has anyone encountered bridge port state toggles or packet queue starvation with high-fps video pipelines inside LXC on PVE 8? Is it better to switch to a dedicated SR-IOV virtual function or direct macvlan for time-sensitive video streams in Proxmox containers?
Thanks for any insights!
We are setting up a dedicated on-prem Proxmox VE 8.2 cluster (3x Lenovo ThinkCentre M70q Tiny nodes running kernel 6.8.4-3-pve) to host local services for automated front-desk reception terminals.
As part of deploying an on-prem visitor management system backend across unprivileged LXC containers (Debian 12), we're hitting an odd latency issue when streaming real-time WebRTC video feeds from physical check-in cameras to the containerized processing worker.
Here is the setup:
- PVE nodes connected via a dedicated 10GbE DAC interconnect for cluster/corosync traffic, and a separate 1GbE management/VLAN bridge (vmbr0.50).
- LXC container has veth interface bridged to vmbr0.50 with static IP.
- Inside the LXC, an OpenCV/GStreamer service handles RTSP/WebRTC badge and face verification.
The problem:
When a terminal opens the WebRTC stream to start guest badge capture, dmesg inside the host intermittently logs:
vmbr0.50: port 3(veth104i0) entered disabled state
vmbr0.50: port 3(veth104i0) entered forwarding state
and the video feed stutters for ~400-800ms before recovering. If we run the exact same container directly on a bare-metal Debian host (no bridge), frame capture is rock solid (<15ms latency).
We tried:
1. Disabling checksum offloading on both the physical NIC and veth (ethtool -K vmbr0 tx off rx off sg off).
2. Increasing rx-usecs and tx-usecs ring buffers.
3. Switching from standard Linux bridge to Open vSwitch (OVS) bridge on PVE.
Has anyone encountered bridge port state toggles or packet queue starvation with high-fps video pipelines inside LXC on PVE 8? Is it better to switch to a dedicated SR-IOV virtual function or direct macvlan for time-sensitive video streams in Proxmox containers?
Thanks for any insights!
