Date: Fri, 9 Jan 2004 20:47:32 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Andre Oppermann <andre@freebsd.org> Cc: Nate Lawson <nate@root.org> Subject: Re: cvs commit: src/sys/netinet ip_icmp.c tcp.h tcp_input.c tcp_subr.ctcp_usrreq.c tcp_var.h Message-ID: <20040109204457.A1453@odysseus.silby.com> In-Reply-To: <3FFF0F5B.31185EA3@freebsd.org> References: <200401081740.i08He8J9063202@repoman.freebsd.org> <3FFEAFC2.8070303@freebsd.org> <3FFEB449.1C32B5FD@freebsd.org> <36749.158.6.15.27.1073658317.squirrel@webmail.pair.com> <3FFEBBC9.A42EDC25@freebsd.org> <20040109095640.G40628@root.org> <3FFF0F5B.31185EA3@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 9 Jan 2004, Andre Oppermann wrote: > > Perhaps you didn't understand Mike? You don't care if TCP_NODELAY is set > > on their side, all you care about is the packet equilibrium. If you send > > data in response to receiving a segment, the net equilibrium is preserved. > > The real behavior you want to detect is someone sending a lot of small > > chunks of data that the application could process as larger chunks. If > > the application waits until it has a full "record" before responding, you > > can distinguish the degenerate case by the application's response rate. > > Ok, that is a very useful distinction. I could modify the detection > logic to take *sent* packets into account (except ACKs of course). Yep, Nate read me correctly. > I came to my conclusion. Methinks something like fsync() for tcp > sockets might be useful. If the database is doing a write for every > row it has got from the query result with TCP_NODELAY it is quite > inefficient. On the other hand if there is only one row you don't > want to Nagle-delay the answer. With a tcp fsync() the database > could simply do its write as before and the socket buffer will queue > it until a max MSS packet is filled. When the last row is written it > will issue a fsync() and whatever is in the buffer will get sent out > immediatly. This would make the database communication way more effective > because the database client usually is not processing the answers until > the full query result is received. Even then, we don't get any delay > just fully used packets. > > Taking this further also telnet and SSH could benefit from this. When > ^C a large listing or so takes ages to take effect because there are > so many small packets in flight. So when there is bulk data it again > can have both worlds large packets and fast answers/responses. > > What do you think? (I know this is off-topic to the minmss settings) > > -- > Andre I think that you're describing linux's TCP_CORK option. I think that we have similar behavior right now with some socket option, but not exactly the same... it might not be a bad idea to just try to be explicitly compatible. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040109204457.A1453>