Latency and smoothness
Smoothness beats the average
Section titled “Smoothness beats the average”A stream at 45 ms that arrives evenly feels better than one at 38 ms that arrives unevenly. Watch presentation interval variation: the standard deviation of the gap between displayed frames. It’s in the in-session performance overlay and the admin session detail.
| Value | Meaning |
|---|---|
| Below 12 ms | Healthy |
| 12 to 18 ms | Noticeable if you look for it |
| Above 18 ms | Visible stutter |
A background or hidden browser tab inflates every client-side smoothness number. Measure in a visible tab, and judge delivery from host-side frame rate and encode time.
Where the time goes
Section titled “Where the time goes”- Game renders the frame. Your game settings.
- Compositor captures it. Small.
- Encoder compresses it. Typically 7 to 19 ms. Above about 16 ms at 60 fps, it’s your bottleneck.
- Network carries it.
- Client buffers it. An adaptive jitter buffer, from the rung’s starting buffer down toward 50 ms, or toward the start if that is lower. Automatic, no server setting.
- Browser decodes and presents it. Small with hardware decode, a few ms more for AV1 software decode.
An uneven network forces a bigger buffer, and the buffer is latency. A consistent path is worth more than a fast one.
Things that help
Section titled “Things that help”- Wired, on both ends. The biggest single improvement. WiFi jitter is the most common cause of a stream that feels bad on a connection that measures fine.
- A larger UDP send buffer on each GPU host.
- A frame rate your GPU can hold. A steady 60 beats an unsteady 90.
- ABR on
smooth, the default. - A codec your client decodes in hardware, where possible.
The UDP send buffer
Section titled “The UDP send buffer”Recommended on every GPU host, not required. The kernel’s default UDP send buffer is too small for a keyframe burst: the kernel drops the overflow, and the stream throttles as if the network were bad.
What to do, once, from an account with sudo:
echo 'net.core.wmem_default=2097152' | sudo tee /etc/sysctl.d/99-quasar.confsudo sysctl --systemOn Unraid (/etc is rebuilt at every boot, so persist it in the boot script):
sysctl -w net.core.wmem_default=2097152grep -q wmem_default /boot/config/go || echo 'sysctl -w net.core.wmem_default=2097152' >> /boot/config/goIt applies to sessions started afterwards.
Check it worked: sysctl net.core.wmem_default prints 2097152 (or more).
To undo: delete /etc/sysctl.d/99-quasar.conf (Unraid: the line in
/boot/config/go) and reboot.
Things that mostly don’t
Section titled “Things that mostly don’t”- A lower GOP. More keyframes cost bitrate and cause spikes. The default 60 is fine.
QUASAR_QUEUE_BUFFERSbelow 3. Saves a couple of ms, loses jitter absorption.- Forward error correction. Don’t enable it for browsers (Experimental options).
macOS clients on WiFi
Section titled “macOS clients on WiFi”Periodic sawtooth latency spikes on a Mac often come from the AWDL interface (AirDrop, Handoff). Check it:
ifconfig awdl0Bringing it down has cut the 95th percentile from 68 ms to about 4 ms. It comes back whenever AirDrop or Handoff is used.
Measuring properly
Section titled “Measuring properly”Take a diagnostic bundle. It lines up encoder, network and client signals and says which one is responsible. See Diagnostics.
Browsers can’t measure true glass-to-glass latency: Chrome doesn’t expose the capture timestamp. A missing number there isn’t a host bug.