here is the patch i have ended up using since the removal of the tcp sysctls. if something doesn't change, 4.9 will be an embarrassingly bad regression in network performance. at least with prevous releases, bumping the recvspace was an available workaround to sucky performance, but now the speedometer is permanently fixed at "balls".
i have tried fiddling with the tp->rfbuf_cnt > so->so_rcv.sb_hiwat / 8 * 7 formula to no avail. my test link is ~6Mbit with ping times varying between 100 and 500ms. so basically, i get my piddly 16K, tick tock, tick tock, and then the counter is reset to 0 again. i can never get more than about 100K/s speeds, even after *hours* of downloading over the same connection. performance improves to close to 600K/s with patch, which is about as good as it gets. i know we aren't going to just crank the recvbuf to the max, so the patch is really just for show, but at the very least, please bring back some level of user control over recvbuf size. [the bump to autorcvbuf_inc doesn't do much, i know, that's left over from trying recvbuf smaller than the max]. Index: tcp_usrreq.c =================================================================== RCS file: /home/tedu/cvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.105 diff -u -r1.105 tcp_usrreq.c --- tcp_usrreq.c 10 Oct 2010 22:02:50 -0000 1.105 +++ tcp_usrreq.c 2 Dec 2010 01:18:28 -0000 @@ -112,14 +112,14 @@ extern struct baddynamicports baddynamicports; #ifndef TCP_SENDSPACE -#define TCP_SENDSPACE 1024*16 +#define TCP_SENDSPACE 1024*64 #endif u_int tcp_sendspace = TCP_SENDSPACE; #ifndef TCP_RECVSPACE -#define TCP_RECVSPACE 1024*16 +#define TCP_RECVSPACE 1024*256 #endif u_int tcp_recvspace = TCP_RECVSPACE; -u_int tcp_autorcvbuf_inc = 16 * 1024; +u_int tcp_autorcvbuf_inc = 64 * 1024; int *tcpctl_vars[TCPCTL_MAXID] = TCPCTL_VARS;
