From mboxrd@z Thu Jan 1 00:00:00 1970 From: Antonio Almeida Subject: Re: [PATCH iproute2] Re: HTB accuracy for high speed Date: Mon, 18 May 2009 18:16:26 +0100 Message-ID: <298f5c050905181016w552b283q2bb2ec508433525a@mail.gmail.com> References: <20090517201528.GA8552@ami.dom.local> <20090518065629.GA6006@ff.dom.local> <298f5c050905180954m791c14eaxe1f4b2c92f952a2f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Stephen Hemminger , netdev@vger.kernel.org, kaber@trash.net, davem@davemloft.net, devik@cdi.cz To: Jarek Poplawski Return-path: Received: from mail-fx0-f158.google.com ([209.85.220.158]:56817 "EHLO mail-fx0-f158.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751722AbZERRQf convert rfc822-to-8bit (ORCPT ); Mon, 18 May 2009 13:16:35 -0400 Received: by fxm2 with SMTP id 2so3373176fxm.37 for ; Mon, 18 May 2009 10:16:35 -0700 (PDT) In-Reply-To: <298f5c050905180954m791c14eaxe1f4b2c92f952a2f@mail.gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: I forgot to tell you that I used tc source code from iproute2-2.6.16. I couldn't use the newest version because I got errors when compiling. Antonio Almeida On Mon, May 18, 2009 at 5:54 PM, Antonio Almeida wro= te: > I'm not sure if I'm able to test this patch. What do you mean with > "smallest sizes"? Are you talking about packet's size? What kind of > sizes? > When I feed my bridge with 950Mbits/s of packets with 800 bytes that > is close to 150.000pps and CPUs start to get busy. For packets 100 > bytes long, 150.000pps would be close to 125Mbits/s and CPUs start to > get busy already, so I'm not able to get close to 500Mbits/s. For > rates near 125bits/s the bad accuracy is not so expressive. For > packets of 100 bytes increasing analyser sent traffic, at some point > is not HTB shaping but the CPU that can't process so many packets. I > might misunderstood your point. > > I applied this tc_core.c patch and for packets of 800 bytes it had no > effect in HTB accuracy with rates over 500Mbit. > Anyway I also test it with packets of 100 bytes, generating 200Mbits, > and the result is the same as without this patch: > > With the patch: > class htb 1:108 parent 1:10 leaf 108: prio 7 quantum 1514 rate > 100000Kbit ceil 100000Kbit burst 14087b/8 mpu 0b overhead 0b cburst > 14087b/8 mpu 0b overhead 0b level 0 > =A0Sent 2187884640 bytes 22790465 pkt (dropped 8624566, overlimits 0 = requeues 0) > =A0rate 124946Kbit 162691pps backlog 0b 0p requeues 0 > =A0lended: 22790465 borrowed: 0 giants: 0 > =A0tokens: 180 ctokens: 180 > > > Without the patch: > class htb 1:108 parent 1:10 leaf 108: prio 7 quantum 1514 rate > 100000Kbit ceil 100000Kbit burst 14087b/8 mpu 0b overhead 0b cburst > 14087b/8 mpu 0b overhead 0b level 0 > =A0Sent 1260235680 bytes 13127455 pkt (dropped 4531299, overlimits 0 = requeues 0) > =A0rate 124575Kbit 162207pps backlog 0b 0p requeues 0 > =A0lended: 13127455 borrowed: 0 giants: 0 > =A0tokens: 123 ctokens: 123 > > > Thanks > =A0Antonio Almeida > > > On Mon, May 18, 2009 at 7:56 AM, Jarek Poplawski = wrote: >> Return non-zero tc_calc_xmittime() for rate tables >> >> While looking at the problem of HTB accuracy for high speed (~500Mbi= t >> rates) I've found that rate tables have cells filled with zeros for >> the smallest sizes. It means such packets aren't accounted at all. >> Apart from the correctness of such configs, let's make it safe with >> rather overaccounting than living it unlimited. >> >> Reported-by: Antonio Almeida >> Signed-off-by: Jarek Poplawski >> --- >> >> =A0tc/tc_core.c | =A0 =A04 +++- >> =A01 files changed, 3 insertions(+), 1 deletions(-) >> >> diff --git a/tc/tc_core.c b/tc/tc_core.c >> index 9a0ff39..14f25bc 100644 >> --- a/tc/tc_core.c >> +++ b/tc/tc_core.c >> @@ -58,7 +58,9 @@ unsigned tc_core_ktime2time(unsigned ktime) >> >> =A0unsigned tc_calc_xmittime(unsigned rate, unsigned size) >> =A0{ >> - =A0 =A0 =A0 return tc_core_time2tick(TIME_UNITS_PER_SEC*((double)s= ize/rate)); >> + =A0 =A0 =A0 unsigned t; >> + =A0 =A0 =A0 t =3D tc_core_time2tick(TIME_UNITS_PER_SEC*((double)si= ze/rate)); >> + =A0 =A0 =A0 return t ? : 1; >> =A0} >> >> =A0unsigned tc_calc_xmitsize(unsigned rate, unsigned ticks) >> >