Date: Sun, 18 Jun 2000 15:03:28 -0400 (EDT) From: "Richard A. Steenbergen" <ras@e-gerbil.net> To: freebsd-net@freebsd.org Subject: Auto-scaling socket buffers Message-ID: <Pine.BSF.4.21.0006181443030.95120-100000@pkitty.e-gerbil.net>
next in thread | raw e-mail | index | archive | help
PREAMBLE: I had an interesting thought. As we all know, thruput is a product of bandwidth and delay, and achieving high thruput across high latency high bandwidth pipes is accomplished by using large TCP windows to keep sufficient packets in flight while awaiting ACKs (see rfc1323). Maximium TCP window size is limited by socket buffer size, which by default is set to 16k each in send and recv direction (net.inet.ip.sendspace/recvspace), changable by setsockopt() SO_SNDBUF SO_RCVBUF, up to a maximium of 256k total for BOTH buffers (kern.ipc.maxsockbuf). The maximium value for a TCP window without using rfc1323 window scaling is 2**16 (64k) as limited by the window field in the tcp header. An application expecting to do high performance transfers should consider increasing this value on the data sockets (ftp/ftpd for example, which currently does not do this). Even Linux has caught on and now defaults to 64k buffers with rfc1323 features enabled by default. Unfortunantly one of the arguements against simply increasing the default to something like 64k (or higher, I increase my maxsockbuf and send/recv space to 256k in each direction for good transfer speeds from europe to the USA), is that it reserves this much buffer memory in sbreserve() calls for every socket. For some sockets this is an absurdly high number (for example, an irc server with 10,000 client sockets which would probably be quite content at 4k, and a few server sockets which need to eat a connect burst quickly, though this is a poor example because any such sane server should be doing this itself), and wastes memory. IDEA: Which leads to my idea. Automatically scale the socket buffer when the TCP window is exausted and the reason it cannot be extended is the sockbuf. This would allow the default recvspace/sendspace to be set to something like 4k, but still allow performance sockets to quickly scale upwards to a set limit, to achieve maximium thruput. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006181443030.95120-100000>