testing crazy stuff with iproute2

testing crazy stuff with iproute2

[Denys Fedoryshchenko]

I did rules:

tc qdisc        del dev eth0 root
tc qdisc        add dev eth0 handle 1: root htb

tc class        add dev eth0 parent 1:0 classid 1:2 htb rate 100Mbit ceil 
100Mbit quantum 1514
tc qdisc        add dev eth0 handle 2: parent 1:2 sfq

tc class        add dev eth0 parent 1:0 classid 1:3 htb rate 100Mbit ceil 
100Mbit quantum 1514
tc qdisc        add dev eth0 parent 1:3 handle 3: est 1sec 8sec tbf buffer 
1024kb latency 500ms rate 10240 peakrate 1024000 mtu 1500
tc qdisc        add dev eth0 parent 3:1 handle 30 pfifo limit 1

tc filter       add dev eth0 parent 1:0 protocol ip prio 5 u32 match ip src 
192.168.1.1/32 flowid 1:3

Probably it must not work at all (attaching tbf), but it works as expected in 
my understanding.

classid 1:2 just fake, not used at all
classid 1:3 is created, because i want to use tbf multiple times. 
I like burst introduced in TBF, and seems burst/cburst in HTB not doing same 
job, at least i had some difficulties with them (will research more).

filter don't want to attach with parent 3:0 or 3:1, so i had to attach it to 
1:3. It works fine, but i have to put high value in ceil to not be limited by 
htb. TBF working as expected. When rate-limit in TBF reached, it is queueing 
buffer in qdisc with handle 30

But i got few times in dmesg, during tests (probably when i set sfq instead 
pfifo, or etc).

[2090816.116000] htb: class 10003 isn't work conserving ?!

Is it a bug? And does it worth to do such "shaper"?


--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.

Re: testing crazy stuff with iproute2

[Jarek Poplawski]

Denys Fedoryshchenko wrote, On 12/26/2007 05:57 AM:
...

> But i got few times in dmesg, during tests (probably when i set sfq instead 
> pfifo, or etc).
> 
> [2090816.116000] htb: class 10003 isn't work conserving ?!
> 
> Is it a bug? And does it worth to do such "shaper"?

It's not a bug - htb simply wonders the sub-queue has packets,
but doesn't dequeue any when expected. Probably htb + tbf isn't
the most common configuration, but nothing wrong either. You
should only consider htb could do similar (not exactly) job by
itself, and each additional qdisc adds some latency, so it's only
a question of priorities. But, hmm, ...don't you think this
lartc.org's mailing list is really nice?

Regards,
Jarek P.

PS: BTW, maybe I missed this, but I hoped you'd share here some
impressions from testing this new PSPacer scheduler?

Re: testing crazy stuff with iproute2

[Denys Fedoryshchenko]

I will try to talk in lartc, about HTB i wrote another mail...
It is not acting as TBF with burst, it is even acting weird. Probably it is 
bug, when traffic get "blocked" cause of burst.

I will try to use lartc, if it is better to not "spam" my stuff here :-)

I didn't try yet PSPacer yet, as ESFQ things. If it is need i can do that and 
write feedback. I can use some of them in real environment after some pre-
testing.

On Thu, 27 Dec 2007 22:09:01 +0100, Jarek Poplawski wrote
> Denys Fedoryshchenko wrote, On 12/26/2007 05:57 AM:
> ....
> 
> > But i got few times in dmesg, during tests (probably when i set sfq 
instead 
> > pfifo, or etc).
> > 
> > [2090816.116000] htb: class 10003 isn't work conserving ?!
> > 
> > Is it a bug? And does it worth to do such "shaper"?
> 
> It's not a bug - htb simply wonders the sub-queue has packets,
> but doesn't dequeue any when expected. Probably htb + tbf isn't
> the most common configuration, but nothing wrong either. You
> should only consider htb could do similar (not exactly) job by
> itself, and each additional qdisc adds some latency, so it's only
> a question of priorities. But, hmm, ...don't you think this
> lartc.org's mailing list is really nice?
> 
> Regards,
> Jarek P.
> 
> PS: BTW, maybe I missed this, but I hoped you'd share here some
> impressions from testing this new PSPacer scheduler?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.

Re: testing crazy stuff with iproute2

[Jarek Poplawski]

On Thu, Dec 27, 2007 at 11:25:53PM +0200, Denys Fedoryshchenko wrote:
> I will try to talk in lartc, about HTB i wrote another mail...
> It is not acting as TBF with burst, it is even acting weird. Probably it is 
> bug, when traffic get "blocked" cause of burst.

HTB was probably projected to be simple, so it has less knobs than CBQ 
or TBF. But it shouldn't act weird, unless you do weird things...
E.g. what do you expect with 'rate 8bit'? I think, you should firstly
do some tests with different rates without touching cburst or even
quantum: HTB usually uses workable defaults if rates and packet sizes
are within some limits. End at the beginning I think it's better to
always use 'default' parameter with qdisc, and add some class for this
to verify all traffic is filtered as expected. 

> I will try to use lartc, if it is better to not "spam" my stuff here :-)

Maybe you don't believe it, but I really knew much more about properly
setting HTB parameters 2 years ago, when I read lartc or not worse our
local linux networking news group than now - when, this practical
knowledge was mostly erased by some 'useless' inside details.

