[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A282216.20203@trash.net>
Date: Thu, 04 Jun 2009 21:35:50 +0200
From: Patrick McHardy <kaber@...sh.net>
To: Jarek Poplawski <jarkao2@...il.com>
CC: Antonio Almeida <vexwek@...il.com>,
Stephen Hemminger <shemminger@...tta.com>,
netdev@...r.kernel.org, davem@...emloft.net, devik@....cz,
Eric Dumazet <dada1@...mosbay.com>,
Vladimir Ivashchenko <hazard@...ncoudi.com>
Subject: Re: [PATCH iproute2] Re: HTB accuracy for high speed
Jarek Poplawski wrote:
> On Thu, Jun 04, 2009 at 02:50:06PM +0100, Antonio Almeida wrote:
>> On Wed, Jun 3, 2009 at 10:54 AM, Jarek Poplawski wrote:
>>> Antonio, could you give this patch a try (with all the previous) and
>>> repeat those HFSC tests you did before (plus maybe a few tries with
>>> lower rates)?
>> For me, HTB values are just perfect! I would say that they're better
>> than HFSC, since sent rate stays below the configured ceil (but that's
>> for me)
>> After applying the patch you sent (to sch_hfsc.c) I got these values for HFSC:
>>
>> configuration analyser RX error (%)
>> 10000000 10062688 0,63
>> 20000000 20096961 0,48
>> 30000000 30135028 0,45
>> 40000000 40186190 0,47
>> 50000000 50294890 0,59
>> 60000000 60294553 0,49
>> 70000000 70284220 0,41
>> 80000000 80414272 0,52
>> 90000000 90354675 0,39
>> 100000000 100453024 0,45
>> 200000000 200962041 0,48
>> 250000000 251467886 0,59
>> 300000000 301422613 0,47
>> 400000000 402123479 0,53
>> 500000000 502356820 0,47
>> 550000000 552988253 0,54
>> 600000000 602956905 0,49
>> 700000000 703405632 0,49
>> 750000000 753949085 0,53
>> 800000000 804315169 0,54
>> 900000000 904584208 0,51
>>
>> As usually, generating 970Mbit/s of tcp traffic of 800 bytes packets.
>
> Very nice, it looks like HFSC precision isn't affected by these changes.
> ...
>> If you'd like any other values just ask. I'll be away till the fourteenth.
>> Thanks a lot! Good job!
>
> OK, I'll browse other schedulers, and if there is nothing suspicious
> I'll submit these patches.
Please give me a day to have another look at this, I didn't find
any time today.
In most areas the overflows are only occuring when crossing
IMO unreasonable boundaries (but I've been wrong about that
before), but tc_cbq_calc_maxidle() is still making me nervous.
--
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