these folk do good work, and I loved the graphs
https://blog.cloudflare.com/unbounded-memory-usage-by-tcp-for-receive-buffers-and-how-we-fixed-it/
Very cool. Thanks for sharing.
I've been considering adding stress tests to iperf 2. Looks like
Cloudfare has at least two
Small reads & writes with short delay to stress receive window
processing per
At the sending host, run a TCP program with an infinite loop, sending
1500B packets, with a 1 ms delay between each send.
At the receiving host, run a TCP program with an infinite loop,
reading 1B at a time, with a 1 ms delay between each read.
And then, rx buffer limit tests, from
https://blog.cloudflare.com/optimizing-tcp-for-high-throughput-and-low-latency/
reads as fast as it can, for five seconds this is called fast mode,
opens up the window
calculates 5% of the high watermark of the bytes reader during any
previous one second
for each second of the next 15 seconds: this is called slow mode
reads that 5% number of bytes, then stops reading
sleeps for the remainder of that particular second
most of the second consists of no reading at all
steps 1-3 are repeated in a loop three times, so the entire run is 60
seconds
This has the effect of highlighting any issues in the handling of
packets when the buffers repeatedly hit the limit.
Curious about any other traffic scenarios driven by socket read/write
behaviors that could be useful. Or any others that might apply to WiFi
aggregation.
Then, if there is a way to generalize these types of send/read/delay
graphs with a parametric command line?
Bob
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
