From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Fink Subject: Re: [PATCH 1/2]: [NET_SCHED]: Make all rate based scheduler work with TSO. Date: Wed, 5 Sep 2007 23:59:54 -0400 Message-ID: <20070905235954.a2b4e3d2.billfink@mindspring.com> References: <1188562975.18622.11.camel@localhost.localdomain> <46D9103B.7090905@trash.net> <20070903233456.0e738183.billfink@mindspring.com> <46DD867E.6020307@trash.net> <20070904134015.18a3e7ca.billfink@mindspring.com> <1188983830.16405.21.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Jesper Dangaard Brouer , "netdev@vger.kernel.org" To: jdb@comx.dk Return-path: Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]:49407 "EHLO elasmtp-dupuy.atl.sa.earthlink.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750717AbXIFEAe (ORCPT ); Thu, 6 Sep 2007 00:00:34 -0400 In-Reply-To: <1188983830.16405.21.camel@localhost.localdomain> Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Wed, 05 Sep 2007, Jesper Dangaard Brouer wrote: > On Tue, 2007-09-04 at 13:40 -0400, Bill Fink wrote: > > On Tue, 04 Sep 2007, Patrick McHardy wrote: > > > > > Bill Fink wrote: > > > > On Sat, 1 Sep 2007, Jesper Dangaard Brouer wrote: > > > > > > > Yes, you need to specify the MTU on the command line for > > > jumbo frames. > > > > Thanks! Works much better now, although it does slightly exceed > > the specified rate. > > Thats what happens, with the current rate table system, as we use the > lower boundry (when doing the packet to time lookups). Especially with a > high MTU, as the "resolution" of the rate table diminish (mpu=9000 gives > cell_log=6, 2^6=64 bytes "resolution" buckets). > > > [root@lang4 ~]# tc qdisc add dev eth2 root tbf rate 2gbit buffer 5000000 limit 18000 mtu 9000 > > > > [root@lang4 ~]# ./nuttcp-5.5.5 -w10m 192.168.88.14 > > 2465.6729 MB / 10.08 sec = 2051.8241 Mbps 19 %TX 13 %RX That doesn't seem to account for the magnitude of the rate exceeding. In the worst case (rough calculation): (1+64/9000)*2000 = 2014.2222 Mbps Now if that were 256 rather than 64: (1+256/9000)*2000 = 2056.8888 Mbps Or maybe the packet overhead is calculated wrong for the 9000 MTU case (just wild speculation on my part). -Bill