A connection given back is revived every time on the XGS 136, measured, 2026-10-24
Issue 717: a TCP stream whose data comes
from the far side - the bench PC opens it, the second XGS 3300 behind the XGS 136's Port8 sends - stayed
with the host for most of its length on some runs, every frame CONN_RECLAIM_PENDING. The fast path
had given the connection back by its retransmission rule, the driver revived it, and after four
revivals in four seconds took it out and left it with the host for a wait - a second, then two, then
four - which a stream with losses meets again and again. That rule was the XGS 136's alone. The
XGS 3300's driver measured the same rule on 2026-10-20, found it no help, and revives every time
(xgs3300-many-2026-10-19.md).
The XGS 136 now does the same: flow.revive_hold, 0 by default, revives a connection the fast path
gives back every time; 1 keeps the old rule, as an instrument.
The whole page, with how it was taken and what it does not show: A connection given back is revived every time on the XGS 136, measured, 2026-10-24.
The discussion of this page is held in the project's GitHub Discussions. Showing it here loads giscus from giscus.app and GitHub, and writing in it needs a GitHub account - what that means.