Socket buffer tuning and the 9.5 fps deficit

[mauricio-gg]

Summary. In February 2026 the Vita's UDP receive buffer was raised from 100 KB to 512 KB, and a batch "drain" loop was added after each blocking receive, to stop a suspected socket overflow that was costing about 9.5 fps. Both changes are on main and the 512 KB value is still what the Vita uses. The original document's "pending hardware validation" status is stale. I found no recorded before/after fps measurement in the repo, but a later A/B (PR #193) showed that shrinking the buffer to 256 KB made freezes and frame failures several times worse, which is the strongest evidence that the large buffer is doing real work. Treat the "9.5 fps" figure as the original author's analysis, not a confirmed measurement.

The problem as originally described (February 13, 2026)

Periodic fps loss during streaming: about 2.4 events per second (roughly every 420 ms), always about 3 frames per event, totalling about 9.5 fps. The investigation process was:

1. Decode bottleneck? No. Decode took 1-2 ms against a 33 ms frame budget.
2. Random Wi-Fi loss? The pattern was deterministic (~420 ms period), which random loss would not produce.
3. Root cause proposed: UDP socket receive-buffer overflow. The PS5 sends video as bursts (about 1200 packets/s of ~1400 bytes, ~1.7 MB/s), each burst carrying roughly 100-200 ms of video. A 100 KB buffer fills in about 59 ms and the kernel silently drops what does not fit. The Vita was using the 100 KB desktop default.

The packet-rate and burst figures are the original author's estimates; they are not tied to a log id in the source.

What was changed

• P0: larger Vita receive buffer. TAKION_A_RWND became 0x80000 (512 KB) on the Vita and stayed 0x19000 (100 KB) elsewhere, with getsockopt logging to show what size the OS actually granted. The same value is also advertised to the console as its receive window.
• P1: batch drain loop. After the blocking select() and first recv(), pull any already-buffered packets with zero-timeout receives before blocking again. The aim was to avoid one wakeup per packet during a burst. The original cap was 64 packets per wakeup.

P2 (buffer-pool malloc elimination) was deferred pending results of P0 and P1.

What main does today (0e9dd13)

• Receive buffer: 512 KB on the Vita. #define TAKION_A_RWND 0x80000 under __PSVITA__, 0x19000 (100 KB) elsewhere (lib/src/takion.c:51-53). It is assigned at takion.c:330 and applied with setsockopt(SO_RCVBUF) on both socket setup paths (takion.c:370 for a socket passed in, :491 for a socket Takion creates). The granted size is logged after each as Takion SO_RCVBUF requested=... actual=... (takion.c:381, 502).

• Send buffer matched to it. SO_SNDBUF is set to the same size and logged (takion.c:384-402 and :505-518), from PR fix(net): SO_SNDBUF symmetric tuning + Senkusha 1ms RTT fallback fix #148 (May 2026), so IDR requests, feedback and ACK bursts are not stalled by a small default send buffer. A failure there is a logged warning, not an error.

• Drain cap raised to 256. TAKION_RECV_DRAIN_MAX 256 (takion.c:80, loop at :1432). PR fix(takion): eliminate per-packet malloc churn and raise drain cap to cut recv-thread lag (#192) #192 (June 2026) raised it from 64 after log 18111884121_vitarps5-testing.log showed drain_max=64 saturated, meaning bursts were being split across wakeups. The same PR removed the per-packet malloc(1500) on the receive thread (the log had shown 1365-2146 malloc calls per 5 s), which is how P2 was effectively done, by reusing one receive buffer rather than building a pool.

• The hardware A/B that tried to shrink it (PR fix(metrics): print honest windowed bitrate as measured [A/B: RWND revert] #193, reverted). Cutting the window from 512 KB to 256 KB to reduce bufferbloat gave no latency benefit and a clear stability regression. Counts from the PR description, 512 KB baseline versus 256 KB:

  Guard	512 KB	256 KB
  PIPE/FREEZE	4	16
  missing_ref	17	50
  fec_fail	15	45
  corrupt	21	99

  The PR also listed jitter and RTT rows. Those came from the discredited latency readout (handshake RTT plus a control-channel EWMA; see the #251 IDR-wait freeze thread) and are dropped here as invalid. The smaller window left too little headroom to absorb Vita Wi-Fi burst loss, and 192 KB and 128 KB were abandoned without trying. The decision is recorded as a permanent comment above TAKION_A_RWND (takion.c:44-50) so it is not retried. Bufferbloat remains a real concern, but it is not bounded by the receive window at this stream's bitrate.

Corrections to the original text

• Status. "Implemented, pending hardware validation" is stale; the change has been in every build since February, and the later PR fix(metrics): print honest windowed bitrate as measured [A/B: RWND revert] #193 A/B counts are the closest thing to validation on record. The original expected figures (near-zero fps loss, 10-15 ms latency saving, ~28 ms/s cumulative saving) were forecasts and were never confirmed in the repo.
• Conditional name. The original snippets used #ifdef VITA; the real symbol is __PSVITA__.
• "8-packet reorder queue." The appendix described an application-level 8-packet reorder queue. Today the reorder queue has 256 entries and carries control-channel messages only; video and audio packets bypass it (takion.c:69).
• Drain cap 64. Now 256 (see above).
• Branch name. The work was done on feat/startup-connect-burst-rework (commit 481f7e6); that branch is long gone and nothing depends on it.
• IP_DONTFRAG was listed as unavailable on the Vita. That is still true: takion.c:429-433 only logs "Don't fragment is not supported on this platform".

Optional follow-up decision criteria (from the original)

P2 was to be pursued only if fps loss stayed above about 2 fps after P0 and P1, and skipped if it was under 1 fps. With the malloc removal in PR #192 done, this question is closed unless a new measurement shows the loss returning.

Source: docs/ai/NETWORK_SOCKET_BUFFER_OPTIMIZATION.md and docs/NETWORK_OPTIMIZATION_SUMMARY.md (deleted from the repo in #281; recoverable from git history at commit 0e9dd13)