On Thu, Apr 15, 2021 at 08:43:02PM +0200, Alexander Bluhm wrote: > Hi, > > I found another regression with Jan's TCP diff that sends less ACK > packets. relayd run-args-http-slow-consumer.pl fails on i386 due > to his commit. This test writes a lot of data from the http server, > but blocks receive for 2 seconds in the client. Relayd between > these machines should handle the delay. The socket buffer size is > very small to trigger the situation reliably. > > The current TCP stack does not recover after the delay. Packets > are sent very slowly and the regress test runs in a timeout. When > I backout the change, the test passes quickly. > > Ususally the test runs on localhost loopback. There the problem > is not triggered. Only my i386 regress setup uses a remote machine. > > As Jan's change send less ACKs that have to be handled, throughput > increases when TCP/IP stack is CPU bound. This can give a 20% > increase. > > Due to the maxburst limitation, throughput may also drop by 70% on > a single connection. I have removed this limitation, so it does > not happen if the other side is a current OpenBSD. But TCP connection > between -current and 6.8 can run into this problem. > > Now I have found another corner case in a regress test where we get > only 10 TCP packets per second. But that may be the result of > unrealistic settings of the socket buffer size. > > Should we back it out for release? Diff below.
I don't mind the revert. It is a bit of a you win a little you lose a little. What surprises me is that other systems behave very similar to what we did in OpenBSD (reducing the amount of acks sent) and nobody complains there. Wonder if something else is still amiss. -- :wq Claudio
