From owner-freebsd-arch@FreeBSD.ORG Tue May 27 04:31:45 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B93037B401 for ; Tue, 27 May 2003 04:31:45 -0700 (PDT) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id E864143F3F for ; Tue, 27 May 2003 04:31:43 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h4RBVgp9044767; Tue, 27 May 2003 21:31:42 +1000 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h4RBVdCH044766; Tue, 27 May 2003 21:31:39 +1000 (EST) Date: Tue, 27 May 2003 21:31:38 +1000 From: Peter Jeremy To: Igor Sysoev Message-ID: <20030527113138.GD44520@cirb503493.alcatel.com.au> References: <3ED33487.59C03DA9@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: arch@freebsd.org Subject: Re: sendfile(2) SF_NOPUSH flag proposal X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2003 11:31:45 -0000 On Tue, May 27, 2003 at 02:49:35PM +0400, Igor Sysoev wrote: >Actually 6 vs. 6 for this 8K file. But I said about another thing. >Let's see 48K file and 250 bytes header. sendfile() usually sends >it as 4K or 8K hunks so there are 48/8 * 6 + 1 (header) = 37 packets. >But (48K + 250) / 1460 = 33 * 1460 + 1270 i.e. 34 packets. >It's 8% decrease of data packets. Add here the possible retransmitions. Why is the number of data packets so important? If you repeat the calculation considering bytes across the wire (assuming Ethernet), then the saving is closer to 0.4% - this is in the noise. For that matter, have you considered the impact of Path MTU discovery? I think possible retransmissions are irrelevant here. If your packet loss is anything above negligible then you have other problems. If the retransmission is caused by transmission noise, then the smaller packets are less likely to get hit. And the sender is likely to retransmit a full packet rather than the small packet originally sent. >> Really: it's in the noise. Unless you are paying by packet >> count, you probably shouldn't care. > >So do you consider that IP fragmentation is the good thing ? "IP fragmentation" normally refers to a single IP packet being split up into multiple smaller packets by a router. It has nothing to do with the topic under discussion. If anything, transmitting smaller IP packets reduces the likelihood that an intervening router will need to fragment packets - so your patch actually increases the probability of IP fragmentation. Peter