You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After moving MAX_TRANSMIT_SEGMENTS limitation from quinn-proto to quinn in #2185 , I'd like to understand if it's possible to relax it, by either increasing it or dropping.
This issue was created to follow up on this discussion and decide the path forward. Are there any benchmarks on the subject? I suspect at a minimum we want to:
Test a range of values for it: 10,30,60...
Test in the major supported platforms
Possibly test it with different MTU sizes? 1200, 1500(ethernet), but also testing with Jumbo frames?
What's the data we want to collect? Possbily:
Throughput
Latency
Error rate
The text was updated successfully, but these errors were encountered:
Another interesting variable is memory use. Each connection has a send buffer that may grow as required to fit a GSO batch. If e.g. a Windows server, capable of 512-datagram GSO batches, has a large number of concurrent connections, each of which at some point requests a large amount of data, then the worst-case memory use might add up more than users expect.
After moving MAX_TRANSMIT_SEGMENTS limitation from quinn-proto to quinn in #2185 , I'd like to understand if it's possible to relax it, by either increasing it or dropping.
This issue was created to follow up on this discussion and decide the path forward. Are there any benchmarks on the subject? I suspect at a minimum we want to:
What's the data we want to collect? Possbily:
The text was updated successfully, but these errors were encountered: