Roflin 4e412c8b9b fsp-server: stop clamping GET_FILE replies to 1024, which capped streaming ...

Streaming measured 509 KB/s, BELOW the menu's 850 KB/s TCP dump, and the
arithmetic says exactly why.

I had this wrong: QUEUE_SIZE 2 is the number of queued GAME reads, not
concurrent network requests.  fsp_read_queued() sends ONE fsp_get_file and
arms a 1 s alarm; fsp_pop_queue() issues the next only once the response
arrives.  Streaming is therefore STRICTLY ONE REQUEST IN FLIGHT, so

    throughput = bytes_per_reply / round_trip

The server clamped replies to FSP_SPACE (1024), giving 1024 B / ~2.01 ms =
509 KB/s -- the measured figure almost exactly.  But the in-game client asks
for pmtu - 40 (1460 at a 1500 MTU) and accepts it; only fsplib has the 1024
limit, and fsplib never asks for more than that.  So honouring the requested
size is safe for both clients, and at 1440 B (the 1500 MTU budget rounded
down to 32) the same round trip gives ~1.41x, about 700 KB/s.

Replies stay a multiple of 32 unless they are the file tail, because the
client computes data_size = MIN(requested, OSRoundDown32B(reply_len)) and a
non-aligned mid-file reply would be silently truncated.

Also instruments the round trip: with one request in flight the observed
interval IS the RTT, so the report now splits it into total and this server's
median service time and says SERVER-bound or console-bound.  Without that,
"it is slow" has no owner.  And the raw socket now binds ETH_P_IP rather than
ETH_P_ALL, so our own outgoing frames are no longer copied to userspace and
parsed in Python on the path we are trying to shorten.

T13 checks a 1460-byte request yields 1440 (32-aligned) while an fsplib-sized
1024 request still yields exactly 1024.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-10-10 16:39:46 +02:00

115 KiB

Raw Permalink History

View Raw