tc and PRIOMAP not working

Hello group,

I have the following traffic control configuration currently in my system:

tc qdisc add dev eth1 root handle 1: htb default 10

tc class add dev eth1 parent 1: classid 1:1 htb rate 1mbit burst 15k

tc class add dev eth1 parent 1:1 classid 1:10 htb rate 768kbit ceil
1mbit burst 15k # Standard internet
tc class add dev eth1 parent 1:1 classid 1:20 htb rate 53kbit ceil 1mbit
burst 15k # Medium priority
tc class add dev eth1 parent 1:1 classid 1:30 htb rate 53kbit ceil
93kbit burst 15k # Lowest priority

tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev eth1 parent 1:30 handle 30: sfq perturb 10

tc filter add dev eth1 protocol ip parent 1: prio 1 handle 2 fw flowid
1:20 # Medium priority
tc filter add dev eth1 protocol ip parent 1: prio 1 handle 1 fw flowid
1:30 # Lowest priority

I today tried to modify it. Goals I already achieve:

* All connections which are unmarked go into the 1:10 class, which share
the bandwith using SFQ
* All connections marked with 1 should be limited to max. 93kbit ceiling

I want to add a third goal:

* All connection marked with 2 should get all the bandwith they need,
unless someone in 1:10 needs it. If someone in 1:10 needs it, it always
has priority and may starve mark 2 packets.

I really didn't get anything done. I tried fiddling with PRIOMAP with 2
bands, but did not get anything to work.

Could you offer me help?
Thanks,
Johannes

--
"Meine Gegenklage gegen dich lautet dann auf bewusste Verlogenheit,
verlästerung von Gott, Bibel und mir und bewusster Blasphemie."
-- Prophet und Visionär Hans Joss aka HJP in de.sci.physik
<48d8bf1d$0$7510$(E-Mail Removed)>

Johannes Bauer wrote:
> Hello group,
>
> I have the following traffic control configuration currently in my system:
>
> tc qdisc add dev eth1 root handle 1: htb default 10

Remember if you ever change things so that default is a rubbish low prio
class that arp will go here unless you filter it elsewhere.

> I want to add a third goal:
>
> * All connection marked with 2 should get all the bandwith they need,
> unless someone in 1:10 needs it. If someone in 1:10 needs it, it always
> has priority and may starve mark 2 packets.

Total starvation always seems a bit harsh, maybe causing people/apps to
thing the network is broken.

Why not use the htb prio parameter on the classes and give low rates.

If you put prio 0 on 1:10 and prio 1 on 1:20 etc then any spare
bandwidth above the set rates will get shared in order.

Andy.

Andy Furniss schrieb:

>> * All connection marked with 2 should get all the bandwith they need,
>> unless someone in 1:10 needs it. If someone in 1:10 needs it, it always
>> has priority and may starve mark 2 packets.
>
> Total starvation always seems a bit harsh, maybe causing people/apps to
> thing the network is broken.
>
> Why not use the htb prio parameter on the classes and give low rates.
>
> If you put prio 0 on 1:10 and prio 1 on 1:20 etc then any spare
> bandwidth above the set rates will get shared in order.

Your tip lead me to a solution which is now working marvellously. To sum
it up: I wanted to mainly reduce latency when people are downloading
large amounts of bulk data and I'm doing some ssh stuff. So the bulk
transfers now go into the low-priority queue und the ssh into the
high-priority, with the "prio" keyword and HTB, just as you suggested. I
had to fiddle with the leaf node, however: They were all configured to
use SFQ, which was a desaster for latency. Now the high prio queue is
using SFQ and all the low-priorirty queues are using pfifo with a queue
size of 1 (increasing this significantly increases delay, too).

Thanks a lot for your hint!
Regards,
Johannes

--
"Meine Gegenklage gegen dich lautet dann auf bewusste Verlogenheit,
verlästerung von Gott, Bibel und mir und bewusster Blasphemie."
-- Prophet und Visionär Hans Joss aka HJP in de.sci.physik
<48d8bf1d$0$7510$(E-Mail Removed)>

Johannes Bauer wrote:

> Your tip lead me to a solution which is now working marvellously. To sum
> it up: I wanted to mainly reduce latency when people are downloading
> large amounts of bulk data and I'm doing some ssh stuff. So the bulk
> transfers now go into the low-priority queue und the ssh into the
> high-priority, with the "prio" keyword and HTB, just as you suggested. I
> had to fiddle with the leaf node, however: They were all configured to
> use SFQ, which was a desaster for latency. Now the high prio queue is
> using SFQ and all the low-priorirty queues are using pfifo with a queue
> size of 1 (increasing this significantly increases delay, too).

Hmm, seems like something else is wrong and giving a 1 queue size is
just masking it.

It could just be that you have the rates set too high, often because of
overheads you need to back off from what you think the rate for your
line is.

If it's dsl with recent kernels there are ways to do things properly to
account for atm. I still patch tc to achieve the same result. What you
need to do depends on the wan you have, and if dsl the way you connect
(eg. pppoa/pppoe/bridged etc) as they all have different overheads.