On Fri, Apr 16, 2021 at 08:30:46AM +0200, Claudio Jeker wrote: > Wonder if something else is still amiss.
What you see in this graph is the single connection TCP througput during 6.8 development. The tcpbench output of the sender has been measured. http://bluhm.genua.de/perform/results/gnuplot/6.8-tcp_6.png About 3x10^9 GBit/sec is regular throughput since 6.8 release. It drops to 5x10^8 when delay more than 2 ACKs was added at the receiving side. Removing maxburst at the sender makes it go up to 4x10^9. The final data point between 3x10^9 and 3.5x10^9 is when delay more than 2 ACKs was backed out. An interesting thing is the sparse area of slow throughput on the right quarter of the graph. It seems that although aggessivly delayed ACK and no maxburst is usually fast, throughput randomly drops down between 1.5x10^9 and 4x10^9. Maybe this is caused by lost ACKs that are not immediately retransmitted. So we have issues with full window if the socket buffer is extremly small and spontaneous performance drops. If we could solve those it would be great to get back the 20% improvement until 7.0 release. bluhm