> I didn't try yet PSPacer yet, as ESFQ things. If it is need i can do that and 
> write feedback. I can use some of them in real environment after some pre-
> testing.

It looked like very interesting, so I'm only a bit curious why so
quiet...

Jarek P.

Re: testing crazy stuff with iproute2

[Denys Fedoryshchenko]

On Thu, 27 Dec 2007 23:54:55 +0100, Jarek Poplawski wrote
> On Thu, Dec 27, 2007 at 11:25:53PM +0200, Denys Fedoryshchenko wrote:
> > I will try to talk in lartc, about HTB i wrote another mail...
> > It is not acting as TBF with burst, it is even acting weird. Probably it 
is 
> > bug, when traffic get "blocked" cause of burst.
> 
> HTB was probably projected to be simple, so it has less knobs than 
> CBQ or TBF. But it shouldn't act weird, unless you do weird things...
> E.g. what do you expect with 'rate 8bit'? I think, you should 
> firstly do some tests with different rates without touching cburst 
> or even quantum: HTB usually uses workable defaults if rates and 
> packet sizes are within some limits. End at the beginning I think 
> it's better to always use 'default' parameter with qdisc, and add 
> some class for this to verify all traffic is filtered as expected.

It is just to make ceil thing there is no bandwidth available. I know that 
parents in theory must be equal or more than childs sum and etc. About 
strange cburst/burst i will explain in next part.


> 
> > I will try to use lartc, if it is better to not "spam" my stuff here :-)
> 
> Maybe you don't believe it, but I really knew much more about 
> properly setting HTB parameters 2 years ago, when I read lartc or 
> not worse our local linux networking news group than now - when, 
> this practical knowledge was mostly erased by some 'useless' inside details.

For bandwidth sharing it is perfect, but i want just to make things, which i 
did with TBF - some time bursty speed, and then slow down to lower speed if 
customer is using too much. In theory it has to work like this, but in 
practice i am hitting wall. I tried it about 1 year ago, it was same thing, 
just with another conditions. Seems cburst/burst a bit different thing, just 
to make load on CPU by HTB less , at high speeds.

> 
> > I didn't try yet PSPacer yet, as ESFQ things. If it is need i can do that 
and 
> > write feedback. I can use some of them in real environment after some pre-
> > testing.
> 
> It looked like very interesting, so I'm only a bit curious why so
> quiet...
On my experience people don't like much talking on mails, sending bug reports 
and etc. I know a lot of people who have kernel panic, oops issues, and who 
don't know what to do, just to blame "linux". Now i am trying to help them 
and also to help improve linux this way.
For me personally more interesting right now ESFQ way. Just i am scared to 
put in producting patches not from mainline, cause then on issues i cannot 
write proper bugreport.

> 
> Jarek P.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.

Re: testing crazy stuff with iproute2

[Jarek Poplawski]

On Fri, Dec 28, 2007 at 01:44:17AM +0200, Denys Fedoryshchenko wrote:
...
> For bandwidth sharing it is perfect, but i want just to make things, which i 
> did with TBF - some time bursty speed, and then slow down to lower speed if 
> customer is using too much. In theory it has to work like this, but in 
> practice i am hitting wall. I tried it about 1 year ago, it was same thing, 
> just with another conditions. Seems cburst/burst a bit different thing, just 
> to make load on CPU by HTB less , at high speeds.

IMHO it's quite possible you're trying to use HTB to things it is
not intended to do. cburst/burst have to limit burstiness and not
change rates depending on load. But, maybe they could do the other
things too whith some tricks, I don't know. I think CBQ or maybe
HFSC could be better for you. But, if TBF works for you, and you
don't need sharing (lending) I don't understand why to 'fight'
with HTB at all. You could maybe use it only to get class hierarchy
with some high, not limiting rates, or even try e.g. prio + TBF
combination.

Regards,
Jarek P.

Re: testing crazy stuff with iproute2

[Denys Fedoryshchenko]

Prio is limited. I can have on PPPoE up to 500-600 customers, and i need to 
create for each in ifb device class/qdisc. So prio will not fit.

On Fri, 28 Dec 2007 11:18:27 +0100, Jarek Poplawski wrote
> On Fri, Dec 28, 2007 at 01:44:17AM +0200, Denys Fedoryshchenko wrote:
> ....
> > For bandwidth sharing it is perfect, but i want just to make things, 
which i 
> > did with TBF - some time bursty speed, and then slow down to lower speed 
if 
> > customer is using too much. In theory it has to work like this, but in 
> > practice i am hitting wall. I tried it about 1 year ago, it was same 
thing, 
> > just with another conditions. Seems cburst/burst a bit different thing, 
just 
> > to make load on CPU by HTB less , at high speeds.
> 
> IMHO it's quite possible you're trying to use HTB to things it is
> not intended to do. cburst/burst have to limit burstiness and not
> change rates depending on load. But, maybe they could do the other
> things too whith some tricks, I don't know. I think CBQ or maybe
> HFSC could be better for you. But, if TBF works for you, and you
> don't need sharing (lending) I don't understand why to 'fight'
> with HTB at all. You could maybe use it only to get class hierarchy
> with some high, not limiting rates, or even try e.g. prio + TBF
> combination.
> 
> Regards,
> Jarek P.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.