On Mon, Nov 15, 2010 at 02:14:26AM +1300, Ben Aitchison wrote: > On Sat, Nov 06, 2010 at 03:47:54PM +0100, Claudio Jeker wrote: > > On Sat, Nov 06, 2010 at 02:13:46PM +0100, Jan Stary wrote: > > > For some time now, I have been using the following sysctl's > > > mentioned in FAQ 6.6.4, which sped up my network traffic > > > considerably: > > > > > > net.inet.tcp.recvspace > > > net.inet.tcp.sendspace > > > net.inet.udp.recvspace > > > net.inet.udp.sendspace > > > > > > Now that I have reinstalled with current/amd64, the tcp ones > > > seem to have disappeared (while the udp ones are still there). > > > > > > Am I missing something? > > > > > > > No. The TCP ones are gone, enjoy fast downloads without pushing buttons. > > The automatic TCP windowscaling in -current makes the global tcp.recvspace > > and tcp.sendspace superfluous. > > > I've found that receiving traffic from Linux hosts with timestamps turned > off has decreased in performance with the new window scaling. Is this because > the RTT cannot be determined. Or an oversight?
Yes, we need timestamps to be able to figure out the RTT. The current receive window scaling algorithm is built that way. > The thing is in general timestamps don't seem to improve things a lot, and > take > up an extra 12 bytes if you're otherwise not using TCP options. Timestamps are needed for PAWS and are needed for high speed TCP connections. Embrace the 12 extra bytes, they will not hurt you. > I was doing tcpdumps etc, and found that basically the window size doesn't > raise > above 16k like the old default. But in general I've been setting TCP window > size > manually for a long time. Yes, if the timestamps are not available the window will not scale. Again this is a limitation of the current implementation and I'm happy if someone comes up with a version that does not rely on timestamps. > I also noticed that now OpenBSD seems to be faster at sending data than Linux > to > my home ADSL link from a closeish connection. :) > > Also I was wondering if making the initial cwnd window size be tunable as been > taken into consideration. As well as being able to run-time tune the maximum > window size above 256k. (or below) Bigger initial window sizes is something that we should think about. Currently the default is to send up to around 3 packets. Or to be more precise OpenBSD uses RFC 3390 by default (sysctl net.inet.tcp.rfc3390). There is some discussion to increase the initial window even more, which is nice for systems connected to a high speed line but it may cause queuing issues on slower links (gprsi/edge, slow ADSL lines, etc) where the router suddenly needs to hold a lot more packages to manage this initial burst (from probably multiple sessions). But be assured that if I change the initial window size or maximum socket buffer size then I will probably remove some more knobs to fiddle with. Letting users push buttons based on bad blog entries they found on the internet is a sign of developers taking no responsibility for their code. > I poked around in the source a little. And I noticed that I could tune > maximum > window size up to 1024k and could change the minimum window size up. But I > am at > a loss to understand if it's possible to use > 64k window size on hosts > without > timestamps (because I saw the window size set being advertised directly > before it > is known whether there was window scaling or not) and whether memory pressure > could lead to issues from bigger buffers. ie does something else have to be > raised assuming one has sufficient memory and bandwidth/latency. For now we keep the old limit of 256k maximum socket buffer size. The increased memory consumption because of the bigger socket buffers is something that may run systems out of memory and so we decided to keep the current value until the effect of windowscaling are known. While it may be OK for a workstation to have huge socket buffers it is most probably causing issues on servers. Yes, OpenBSD could scale way more aggressive and be more instable because of this but I prefer a reliable and working system. > In my own testing I noticed a speed jump from 14 to 31 megabit going from a > 256k > to 1024k maximum window size. Which to me seems significant. Sure you can increase the maximum socket buffer size but by doing so you void your warranty :). -- :wq Claudio
