[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <298f5c050905181016w552b283q2bb2ec508433525a@mail.gmail.com>
Date: Mon, 18 May 2009 18:16:26 +0100
From: Antonio Almeida <vexwek@...il.com>
To: Jarek Poplawski <jarkao2@...il.com>
Cc: Stephen Hemminger <shemminger@...tta.com>, netdev@...r.kernel.org,
kaber@...sh.net, davem@...emloft.net, devik@....cz
Subject: Re: [PATCH iproute2] Re: HTB accuracy for high speed
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 <vexwek@...il.com> wrote:
> 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
> Sent 2187884640 bytes 22790465 pkt (dropped 8624566, overlimits 0 requeues 0)
> rate 124946Kbit 162691pps backlog 0b 0p requeues 0
> lended: 22790465 borrowed: 0 giants: 0
> tokens: 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
> Sent 1260235680 bytes 13127455 pkt (dropped 4531299, overlimits 0 requeues 0)
> rate 124575Kbit 162207pps backlog 0b 0p requeues 0
> lended: 13127455 borrowed: 0 giants: 0
> tokens: 123 ctokens: 123
>
>
> Thanks
> Antonio Almeida
>
>
> On Mon, May 18, 2009 at 7:56 AM, Jarek Poplawski <jarkao2@...il.com> wrote:
>> Return non-zero tc_calc_xmittime() for rate tables
>>
>> While looking at the problem of HTB accuracy for high speed (~500Mbit
>> 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 <vexwek@...il.com>
>> Signed-off-by: Jarek Poplawski <jarkao2@...il.com>
>> ---
>>
>> tc/tc_core.c | 4 +++-
>> 1 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)
>>
>> unsigned tc_calc_xmittime(unsigned rate, unsigned size)
>> {
>> - return tc_core_time2tick(TIME_UNITS_PER_SEC*((double)size/rate));
>> + unsigned t;
>> + t = tc_core_time2tick(TIME_UNITS_PER_SEC*((double)size/rate));
>> + return t ? : 1;
>> }
>>
>> unsigned tc_calc_xmitsize(unsigned rate, unsigned ticks)
>>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists