-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Add confirmed
parameter to PTO calculation
#2127
Conversation
Rather than having the caller determine for which space a PTO should be calculated for. Broken out of mozilla#1998 I'm ambivalent if we want this change - thoughts?
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2127 +/- ##
==========================================
- Coverage 95.35% 95.35% -0.01%
==========================================
Files 112 112
Lines 36336 36345 +9
==========================================
+ Hits 34648 34656 +8
- Misses 1688 1689 +1 ☔ View full report in Codecov by Sentry. |
Benchmark resultsPerformance differences relative to 55e3a93. coalesce_acked_from_zero 1+1 entries: 💚 Performance has improved.time: [98.978 ns 99.269 ns 99.563 ns] change: [-12.709% -12.336% -11.979%] (p = 0.00 < 0.05) coalesce_acked_from_zero 3+1 entries: 💚 Performance has improved.time: [116.83 ns 117.20 ns 117.63 ns] change: [-33.546% -33.254% -32.939%] (p = 0.00 < 0.05) coalesce_acked_from_zero 10+1 entries: 💚 Performance has improved.time: [116.38 ns 116.76 ns 117.23 ns] change: [-39.822% -35.573% -33.013%] (p = 0.00 < 0.05) coalesce_acked_from_zero 1000+1 entries: 💚 Performance has improved.time: [97.621 ns 97.771 ns 97.941 ns] change: [-31.759% -31.169% -30.586%] (p = 0.00 < 0.05) RxStreamOrderer::inbound_frame(): No change in performance detected.time: [111.38 ms 111.50 ms 111.66 ms] change: [-0.0092% +0.1054% +0.2449%] (p = 0.13 > 0.05) transfer/pacing-false/varying-seeds: No change in performance detected.time: [26.606 ms 27.769 ms 28.976 ms] change: [-8.0355% -2.8408% +2.6457%] (p = 0.32 > 0.05) transfer/pacing-true/varying-seeds: No change in performance detected.time: [34.924 ms 36.626 ms 38.361 ms] change: [-10.279% -4.3825% +1.8437%] (p = 0.18 > 0.05) transfer/pacing-false/same-seed: No change in performance detected.time: [25.499 ms 26.282 ms 27.076 ms] change: [-7.7842% -3.8988% +0.4373%] (p = 0.07 > 0.05) transfer/pacing-true/same-seed: No change in performance detected.time: [41.540 ms 43.588 ms 45.658 ms] change: [-6.8337% -0.3259% +6.0094%] (p = 0.92 > 0.05) 1-conn/1-100mb-resp (aka. Download)/client: 💚 Performance has improved.time: [113.54 ms 113.93 ms 114.31 ms] thrpt: [874.80 MiB/s 877.75 MiB/s 880.78 MiB/s] change: time: [-2.1535% -1.7221% -1.3254%] (p = 0.00 < 0.05) thrpt: [+1.3432% +1.7523% +2.2009%] 1-conn/10_000-parallel-1b-resp (aka. RPS)/client: Change within noise threshold.time: [309.21 ms 312.90 ms 316.58 ms] thrpt: [31.588 Kelem/s 31.960 Kelem/s 32.341 Kelem/s] change: time: [-3.9150% -2.3280% -0.6881%] (p = 0.01 < 0.05) thrpt: [+0.6929% +2.3835% +4.0745%] 1-conn/1-1b-resp (aka. HPS)/client: No change in performance detected.time: [33.663 ms 33.828 ms 34.009 ms] thrpt: [29.404 elem/s 29.562 elem/s 29.706 elem/s] change: time: [-0.4931% +0.2593% +0.9745%] (p = 0.49 > 0.05) thrpt: [-0.9650% -0.2587% +0.4955%] Client/server transfer resultsTransfer of 33554432 bytes over loopback.
|
Failed Interop TestsQUIC Interop Runner, client vs. server neqo-latest as client
neqo-latest as server
All resultsSucceeded Interop TestsQUIC Interop Runner, client vs. server neqo-latest as client
neqo-latest as server
Unsupported Interop TestsQUIC Interop Runner, client vs. server neqo-latest as client
neqo-latest as server
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes make sense to me. Only one question related to tests.
@martinthomson I'd appreciate a review, since the code I am touching is pretty complex. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this one. It's a simplification for the most part.
(There's some duplication of state information between Connection and the loss recovery stuff, but that seems necessary. The meaning is consistent.)
Merge failure due to #2141. |
Rather than having the caller determine for which space a PTO should be calculated for.
Also arm PTOs in the application packet number space before the handshake is complete, so 0-RTT gets RTX'ed.
Broken out of #1998