From owner-cvs-src@FreeBSD.ORG Sat Jan 10 00:47:46 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 220B416A4D0 for ; Sat, 10 Jan 2004 00:47:46 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 1492643D2F for ; Sat, 10 Jan 2004 00:47:39 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 57668 invoked from network); 10 Jan 2004 08:47:37 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 10 Jan 2004 08:47:37 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 9 Jan 2004 20:47:32 -0600 (CST) From: Mike Silbersack To: Andre Oppermann In-Reply-To: <3FFF0F5B.31185EA3@freebsd.org> Message-ID: <20040109204457.A1453@odysseus.silby.com> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: davidxu@freebsd.org cc: cvs-all@freebsd.org cc: Nate Lawson Subject: Re: cvs commit: src/sys/netinet ip_icmp.c tcp.h tcp_input.c tcp_subr.ctcp_usrreq.c tcp_var.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2004 08:47:46 -0000 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