On Wed, Feb 03, 2021 at 11:20:04AM +0100, Claudio Jeker wrote: > Just commit it. OK claudio@ > If people see problems we can back it out again.
This has huge impact on TCP performance. http://bluhm.genua.de/perform/results/2021-02-07T00%3A01%3A40Z/perform.html For a single TCP connection between to OpenBSD boxes, througput drops by 77% from 3.1 GBit/sec to 710 MBit/sec. But with 100 parallel connections the througput over all increases by 5%. Sending from Linux to OpenBSD increases by 72% from 3.5 GBit/sec to 6.0 GBit/sec. Socket splicing from Linux to Linux via OpenBSD with 10 parallel TCP connections increases by 25% from 3.5 GBit/sec from 1.8 GBit/sec to 2.3 GBit/sec. It seems that sending less ACK packets improves performance if the machine is limited by the CPU. But the TCP stack of OpenBSD is sending 77% percent slower, if it does not receive enough ACKs. This has no impact if we are measuring the combined througput of many parallel connections. The Linux packet sending algorithm looks unaffected by our more delayed acks. I think 77% slower between two OpenBSDs is not acceptable. Do others see that, too? bluhm