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;