Repository navigation
Conversation
At 50,176 bytes the data-driven acknowledgment carried 35-48 segments, fewer than two per sender burst. Losing two of them (the WiFiPi TX drop of #89) left the sender with no feedback until a probe and the 100-200 ms delayed-ACK hold. At 11,680 (8 x 1460) the crossing falls inside the first 16-frame GRO run, so one acknowledgment leaves per run. Measured on the A1200 (WiFiPi, main 95e3983, inbound iperf, same harness and driver, only this constant differs): bytes per acknowledgment (median) 60,932 (5 controls) -> 23,360 acknowledgments per second ~89 -> 218 throughput 41.8-44.0 -> 50.3 Mbit/s One test leg: the stall reduction is not yet shown. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tinic
marked this pull request as draft
September 28, 2026 02:35
Owner
Author
|
On hold, not merging: the ACK cap is to become a per-interface runtime setting (TCPACKMAX: WiFi 11680, wired 50176). This global default would overlap it. CI is green; the measurements here (hw19, same window in every leg) stay valid for the per-interface change. The hw20 240 s legs are confounded by the connect-time receive window (100352 vs 802816 B) and are not evidence for stall reduction. |
Owner
Author
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
1 participant
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.
Lowers
NX_TCP_ACK_THRESHOLD_MAX(port/netxduo-amiga/inc/nx_user.h) from 50,176 to 11,680 bytes, part of #89. The value is a constant, so this is the whole change.Why
At 50,176 bytes, each data-driven acknowledgment covered 35-49 segments (p50 41.7), fewer than two per sender burst. When the WiFiPi TX path dropped two of them (#89), the sender had no feedback left. It waited for a probe and the Amiga's 100 to 200 ms delayed-ACK hold. hw4 shows five such stalls of 161 to 251 ms.
At 11,680 bytes (8 × 1460), the threshold is crossed inside the first 16-frame GRO run (
sana2_rx.c), so the stack sends one acknowledgment per run.Measured
Setup: A1200 with WiFiPi, running main
95e3983a. Inbound iperf, the same harness and the same driver (0f81c5ff) in every leg. Only this constant differs.Merge is on hold for an inbound A/B on a wired card: the define is global, and 2.45x the ACK TX may cost read throughput where the path is CPU-bound.
There is only one test leg. The change in ACK cadence and the throughput gain are both well outside the control spread. The reduction in stalls is not yet shown: a 240 s paired leg is proposed to test it. CPU cost was not measured; the Amiga sends about 2.5× as many ACKs.
Evidence: playhouse2
~/anxd-evidence/89-trace/hw19-main-ackceil/.🤖 Generated with Claude Code