esp32/boards: Raise default lwIP TCP window on PSRAM boards. - #19592
Open
pavelrevak wants to merge 1 commit into
Open
esp32/boards: Raise default lwIP TCP window on PSRAM boards.#19592pavelrevak wants to merge 1 commit into
pavelrevak wants to merge 1 commit into
Conversation
The lwIP default TCP send buffer and window (5760 bytes) limit a single TCP connection to window/RTT, which at a typical WiFi RTT of ~5 ms caps throughput at roughly 5-10 Mbit/s regardless of the WiFi PHY rate or band -- the extra capacity of 5 GHz / 802.11ax is simply wasted. Set CONFIG_LWIP_TCP_SND_BUF_DEFAULT and CONFIG_LWIP_TCP_WND_DEFAULT to 65534 in sdkconfig.spiram_oct and sdkconfig.spiram_quad, so boards with external PSRAM get a full-size TCP window. This is gated on PSRAM on purpose: the larger per-connection buffers cost internal RAM, so boards without PSRAM keep the small window (size over speed). The ESP32-P4 board already sets this in its own config. Measured single-connection TCP TX throughput (RSSI -40..-48 dBm). The ESP32-C5 was associated to an 802.11ax (WiFi 6) access point; the S3 figure is from a generic ESP32-S3 module: ESP32-C5, 2.4 GHz: 9.4 -> 31.7 Mbit/s ESP32-C5, 5 GHz: 6.6 -> 34.7 Mbit/s ESP32-S3: 5.0 -> 11.0 Mbit/s Signed-off-by: Pavel Revak <pavelrevak@gmail.com>
|
Code size report: |
Contributor
Author
|
This makes WiFi actually fast on PSRAM boards: a single TCP |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Raises the default lwIP TCP window on esp32 boards with external PSRAM,
which currently run with a window too small to use the WiFi link.
The problem
The esp32 port uses the lwIP default TCP send buffer / window of 5760
bytes. A single TCP connection is then limited to
window / RTT; at atypical WiFi RTT of ~5 ms that caps throughput at roughly 5-10 Mbit/s
regardless of the WiFi PHY rate or band -- the extra capacity of
5 GHz / 802.11ax is wasted. The ESP32-P4 board already raises this in its
own config; other boards don't.
The fix
Set
CONFIG_LWIP_TCP_SND_BUF_DEFAULTandCONFIG_LWIP_TCP_WND_DEFAULTto65534 in
sdkconfig.spiram_octandsdkconfig.spiram_quad, covering theS2/S3/C5 boards that use quad/octal PSRAM. It is gated on PSRAM
deliberately: the larger per-connection buffers cost internal RAM, so
non-PSRAM boards keep the small window (size over speed). The
original-ESP32 PSRAM config (
sdkconfig.spiram_esp32) is left unchangedfor now -- those chips have a lower WiFi PHY and less RAM headroom and I
have not tested them; it can be a follow-up.
Testing
Raw single-connection TCP TX throughput (RSSI -40..-48 dBm). The ESP32-C5
was on an 802.11ax (WiFi 6) AP; the S3 figure is a generic ESP32-S3
module:
The cap was confirmed window-limited (effective in-flight data ~= 5760 B,
the default), and opening several parallel connections scaled aggregate
throughput before the fix -- i.e. the WiFi PHY had headroom a single
connection could not use.
Generative AI
I used generative AI tools when creating this PR, but a human has checked the
code and is responsible for the code and the description above.