summaryrefslogtreecommitdiffhomepage
path: root/test/cmd
diff options
context:
space:
mode:
authorBhasker Hariharan <bhaskerh@google.com>2020-07-30 14:44:34 -0700
committergVisor bot <gvisor-bot@google.com>2020-07-30 14:46:49 -0700
commitf15d5a8d0fe4ad7d072909e7957977756f7be118 (patch)
tree4c245840b8d849ceac12e3d6fd216c388b7de885 /test/cmd
parent9960a816a9ad65a4a6620eee5a66e5cc071b60cb (diff)
Revert change to default buffer size.
In https://github.com/google/gvisor/commit/ca6bded95dbce07f9683904b4b768dfc2d4a09b2 we reduced the default buffer size to 32KB. This mostly works fine except at high throughput where we hit zero window very quickly and the TCP receive buffer moderation is not able to grow the window. This can be seen in the benchmarks where with a 32KB buffer and 100 connections downloading a 10MB file we get about 30 requests/s vs the 1MB buffer gives us about 53 requests/s. A proper fix requires a few changes to when we send a zero window as well as when we decide to send a zero window update. Today we consider available space below 1MSS as zero and send an update when it crosses 1MSS of available space. This is way too low and results in the window staying very small once we hit a zero window condition as we keep sending updates with size barely over 1MSS. Linux and BSD are smarter about this and use different thresholds. We should separately update our logic to match linux or BSD so that we don't send window updates that are really tiny or wait until we drop below 1MSS to advertise a zero window. PiperOrigin-RevId: 324087019
Diffstat (limited to 'test/cmd')
0 files changed, 0 insertions, 0 deletions