diff options
Diffstat (limited to 'sdkconfig.defaults')
| -rw-r--r-- | sdkconfig.defaults | 19 |
1 files changed, 12 insertions, 7 deletions
diff --git a/sdkconfig.defaults b/sdkconfig.defaults index 4c50a23..1ba8375 100644 --- a/sdkconfig.defaults +++ b/sdkconfig.defaults @@ -29,13 +29,18 @@ CONFIG_LWIP_IPV4=y CONFIG_LWIP_IPV6=y CONFIG_MDNS_MAX_INTERFACES=1 -# TCP receive-window tuning attempted (WND/SND_BUF=32k, RECVMBOX=16, -# SACK on). Measured net-negative on the /frame path: ttfb regressed -# from ~350µs to ~1.2ms, body unchanged, and periodic 250+ms stalls -# appeared. Reason: Scrypted's per-frame fetch() opens a fresh TCP -# socket each time, so the larger window just slows slow-start. -# Reverted; revisit once we switch to HTTP keep-alive on the Scrypted -# side. Keeping the lwIP defaults. +# TCP receive-window + buffer tuning. Earlier attempt under HTTP +# regressed because every /frame opened a fresh socket and we ate +# the slow-start cost repeatedly. Under the streaming pivot the +# socket is long-lived: slow-start happens once, then we run with +# the full window for the rest of the session — which is exactly +# the workload these knobs are designed for. Larger WND lets the +# sender keep more bytes in flight per ACK and pushes our recv +# throughput ceiling up from ~5.3 MB/s. +CONFIG_LWIP_TCP_WND_DEFAULT=65535 +CONFIG_LWIP_TCP_SND_BUF_DEFAULT=65535 +CONFIG_LWIP_TCP_RECVMBOX_SIZE=16 +CONFIG_LWIP_TCP_SACK_OUT=y # HTTP server CONFIG_HTTPD_MAX_REQ_HDR_LEN=1024 |