ports: Increase the STM32N6/MIMXRT TCP receive window. - #19629
Open
kwagyeman wants to merge 2 commits into
Open
Conversation
TCP receive throughput is bounded by window/RTT. At the ~5-6ms round-trip time of the OPENMV_N6's CYW43439 WiFi link, the 16*MSS window works out to ~31Mbit/s -- and that is exactly what the board measures, well below what the link otherwise carries (~43Mbit/s UDP on the same air). Double the receive window to 32*MSS: it is covered by the existing PBUF_POOL (32 buffers), so there is no additional static memory cost, and the send buffer is unchanged. Measured on an OpenMV N6 (Python socket benchmark, 2.4GHz, same board/AP/position): TCP receive over WiFi improves from ~31Mbit/s to 35-39Mbit/s; TCP transmit and UDP are unchanged, and ethernet on the same board is unaffected (its sub-millisecond RTT was never window-limited). Signed-off-by: Kwabena W. Agyeman <kwagyeman@live.com>
The port used the smallest lwipopts_common.h memory tier: MSS=800, an 8*MSS=6400 byte window and an 8000 byte heap. On WiFi round-trip times that window caps TCP at window/RTT, and the sub-MTU MSS costs per-packet efficiency on every link. Measured on an OpenMV RT1060 (CYW4343W WiFi): TCP was limited to 6.4Mbit/s transmit / 15.9Mbit/s receive. Switch to MSS=1460 with a 7*MSS receive window, 6*MSS send buffer and a 13K heap (sized so the heap comfortably exceeds the send buffer, keeping lwIP's ERR_MEM retry path cold). With this configuration the same benchmark measures 22.2Mbit/s transmit / 24Mbit/s receive (3.5x / 1.5x), with UDP unaffected. 100M ethernet on the same silicon still runs at line rate. All values are guarded so a board can override them, and only boards with a network interface build lwIP on this port. Signed-off-by: Kwabena W. Agyeman <kwagyeman@live.com>
|
Code size report: |
Contributor
|
good! |
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
3 participants
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.
Summary
Two per-port lwIP sizing fixes found while benchmarking TCP/UDP on WiFi
hardware:
receive is bounded by window/RTT. At the ~5-6ms round-trip time of the
OPENMV_N6's CYW43439 WiFi link, the existing 16*MSS window works out to
~31Mbit/s — exactly what the board measures, well below what the link
carries (~43Mbit/s UDP on the same air). The larger window is covered
by the existing PBUF_POOL, so there is no additional static memory
cost. The send buffer is unchanged.
smallest
lwipopts_common.htier: MSS=800, a 6400-byte window and an8000-byte heap. That caps TCP at single-digit Mbit/s on WiFi RTTs and
costs per-packet efficiency everywhere. Switch to MSS=1460 with a 7MSS
receive window, 6MSS send buffer and a 13K heap — sized so the heap
comfortably exceeds the send buffer, keeping lwIP's ERR_MEM retry path
cold. All values are
#ifndef-guarded so boards can override them, andonly boards with a network interface build lwIP on this port (all of
which have ample OCRAM).
Measured (Python socket benchmarks, 2.4GHz WiFi, same board/AP/position
per pair, multiple runs):
100M ethernet on the RT10xx still runs at line rate (91/91 Mbit/s TCP),
and the N6's gigabit ethernet is unaffected (its sub-millisecond RTT was
never window-limited).
Testing
Runtime tested with TCP/UDP benchmarks in both directions on an OpenMV N6
(CYW43439 WiFi + RGMII ethernet) and an OpenMV RT1060 (CYW4343W WiFi +
100M ethernet), numbers above.
Build-tested: OPENMV_N6, TEENSY41, MIMXRT1060_EVK.
Trade-offs and Alternatives
The mimxrt change grows lwIP's static footprint by roughly 20K on
network-enabled boards (heap + full-size pbuf pool). Boards that want the
old sizes can override any value before the guarded block. The stm32
change is N6-scoped and costs nothing beyond window accounting.
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.