Summary: SOCKET_BUFFER_SIZE was 32 KiB, which caps a single TCP connection
at roughly 1 MB/s over a typical internet path regardless of the available
bandwidth.
Details:
The receive buffer size is the upper bound on the window a socket can
advertise, and a TCP connection cannot go faster than window / RTT. At the
old 40968 = 32 KiB, a path with a 32 ms round trip is limited to about
1 MB/s no matter how fast the link underneath is. Raising the buffer to
409632 = 128 KiB moves that ceiling to roughly 4 MB/s on the same path.
Nothing else needs adjusting: request_r_scale is derived from
SOCKET_BUFFER_SIZE in tcp_usreq, so the window scale we request grows with
the buffer automatically, and both tcp_output and tcp_respond clamp the
scaled value to the 16-bit header field. The constant keeps satisfying the
documented requirement of 4096*(power of two >= 8).
The cost is memory: each stream socket maps a send and a receive ring, so a
TCP socket now reserves 256 KiB of physical memory instead of 64 KiB (and
twice that in address space, since the rings are mirror-mapped). For a
browser holding a handful of connections open this is a few megabytes.
Summary: SOCKET_BUFFER_SIZE was 32 KiB, which caps a single TCP connection
at roughly 1 MB/s over a typical internet path regardless of the available
bandwidth.
Details:
The receive buffer size is the upper bound on the window a socket can
advertise, and a TCP connection cannot go faster than window / RTT. At the
old 4096*8 = 32 KiB, a path with a 32 ms round trip is limited to about
1 MB/s no matter how fast the link underneath is. Raising the buffer to
4096*32 = 128 KiB moves that ceiling to roughly 4 MB/s on the same path.
Nothing else needs adjusting: request_r_scale is derived from
SOCKET_BUFFER_SIZE in tcp_usreq, so the window scale we request grows with
the buffer automatically, and both tcp_output and tcp_respond clamp the
scaled value to the 16-bit header field. The constant keeps satisfying the
documented requirement of 4096*(power of two >= 8).
The cost is memory: each stream socket maps a send and a receive ring, so a
TCP socket now reserves 256 KiB of physical memory instead of 64 KiB (and
twice that in address space, since the rings are mirror-mapped). For a
browser holding a handful of connections open this is a few megabytes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Summary: SOCKET_BUFFER_SIZE was 32 KiB, which caps a single TCP connection
at roughly 1 MB/s over a typical internet path regardless of the available
bandwidth.
Подробно:
The receive buffer size is the upper bound on the window a socket can
advertise, and a TCP connection cannot go faster than window / RTT. At the
old 4096*8 = 32 KiB, a path with a 32 ms round trip is limited to about
1 MB/s no matter how fast the link underneath is. Raising the buffer to
4096*32 = 128 KiB moves that ceiling to roughly 4 MB/s on the same path.
Nothing else needs adjusting: request_r_scale is derived from
SOCKET_BUFFER_SIZE in tcp_usreq, so the window scale we request grows with
the buffer automatically, and both tcp_output and tcp_respond clamp the
scaled value to the 16-bit header field. The constant keeps satisfying the
documented requirement of 4096*(power of two >= 8).
The cost is memory: each stream socket maps a send and a receive ring, so a
TCP socket now reserves 256 KiB of physical memory instead of 64 KiB (and
twice that in address space, since the rings are mirror-mapped). For a
browser holding a handful of connections open this is a few megabytes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Again, too much comments.
I suggest to remove all new comments as they have no real statistical proof.
Regarding the change itself, I can accept it, but we should perform some tests in the future if the extra memory usage is justified on lower end systems.
We can make a new issue for that as a future work.
Again, too much comments.
I suggest to remove all new comments as they have no real statistical proof.
Regarding the change itself, I can accept it, but we should perform some tests in the future if the extra memory usage is justified on lower end systems.
We can make a new issue for that as a future work.
hidnplayr
self-assigned this 2026-08-01 08:57:43 +00:00
Again, too much comments.
I suggest to remove all new comments as they have no real statistical proof.
Regarding the change itself, I can accept it, but we should perform some tests in the future if the extra memory usage is justified on lower end systems.
We can make a new issue for that as a future work.
Comments cleared.
> Again, too much comments.
> I suggest to remove all new comments as they have no real statistical proof.
>
> Regarding the change itself, I can accept it, but we should perform some tests in the future if the extra memory usage is justified on lower end systems.
> We can make a new issue for that as a future work.
Comments cleared.
Leency
requested review from hidnplayr 2026-08-03 18:09:18 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
hidnplayr
Summary: SOCKET_BUFFER_SIZE was 32 KiB, which caps a single TCP connection
at roughly 1 MB/s over a typical internet path regardless of the available
bandwidth.
Details:
The receive buffer size is the upper bound on the window a socket can
advertise, and a TCP connection cannot go faster than window / RTT. At the
old 40968 = 32 KiB, a path with a 32 ms round trip is limited to about
1 MB/s no matter how fast the link underneath is. Raising the buffer to
409632 = 128 KiB moves that ceiling to roughly 4 MB/s on the same path.
Nothing else needs adjusting: request_r_scale is derived from
SOCKET_BUFFER_SIZE in tcp_usreq, so the window scale we request grows with
the buffer automatically, and both tcp_output and tcp_respond clamp the
scaled value to the 16-bit header field. The constant keeps satisfying the
documented requirement of 4096*(power of two >= 8).
The cost is memory: each stream socket maps a send and a receive ring, so a
TCP socket now reserves 256 KiB of physical memory instead of 64 KiB (and
twice that in address space, since the rings are mirror-mapped). For a
browser holding a handful of connections open this is a few megabytes.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Again, too much comments.
I suggest to remove all new comments as they have no real statistical proof.
Regarding the change itself, I can accept it, but we should perform some tests in the future if the extra memory usage is justified on lower end systems.
We can make a new issue for that as a future work.
Comments cleared.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.