Dave Huang <khym%azeotrope.org@localhost> writes: > On Mon, Aug 03, 2015 at 08:26:31AM -0400, Greg Troxel wrote: >> I have not actually read the code, but I am 99% sure that the window is >> only increased if there are signs that it isn't big enough. That's >> complicated but the key point is that the connection has to be up >> against the window, rather than congestion. > > The code in question seems to be in sys/netinet/tcp_input.c, around > line 2072. The comment says: > > * The criteria to step up the receive buffer one notch are: > * 1. the number of bytes received during the time it takes > * one timestamp to be reflected back to us (the RTT); > * 2. received bytes per RTT is within seven eighth of the > * current socket buffer size; > * 3. receive buffer size has not hit maximal automatic size; > > It seems like those criteria should be met... I haven't tried adding > printfs or something in the series of "if"s to see whether it's making > it all the way to the block that increases the size, and if not, which > check is failing. That more or less makes sense for the criteria. >> Hmm. I was expecting to get to this point and suspect packet loss and >> tell you to run "xplot" (in pkgsrc) which lets you visualize the >> ack/etc. behavior. > > I used xplot a long time ago, but can't get it working now... > tcpdump2xplot complains about "Malformed entry in dump file". I found > http://mail-index.netbsd.org/current-users/2004/11/30/0010.html which > suggests removing the string " IP" from the tcpdump output, but that > didn't help: > > tcpdump2xplot: Malformed entry in dump file :1 "1438577662.919916 > 52.74.238.147.36628 > 10.1.1.73.22: Flags [S], seq 3042363803, win > 26883, options [mss 8961,sackOK,TS val 17717649 ecr 0,nop,wscale 7], > length 0" I should have pointed you to xplot-devel. (I need to straighten that out sometime...). > Actually, I think I used tcptrace last time instead of > tcpdump2xplot... I'm not very proficient at interpreting these graphs, > but I think I know the basics, and I think it confirms that the window > size is too small and that the autosizing should increase the size. > You can take a look at http://www.azeotrope.org/~khym/pics/tsg1.png > and http://www.azeotrope.org/~khym/pics/tsg1_zoomed.png Those plots look pretty much the same. >> > If I increase net.inet.tcp.recvspace to 4194304, the scp connects and >> > does the ssh protocol handshake (according to "scp -v"), but the data >> > transfer never actually starts... no idea what that means. If I set >> >> I wonder if there is a 32-bit bug someplace. I would try a number that >> fits in 31 bits. > > I set it to 4MB, not 4GB... Indeed - and then I have no other ideas. > http://www.azeotrope.org/~khym/pics/tsg2.png and > http://www.azeotrope.org/~khym/pics/tsg2_zoomed.png > > I don't really know how to interpret this one, but it doesn't seem > like there's was any packet loss/retransmission. If that's at the sender, it seems to show packets being sent and the window line being far away. I do see what looks like dupacks (downward green tick). I guess trying to debug/check the receive window growth code is in order. It's certainly possible there has been a bug in that ~forever.
Attachment:
pgpuLKJlfaAvo.pgp
Description: PGP signature