On Sunday, December 4, 2011 21:01 CET, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > Date: Sun, 4 Dec 2011 15:10:56 +0100 > > From: Claudio Jeker <cje...@diehard.n-r-g.com> > > > > On Sun, Dec 04, 2011 at 01:35:33PM +0100, Sebastian Reitenbach wrote: > > > On Sunday, December 4, 2011 13:24 CET, Camiel Dobbelaar <c...@sentia.nl> > > > wrote: > > > > > > > On 4-12-2011 13:01, Sebastian Reitenbach wrote: > > > > > the default maximum size of the tcp send and receive buffer used by > > > > > the autosizing algorithm is way too small, when trying to get maximum > > > > > speed with high bandwidth and high latency connections. > > > > > > > > I have tweaked SB_MAX on a system too, but it was for UDP. > > > > > > > > When running a busy Unbound resolver, the recommendation is too bump the > > > > receive buffer to 4M or even 8M. See > > > > http://unbound.net/documentation/howto_optimise.html > > > > > > > > Otherwise a lot of queries are dropped when the cache is cold. > > > > > > > > I don't think there's a magic value that's right for everyone, so a > > > > sysctl would be nice. Maybe separate ones for tcp and udp. > > > > > > > > I know similar sysctl's have been removed recently, and that they are > > > > sometimes abused, but I'd say we have two valid use cases now. > > > > > > > > So I'd love some more discussion. :-) > > > > > > since they were removed, and there is this keep it simple, and too many > > > knobs are bad attitude, which I think is not too bad, I just bumped the > > > SB_MAX value. > > > If there is consensus that a sysctl would make sense, I'd also look into > > > that approach and send new patch. > > > > SB_MAX is there to protect your system. It gives a upperbound on how much > > memory a socket may allocate. The current value is a compromize. Running > > with a huge SB_MAX may make one connection faster but it will cause > > resource starvation issues on busy systems. > > Sure you can bump it but be aware of the consequneces (and it is why I > > think we should not bump it at the moment). A proper change needs to > > include some sort of resource management that ensures that we do not run > > the kernel out of memory. > > But 256k simply isn't enough for some use cases. Turning this into a > sysctl tunable like FreeBSD and NetBSD would be a good idea if you ask > me. Yes, people will use it to shoot themselves in the foot. I don't > care.
So to be able to shoot myself in the foot without the need to compile the kernel, I'll look into adding a sysctl to tweak the maximum size of the buffer. Well, depending on time and how fast I figure out how to do that, might take some time. Sebastian
