On Sun, Feb 01, 2009 at 02:26:52PM +0000, Dieter wrote: > [ replying here because gmail is broken ] > > > > How high is too high? I have a utility that sets recv buf size > > > to 100,000,000 and it works fine on FreeBSD and NetBSD. (Not > > > tested yet on OpenBSD.) Necessary when the other end has buggy > > > network code and insufficient send buf. > > > > Could you clarify what you mean by that? > > Black box sends data to BSD box using TCP. Data is generated in > real time, the rate cannot be changed. Black box has a very small > (way too small) send buffer. If the BSD box takes too long to > ack, the black box's send buffer fills up and data is lost, > and/or black box's buggy firmware screws up and data is lost. > So I have to do everything I can to ensure that incoming packets > do not get dropped, and that the acks get sent out as fast as > possible. Making the TCP recv buffer very large allows the > incoming packets to get stored and acked, even if the userland > process reading the data doesn't get to run often enough. Even > so, there is still the problem that other device drivers can and > do lock out the Ethernet driver for too long. Still working on > that problem. What we really need is true real time facilities. > > It is a latency problem, not a throughput problem. If the black > box were FLOSS instead of evil closed source it should be possible > to fix the buggy network code. >
A) huge recv buffer does not solve your ACK problem. B) recv buffer is only affected by either the global net.inet.tcp.recvspace or the setsockopt SO_RCVBUF. C) the socketbuffers are limmited to 256kB D) Instead of playing with knobs that don't realy do what you think they will do you should make your userland app read faster. -- :wq Claudio
