Thor Lancelot Simon <tls%panix.com@localhost> writes: > Why the automatic socket buffer sizing code isn't bringing the socket > buffer size and thus the window size up to 128K by itself over the course > of a 10GB test is not obvious to me. Either it's buggy, or it isn't > causing the window scaling option to be used (in other words, it's buggy), > I think has to be the answer. I have been checking TCP throughput on 15+ Mb/s links with ~35ms delay and it was immediately apparent that the default window needed to be bigger to max out the link. I use tcpdump to record the traffic and then tcpdump2xplot (in xplot, which is in pkgsrc) to visualize the TCP connection. It's obvious from the sender-side trace that the sender becomes limited by its notion of the receiver's available window. Then, I turned on automatic buffer tuning, and it seemed that it took a long time for the receiver buffer to open up. Looking at receiver-side plots, I found it very unobvious how this ought to work - at the receiver, the window is almost always close to empty. I didn't get to looking at the code, but I would expect that it would have to measure receive data rate and RTT and try to adapt to that - the key point is that the receiver has to open up the window so the transmitter isn't constrained, which I think means more than data_in_flight * RTT. It would be nice if there were an explanation of how this is supposed to work in the man page, or a pointer to a paper.
Attachment:
pgpolTYkIOOE6.pgp
Description: PGP signature