On Wed, 2005-14-12 at 21:15 -0500, Patrick McManus wrote: > David S. Miller wrote: > > From: John Ronciak <[EMAIL PROTECTED]> > > Date: Wed, 7 Dec 2005 11:48:46 -0800 > > > >> Copybreak probably shouldn't be used in routing use cases. > > > > I think even this is arguable, routers route a lot more than > > small 64-byte frames. Unfortunately, that is what everyone > > uses for packet rate tests. :-/ > > > > Assuming only TCP flows go through a router, it is safe to > > say that the full-sized data frame to ACK ratio is about 2 > > to 1. > > Sadly, the picture most routers see is the opposite: about 2 sub-100 > byte frames for every 1 decent sized one - and fullsize is really rare, > maybe just 1 in 5. > > This thread is semi-modern with some good data: > http://www.cctec.com/maillists/nanog/historical/0312/msg00394.html > > and it is getting worse over time.. in 1998 it was more like 1:1 > > So the all-64byte test isn't that crazy. >
A more up to date info is here: http://netweb.usc.edu/~rsinha/pkt-sizes/ Apparently VPNs have a great impact on the distribution to work around path mtu issues - thats the 1300B peak. Note that 40% of generic traffic infact fits within the 64B area ;-> > BTW - this has been a great thread - enjoyed reading it very much. But > I've kind of lost a feel for what the prefetch and copybreak cases mean > for local delievery (e.g tcp termination) scenarios.. both in throughput > and cpu left for the local application. That has to be a more important > profile than ip forwarding. Any thoughts on that? > I think they are both important. For a end host profile even further for a server as well as a client since they are very different workloads and would really be seeing different packet sizes (a lot of pure ACKs in server and a lot of large packets in an end system). BTW, note some of the ideas of defered copybreaks/recycling discussed. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
