4 ms·

The bandwidth delay product for a 10Gbps stream for a 300ms RTT theoretically only requires ~384MB One option is just to simply keep buffers small and fixed an

by nly 7mo ago

The bandwidth delay product for a 10Gbps stream for a 300ms RTT theoretically only requires ~384MB One option is just to simply keep buffers small and fixed and disconnect blocked clients on write() after some timeout

fulafel 7mo ago
We're up to hundreds of gbps per server, have been for some years now. Eg 400 gbps uses a lot even with much smaller avg rtt. That's not going ng to be one stream of course, but a zillion smaller streams still add up to the same reqs. This is far from little embedded device territory of course. But still, latest wifi is closer to 10 than 1 gbps already.
- Veserv 7mo ago
  I do not understand the point you are trying to make. The person you replied to showed how to evaluate it with simple math. 400 Gb/s is 50 GB/s. RTT of 300 ms would only require 15 GB of buffers. That would not even run a regular old laptop out of memory let alone a server driving 400 Gb/s of traffic. That would be single-digit percents to possibly even sub-percent amounts of memory on such a server.
  - fulafel 7mo ago
    I introduced the concept of bandwidth * delay product to the conversation... The question was about why use dynamic allocation. In this branch of the thread we ere discussing the question "Are there TCP/IP stacks out there in common use that are allocating memory all the time?" We'd not be happy to see the server or laptop statically reserving this worst-case amount of memory for TCP buffers, when it's not infact slinging around max nr of tcp connections, each with worst-case bandwidth*delay product. Nor would be happy if the laptop or server only supported little tcp windows that limit performance by capping the amount of data in-flight to a low number. We are happier if the TCP stack dynamically allocates the memory as needed, just like we're happier with dynamic allocation on most other OS functions.

by nly 7mo ago

fulafel 7mo ago

We're up to hundreds of gbps per server, have been for some years now. Eg 400 gbps uses a lot even with much smaller avg rtt. That's not going ng to be one stream of course, but a zillion smaller streams still add up to the same reqs. This is far from little embedded device territory of course. But still, latest wifi is closer to 10 than 1 gbps already.

Veserv 7mo ago
I do not understand the point you are trying to make. The person you replied to showed how to evaluate it with simple math. 400 Gb/s is 50 GB/s. RTT of 300 ms would only require 15 GB of buffers. That would not even run a regular old laptop out of memory let alone a server driving 400 Gb/s of traffic. That would be single-digit percents to possibly even sub-percent amounts of memory on such a server.
- fulafel 7mo ago
  I introduced the concept of bandwidth * delay product to the conversation... The question was about why use dynamic allocation. In this branch of the thread we ere discussing the question "Are there TCP/IP stacks out there in common use that are allocating memory all the time?" We'd not be happy to see the server or laptop statically reserving this worst-case amount of memory for TCP buffers, when it's not infact slinging around max nr of tcp connections, each with worst-case bandwidth*delay product. Nor would be happy if the laptop or server only supported little tcp windows that limit performance by capping the amount of data in-flight to a low number. We are happier if the TCP stack dynamically allocates the memory as needed, just like we're happier with dynamic allocation on most other OS functions.