Date: Tue, 27 May 2003 11:31:34 -0700 (PDT) From: Marc Slemko <marcs@znep.com> To: arch@freebsd.org Subject: Re: sendfile(2) SF_NOPUSH flag proposal Message-ID: <Pine.NEB.4.53.0305271115230.28029@rhombus.znep.com> In-Reply-To: <20030527113138.GD44520@cirb503493.alcatel.com.au> References: <3ED33487.59C03DA9@mindspring.com> <Pine.BSF.4.21.0305271421320.46491-100000@is> <20030527113138.GD44520@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 May 2003, Peter Jeremy wrote: > 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. I think Ethernet is pretty close to the best case here, other link layers have significantly higher overheads. Granted, it still is fairly low but not noise. > For that matter, have you considered the impact of Path MTU discovery? Withput PMTU-D, the overhead in number of packets would normally be a smaller percent because your MTU will be lower... what are you suggesting? > 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. The reality is that there are many environments where packet loss is a fact of life, and TCP can and does deal with it. I think you will find that the majority of packet loss on the Internet is due to events that are independent of the size of the packet, sugh as many types of buffer overflow. The number of packets also matters from the perspective of a lot of networking equipment that has a heavy per packet overhead, then minimal per byte overhead after that. Regardless of all this, which gets more and more complex to analyze once you look at all the complex behaviours of what routers actually do these days on the net, it is just a "good thing"(tm) to do to ensure that your application uses the minimal number of packets practical.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.4.53.0305271115230.28029>