Conversation
…ms tick The loop's wait is bounded by the earliest engine deadline, so an idle reactor fires a retransmit, ACK or pacing step when it is due. The 250 ms timer and the sweeps are unchanged, and a reactor with no QUIC deadline makes the same unbounded wait as before.
Owner
Author
|
Closing in favour of #272. |
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.
An idle reactor sleeps in
io_uring_enteruntil a completion arrives, and the only one it can count on is the 250 ms ticker. So a QUIC retransmit, ACK or pacing step due in a few ms waited for the next tick. #267 made the deadline correct; nothing woke the loop for it.This bounds the loop's wait by the earliest engine deadline (
IORING_ENTER_EXT_ARGwith a timeout). The 250 ms timer and the sweeps are untouched, and a reactor with no pending QUIC deadline (every TCP-only reactor) makes the same unbounded wait as before.One of two alternatives - the other is #272, which also replaces the timer. Merge one, close the other.
Tests
quic/timer: an idle reactor fires an engine deadline when it is due, not at the next tick: the answer is lost and the peer stays silent, so the retransmit timer fires again and again; each firing is timed against the engine's own ns deadline.[146, 233, 22, 44, 89],[144, 226, 13, 26, 52]ms)quic/timer: a reactor whose last connection is gone does not keep waking for it: nothing resets the tracked deadline when the last connection leaves, so the wait ignores it then. Without that guard the empty reactor woke 996 times/s.quic/timer: a deadline that is already due is reported as due…needed the loop to notice a deadline 2 ms late, which it no longer does; any amount past now counts (the clock only moves forward).All suites pass, pending lists unchanged from main: E2E 233, Unit 60, Chaos 47, Http 44, Tls 151 (the 7 kTLS tests skip without sudo), File 4.
Bench
Interleaved: 5 rounds of 10 s per sample in rotating order, 2 reactors pinned to the P-cores.
controlis a second build of main, so its delta is the noise floor. Medians against main, req/s · CPU per request:Every delta is inside the control's own spread, so neither design costs anything measurable under load. Idle reactors wake 4.0-4.2 times/s on main and both PRs alike (the 250 ms tick), for TCP and for QUIC after a 1.35M-request h3 burst has ended.
Size:
src+62 −17 in 9 files.