PulseBeam cuts Rust SFU latency with thread-per-core scheduling

PulseBeam’s Rust WebRTC selective forwarding unit moved from Tokio’s default multi-threaded work-stealing runtime to a thread-per-core design, and the switch cut P99.99 end-to-end latency from a spiky 70 ms to a stable 10 ms while lifting capacity 25 percent. The change landed in a July 10 technical update from PulseBeam, a lightweight end-to-end media stack with a Rust SFU core and HTTP signaling.

An SFU is the traffic cop of a live call. It forwards video, audio, and data without doing the expensive transcoding work of a full media server, so tail latency and jitter show up immediately in the user experience. In PulseBeam’s benchmark, a fully interactive four-person conference ran on four CPU cores, and WebRTC statistics showed unstable inbound-rtp jitter before the redesign. That instability fed into congestion control and produced visible stutter.

The older architecture followed a familiar async Rust pattern. Each participant, room, controller, and API lived as its own task, with channels carrying messages between them. That approach avoided mutex-heavy coordination, but the benchmark exposed its cost. Tokio’s runtime bundles an I/O driver, a scheduler, and a timer, and its multi-thread scheduler uses a work-stealing strategy. Contended blocking work can stall every other task on the same thread, which becomes a real problem when the hot path is packet handling and scheduler overhead rather than waiting on network I/O.

PulseBeam’s answer was thread-per-core, or TPC. The new layout kept work pinned to cores and made packet processing more synchronous, which cut down on async handoffs and reduced the chance of priority inversion. Tokio’s defaults are a strong starting point for general concurrency, but they are not automatically the right fit when a service starts behaving like a latency-sensitive media router.

PulseBeam is an opinionated stack for real-time video, audio, and data; LiveKit is an open source system for scalable, multi-user conferencing based on WebRTC; and WebRTC.rs leans into an async-friendly, sans-IO approach.