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

Reply via email to