Setting a manual Bandwidth limit of 100 Mbps in the Steam Link app (previously left on
automatic) removed the Packet too big faults completely, and dropped frames fell by more
than two orders of magnitude. Same host, same headset, same network, only that setting changed.
| Before (automatic bandwidth) | After (100 Mbps cap) | |
|---|---|---|
| Session | Half-Life: Alyx, 169 min | VRChat, 28 min |
FAULT: Packet too big |
47 (0.28/min) | 0 |
HandleUnrecoverableError |
43 (0.25/min) | 3 — all during connection setup, none in-session |
| Dropped presents | 2368 / 639583 (0.37%) | 1 / 66322 (0.0015%) |
| Reprojected | 0 | 0 |
At the previous rate, ~8 faults would have been expected in a 28-minute session.
The 3 remaining HandleUnrecoverableError calls all occurred within a 2-second window
before the game launched, and are preceded by:
21:26:56.565920 vrlink: Timed out waiting for another accepted video packet, trying to force the stream reset
21:26:56.565989 vrlink: HandleUnrecoverableError( 1 )
21:26:56.566016 vrlink: SVLFEC::ReportStreamReset() (m_iLastAcknowledgeFrameNumber = 5383)
which looks like ordinary stream negotiation rather than the reported fault.
On a fast link (~2400 Mbit negotiated, -28 dBm) the automatic bandwidth selection appears
to choose an encoder configuration whose output exceeds what the send path accepts, and the
oversized packet is then dropped rather than fragmented or re-encoded smaller. A manual cap
sidesteps it.
This also reinforces the earlier point that vrserver.txt never logs the negotiated
bitrate — with it logged, this would have been diagnosable directly instead of by
experiment.
I suspect this has been fixed as a side-effect of a different (but related) fix. When we push the next version of the Quest app, I'd love to see whether you still have the issue when not capping the bandwidth.
Nothing extracted yet.
Description
During wireless VR streaming to a Quest 3S via Steam Link,
vrlinkperiodically fails tosend video packets, logging
FAULT: Packet too big!!! Can't send!!! Droppingfollowed inmany cases by
HandleUnrecoverableError( -22 )(-EINVAL). Each occurrence is perceivedin-headset as a brief hitch.
This is not GPU-bound: over the same session the compositor reported 0 reprojected
frames and only 0.37% dropped presents.
Frequency
Over a single 2h49m Half-Life: Alyx session (
20:48:35→23:37:40):FAULT: Packet too big!!! Can't send!!! Dropping— 47 occurrencesHandleUnrecoverableError(...)— 43 occurrencesTimed out. 1617 totalRoughly one fault every 3.6 minutes, sometimes in bursts.
Log excerpts (
vrserver.txt)Compositor frame stats for the same session:
Observations
re-encoded at a smaller size, so a frame chunk is simply lost.
-22/EINVALsuggests the datagram exceeds what the socket will accept.~2400 Mbit link rate). No MTU customisation anywhere on the path.
vrserver.txtdoes not log the negotiated bitrate or encoder configuration, which makesit hard to tell whether an over-aggressive bitrate is being selected on a fast link.
System
BUILD_ID 20260716.1)mesa 25.3.0.213835.radeonsivrlink)Expected
Oversized encoder output should be fragmented or the encoder asked for a smaller payload,
rather than the packet being dropped and a frame chunk lost.