[LARTC] HTB - prio and rate

[LARTC] HTB - prio and rate

[Mark Lidstone]

Hi all,

I've not been able to find an explanation of the relationship between
prio and rate as they apply to the HTB technique.  Hopefully someone on
here will be able to help me.

As I understand things, when prio values are assigned to an HTB setup,
classes with a given prio value will only be serviced when there are no
packets waiting in classes with a lower prio value.

Now, does this mean that the rate values for classes with different prio
values should be considered separate?  E.g. imagine the following:

                                   root
                                    |
                                    |
                                Q 1:0 HTB
                                    |
                                    |
                                C 1:1 HTB
                               rate\x100kbit
                               ceil\x100kbit
                             /     / \      \
             _______________/     /   \      \______________
            |              ______/     \______              |
            |             |                   |             |
        C 1:2 HTB     C 1:3 HTB           C 1:4 HTB     C 1:5 HTB
         prio=1        prio=1              prio=2        prio=2
        rate=(a)      rate=(b)            rate=(c)      rate=(d)
            |             |                   |             |
            |             |                   |             |
       Q 12:0 pfifo  Q 13:0 pfifo        Q 14:0 pfifo  Q 15:0 pfifo

Should rates (a) and (b) add up to the maximum rate (100kbit in this
example), with (c) and (d) adding up to the same, or should the total of
(a), (b), (c) and (d) be the maximum rate?  I would have thought that
seeing as queues 1:2 and 1:3 would always take precedence over queues
1:4 and 1:5 that they would almost be treated separately?  I suppose it
all depends on whether the "rate shares" are calculated over all
sub-classes, or if separate calculations are done for each priority
group under the HTB class.

Also, it's very possible I've completely misunderstood something
fundamental here.  If so, please point it out.

Many thanks for any information,

Mark Lidstone
IT and Network Support Administrator

BMT SeaTech Ltd
Grove House, Meridians Cross, 7 Ocean Way
Ocean Village, Southampton.  SO14 3TJ. UK
Tel: +44 (0)23 8063 5122         
Fax: +44 (0)23 8063 5144

E-Mail:  mailto:mark.lidstone@bmtseatech.co.uk
Website: www.bmtseatech.co.uk
====================================
=
Confidentiality Notice and Disclaimer: 
The contents of this e-mail and any attachments are intended only for
the
use of the e-mail addressee(s) shown. If you are not that person, or one
of those persons, you are not allowed to take any action based upon it
or
to copy it, forward, distribute or disclose the contents of it and you
should please delete it from your system. BMT SeaTech Limited does not
accept liability for any errors or omissions in the context of this
e-mail
or its attachments which arise as a result of Internet transmission, nor
accept liability for statements which are those of the author and not
clearly made on behalf of BMT SeaTech Limited.
====================================
=
  
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Andreas Klauer]

On Friday 02 December 2005 14:57, Mark Lidstone wrote:
> As I understand things, when prio values are assigned to an HTB setup,
> classes with a given prio value will only be serviced when there are no
> packets waiting in classes with a lower prio value.

Actually, a class is always able to use it's rate at any time. The prio has 
only an effect when the class is trying to borrow bandwidth from others - 
then the high prio classes are allowed to take what they need first.

The prio of your understanding is instead implemented by the PRIO qdisc. 
However, PRIO does not allow limiting of bandwidth. In my opinion, this 
does make sense, at least I have so far not seen a good solution 
(implemented or theoretical) for combining hard prio and bandwidth 
distribution requirements together.

What you can do, is adding a PRIO qdisc as a child to a HTB leaf class. 
Then the HTB class will take care of the bandwidth limiting, and PRIO will 
take care of the order of the packets inside the HTB class.

> Now, does this mean that the rate values for classes with different prio
> values should be considered separate?

No.

> Should rates (a) and (b) add up to the maximum rate (100kbit in this
> example), with (c) and (d) adding up to the same, or should the total of
> (a), (b), (c) and (d) be the maximum rate?

The rate of the children classes should add up to the parent class rate, 
independent from their prio and ceil (except for the root class, where it 
does not make sense to set a ceil higher than rate).

HTH
Andreas Klauer
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Brian J. Murrell]

[-- Attachment #1.1: Type: text/plain, Size: 997 bytes --]

On Fri, 2005-12-02 at 21:25 +0100, Andreas Klauer wrote:
> Actually, a class is always able to use it's rate at any time. The prio has 
> only an effect when the class is trying to borrow bandwidth from others - 
> then the high prio classes are allowed to take what they need first.

I have wondered about something like this too.  I want to simply
prioritize my upstream bandwidth use, not limit it's use by anything.
Just say (for example) that if an SSH packet is somewhere in the
outbound direction when it hits the queue it gets put to the front of
the queue to minimize the latency of SSH whereas something like
bittorrent waits for SSH but otherwise gets full use of the upstream
bandwidth.  In fact if I were to saturate the upstream with SSH,
something like bittorrent should effectively get no bandwidth at all.

I think this is what Mark wants to, if I'm understanding him correctly.

b.

-- 
My other computer is your Microsoft Windows server.

Brian J. Murrell

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Andreas Klauer]

On Friday 02 December 2005 21:31, Brian J. Murrell wrote:
> In fact if I were to saturate the upstream with SSH, something like
> bittorrent should effectively get no bandwidth at all. 

That's exactly what the PRIO qdisc does. In combination with HTB and SFQ, 
it can be quite powerful, as low priority connections will completely 
starve as long as there are higher priority packets to be sent.

However, PRIO does no bandwidth limiting at all (has to be done by HTB or 
similar), and does not provide connection-based fairness (has to be done 
by SFQ or similar), if you want to avoid one SSH session taking all the 
bandwidth from the other.

Regards,
Andreas Klauer
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Brian J. Murrell]

[-- Attachment #1.1: Type: text/plain, Size: 1763 bytes --]

On Fri, 2005-12-02 at 21:48 +0100, Andreas Klauer wrote:
> 
> That's exactly what the PRIO qdisc does. In combination with HTB and SFQ, 
> it can be quite powerful, as low priority connections will completely 
> starve as long as there are higher priority packets to be sent.

Yeah, that is what I want, but why do I need HTB?  I notice also that
the LARTC Howto says:

        Because it doesn't actually shape, the same warning as for SFQ
        holds: either use it only if your physical link is really full
        or wrap it inside a classful qdisc that does shape. The latter
        holds for almost all cable modems and DSL devices.

I guess I am missing the reasoning for partitioning up the bandwidth
with HTB rather than just letting everyone/everything have an
opportunity to use the full bandwidth as long as something/somebody more
important is not using it.

> However, PRIO does no bandwidth limiting at all (has to be done by HTB or 
> similar), and does not provide connection-based fairness

Surely it will be connection based fairness within the priority class.
IOW, two ssh sessions could starve bittorrent but would each get about
50% of the available bandwidth.  I am fine with that.  I am also fine
with assigning priorities to users and their traffic within their user
priorities.

> (has to be done 
> by SFQ or similar), if you want to avoid one SSH session taking all the 
> bandwidth from the other.

Oh?  So one ssh could starve another?  Why?  Are the outbound SSH
packets not just put to the front of the queue in FIFO order?  I.e.
appended to the end of the "top of the queue" (the top band I guess it
is)?

b.

-- 
My other computer is your Microsoft Windows server.

Brian J. Murrell

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Andreas Klauer]

On Friday 02 December 2005 23:24, Brian J. Murrell wrote:
> Yeah, that is what I want, but why do I need HTB?

You need it only if you also want to limit bandwidth somehow.

> I guess I am missing the reasoning for partitioning up the bandwidth
> with HTB rather than just letting everyone/everything have an
> opportunity to use the full bandwidth as long as something/somebody more
> important is not using it.

Imagine a network where every machine tries to send data at much higher 
rates than your total bandwidth allows. This may cause packet queues 
building up at your router, or worse, at your modem or provider. These 
queues have to empty themselves first before a new packet can be sent, 
which can cause a lot of additional delay depending on queue size.

In that scenario, it's important to take control over this building up 
queue, which you can do by limiting bandwidth using HTB or similar (so the 
queue will be in your router, not somewhere else), by making your router 
the bottleneck.

> Surely it will be connection based fairness within the priority class.

I haven't looked at the code, but I think it's just a plain fifo queue, 
unless you attach SFQ or similar to replace it.

> Oh?  So one ssh could starve another?  Why?  Are the outbound SSH
> packets not just put to the front of the queue in FIFO order?

That's what I thought.

HTH
Andreas
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Brian J. Murrell]

[-- Attachment #1.1: Type: text/plain, Size: 1674 bytes --]

I really don't seem to be getting this.  ~sigh~

As I wrote before I'm not interested in dividing bandwidth up, just
prioritizing the use of the full bandwidth by all-comers.

So I figure I want a TBF in my root class to prevent the queue in my DSL
modem from filling up.  I have about 128kb/s upstream so I added:

# tc qdisc add dev ppp0 root handle 1: tbf rate 120kbit latency 50ms burst 1540

(not sure what values I want for latency and burst)

Then I figure I want a PRIO classifier with 3 bands.  I want anything
not otherwise matching a filter to go in band 2, known bulk to go in
band 3 and priority, latency sensitive "interactive" stuff (i.e. ssh,
not scp) to go in band 1:

# tc qdisc add dev ppp0 parent 1: handle 10: prio

And then only because some examples showed using it, I put an SFQ in
each band.  Do I really need this?  Should I not do this step?

# tc qdisc add dev ppp0 parent 10:1 handle 100: sfq
# tc qdisc add dev ppp0 parent 10:2 handle 200: sfq
# tc qdisc add dev ppp0 parent 10:3 handle 300: sfq

Now I want to use iptables to put stuff into the different bands.
Again, by example I have been trying to do some iptables rules with -j
CLASSIFY --set-class (this one to get ping to be processed in the
highest priority band to test the effectiveness of "interactive
traffic):

# iptables -t mangle -I POSTROUTING -p icmp --icmp-type echo-request -j CLASSIFY --set-class 10:100

I'm not sure what the class numbers I should be using.  Would they be
10:100, 10:200 and 10:300 for the 3 bands?  or 10:1, 10:2 and 10:3?

Thanx,
b.

-- 
My other computer is your Microsoft Windows server.

Brian J. Murrell

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Jeffrey B. Ferland]

Quick question I've been trying to figure out myself without success:  
can I attach a qdisc to a qdisc instead of a qdisc to a class? Be  
nice to chain a few qdiscs together...

Anyway, in order to divide up traffic like that, you'll need to limit  
bandwidth for the reason that splitting up traffic by priority is not  
sufficient to reduce latency. You may be sending your most latency  
sensitive traffic first, but if it's stuck in a queue in your cable  
modem behind everything else that was already there, it won't do you  
a damn bit of good. The following for me took my pings (and ssh  
packets) from about 2.5 _seconds_ of latency under full upload  
conditions to the best times I could get under no load (~40ms from  
here to google). Note that br0 is my bridge where eth0 is the part  
touching the internet. I both NAT and bridge hosts...

#Masquerade ball!
iptables -t nat -F
iptables -t mangle -F
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE

#Setup general policing goodness
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 10
#---- My upload is 384 kilobit from my testing. 380000 under-runs it  
"just enough"
tc class add dev eth0 parent 1: classid 1:1 htb rate 380kbit

#General traffic
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 120kbit ceil  
380kbit prio 2
#Limit general traffic backlog
#---- I might want to increase this... it's a buffer that limits the  
backlog on my default class because it tends to hold too much.
tc qdisc add dev eth0 parent 1:10 handle 100: bfifo limit 12000b

#Priority (small) traffic -- UDP, small SSH, ICMP, small ACK, SYNs
#---- Capped at about 1/3 since it should remain small traffic only.  
Note that no large TCP packets are entered into this class. ICMP,  
DNS, and small packets should never max it out, and therefore it  
should never need more than about 1/3 of the link's bandwidth
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 120kbit prio 0

#Common bulk interactives
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 140kbit ceil  
380kbit prio 2
tc qdisc add dev eth0 parent 1:12 handle 120: sfq perturb 10

#Let iptables tag things
#Prority (small) queue
tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw  
flowid 1:11
#HTTP Queue
tc filter add dev eth0 protocol ip parent 1:0 prio 2 handle 2 fw  
flowid 1:12


#Small packets are fast packets
iptables -t mangle -A POSTROUTING -m length --length 0:128 -j MARK -- 
set-mark 0x1
iptables -t mangle -A POSTROUTING -m length --length 0:128 -j RETURN
iptables -t mangle -A POSTROUTING -p icmp -j MARK --set-mark 0x1
#certain ports go certain places
iptables -t mangle -A POSTROUTING -p tcp --dport 80 -j MARK --set- 
mark 0x2
iptables -t mangle -A POSTROUTING -p tcp --dport 443 -j MARK --set- 
mark 0x2
iptables -t mangle -A POSTROUTING -p tcp --dport 5190 -j MARK --set- 
mark 0x2
iptables -t mangle -A POSTROUTING -p tcp --sport 22 -j MARK --set- 
mark 0x2
iptables -t mangle -A POSTROUTING -p tcp --dport 22 -j MARK --set- 
mark 0x2
#DNS gets the faster lane
iptables -t mangle -A POSTROUTING -p udp --dport 53 -j MARK --set- 
mark 0x1


On Dec 3, 2005, at 1:04 AM, Andreas Klauer wrote:

> On Friday 02 December 2005 23:24, Brian J. Murrell wrote:
>> Yeah, that is what I want, but why do I need HTB?
>
> You need it only if you also want to limit bandwidth somehow.
>
>> I guess I am missing the reasoning for partitioning up the bandwidth
>> with HTB rather than just letting everyone/everything have an
>> opportunity to use the full bandwidth as long as something/ 
>> somebody more
>> important is not using it.
>
> Imagine a network where every machine tries to send data at much  
> higher
> rates than your total bandwidth allows. This may cause packet queues
> building up at your router, or worse, at your modem or provider. These
> queues have to empty themselves first before a new packet can be sent,
> which can cause a lot of additional delay depending on queue size.
>
> In that scenario, it's important to take control over this building up
> queue, which you can do by limiting bandwidth using HTB or similar  
> (so the
> queue will be in your router, not somewhere else), by making your  
> router
> the bottleneck.
>
>> Surely it will be connection based fairness within the priority  
>> class.
>
> I haven't looked at the code, but I think it's just a plain fifo  
> queue,
> unless you attach SFQ or similar to replace it.
>
>> Oh?  So one ssh could starve another?  Why?  Are the outbound SSH
>> packets not just put to the front of the queue in FIFO order?
>
> That's what I thought.
>
> HTH
> Andreas
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Jason Boxman]

Brian J. Murrell said:
> On Fri, 2005-12-02 at 21:25 +0100, Andreas Klauer wrote:
>> Actually, a class is always able to use it's rate at any time. The prio
>> has
>> only an effect when the class is trying to borrow bandwidth from others -
>> then the high prio classes are allowed to take what they need first.
>
> I have wondered about something like this too.  I want to simply
> prioritize my upstream bandwidth use, not limit it's use by anything.
> Just say (for example) that if an SSH packet is somewhere in the
> outbound direction when it hits the queue it gets put to the front of
> the queue to minimize the latency of SSH whereas something like
> bittorrent waits for SSH but otherwise gets full use of the upstream
> bandwidth.  In fact if I were to saturate the upstream with SSH,
> something like bittorrent should effectively get no bandwidth at all.
>
> I think this is what Mark wants to, if I'm understanding him correctly.

I use PRIO myself for this.  It works fine.

http://edseek.com/~jasonb/articles/traffic_shaping/scenarios.html#guarprio



_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Jason Boxman]

Brian J. Murrell said:
> I really don't seem to be getting this.  ~sigh~

It'll come with time.

> As I wrote before I'm not interested in dividing bandwidth up, just
> prioritizing the use of the full bandwidth by all-comers.

Yes.

> So I figure I want a TBF in my root class to prevent the queue in my DSL
> modem from filling up.  I have about 128kb/s upstream so I added:
>
> # tc qdisc add dev ppp0 root handle 1: tbf rate 120kbit latency 50ms burst
> 1540

Precisely what I have done, but I only specified rate and left the rest to
the defaults.

> (not sure what values I want for latency and burst)
>
> Then I figure I want a PRIO classifier with 3 bands.  I want anything
> not otherwise matching a filter to go in band 2, known bulk to go in
> band 3 and priority, latency sensitive "interactive" stuff (i.e. ssh,
> not scp) to go in band 1:

That's pretty common and should work fine.

> # tc qdisc add dev ppp0 parent 1: handle 10: prio
>
> And then only because some examples showed using it, I put an SFQ in
> each band.  Do I really need this?  Should I not do this step?
>
> # tc qdisc add dev ppp0 parent 10:1 handle 100: sfq
> # tc qdisc add dev ppp0 parent 10:2 handle 200: sfq
> # tc qdisc add dev ppp0 parent 10:3 handle 300: sfq

It depends.  The default sfq had a large queue of 128 which may be too big
for interactive traffic.  That said, I ultimately chose to use sfq for all
my classes.  (p2p was unhappy especially with a straight pfifo with so many
connections being made.)

> Now I want to use iptables to put stuff into the different bands.
> Again, by example I have been trying to do some iptables rules with -j
> CLASSIFY --set-class (this one to get ping to be processed in the
> highest priority band to test the effectiveness of "interactive
> traffic):
>
> # iptables -t mangle -I POSTROUTING -p icmp --icmp-type echo-request -j
> CLASSIFY --set-class 10:100
>
> I'm not sure what the class numbers I should be using.  Would they be
> 10:100, 10:200 and 10:300 for the 3 bands?  or 10:1, 10:2 and 10:3?

10:1 .. 10:3 should work.

You could read my whole traffic control guide as it covers all these basics
and it might help some since my goal was a configuration similar to yours.

http://edseek.com/~jasonb/articles/traffic_shaping/



_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Andreas Klauer]

On Sunday 04 December 2005 03:32, Jeffrey B. Ferland wrote:
> Quick question I've been trying to figure out myself without success:
> can I attach a qdisc to a qdisc instead of a qdisc to a class? Be
> nice to chain a few qdiscs together...

Dunno. I've always only attached QDiscs to classes. Even QDiscs that don't 
come with such a class tree structure like HTB do have classes, for 
example in PRIO qdisc, the prio bands of the QDisc are actually classes 
that are created automatically and you can attach another QDisc to them.

What kind of QDisc chain were you thinking of?

Regards,
Andreas Klauer
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Brian J. Murrell]

[-- Attachment #1.1: Type: text/plain, Size: 999 bytes --]

On Sat, 2005-12-03 at 07:04 +0100, Andreas Klauer wrote:
> On Friday 02 December 2005 23:24, Brian J. Murrell wrote:
> > Yeah, that is what I want, but why do I need HTB?
> 
> You need it only if you also want to limit bandwidth somehow.

But surely HTB is overkill for simply limiting bandwidth and keeping the
queue on Linux and not in the modem no?  In my followup message on this
subject, I used TBF instead.  I don't want to classify bandwidth usage,
just prevent the queing on the modem.

> I haven't looked at the code, but I think it's just a plain fifo queue, 

Indeed, but if multiple users are trying to stuff packets in, it will be
more or less evenly distributed when they come out, no?  How can a
single user monopolize a FIFO given that there are other users making
equal demands of it?

> unless you attach SFQ or similar to replace it.

Which I did in my follow example BTW.

b.

-- 
My other computer is your Microsoft Windows server.

Brian J. Murrell

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Jeffrey B. Ferland]

[-- Attachment #1.1.1: Type: text/plain, Size: 1249 bytes --]

OK, reading back through the thread at Brian's previous comment:

 > As I wrote before I'm not interested in dividing bandwidth up, just
 > prioritizing the use of the full bandwidth by all-comers.

And then being confused by this one:
On Dec 4, 2005, at 8:48 AM, Brian J. Murrell wrote:
> On Sat, 2005-12-03 at 07:04 +0100, Andreas Klauer wrote:
>> On Friday 02 December 2005 23:24, Brian J. Murrell wrote:
>>> Yeah, that is what I want, but why do I need HTB?
>>
>> You need it only if you also want to limit bandwidth somehow.
>
> But surely HTB is overkill for simply limiting bandwidth and  
> keeping the
> queue on Linux and not in the modem no?  In my followup message on  
> this
> subject, I used TBF instead.  I don't want to classify bandwidth  
> usage,
> just prevent the queing on the modem.

To prioritize, you must classify. HTB allows prioritization and  
classification... and limitation as well.
Attaching something like this: Root --> TBF --> Prio would be nice,  
but I haven't succeeded in ever attaching anything to a TBF.. or any  
other "classless" qdisc. Goes back to my earlier question that went  
with my earlier answer.

> -- 
> My other computer is your Microsoft Windows server.

^^^^ very nice ;)

-Jeff
SIG: HUP



[-- Attachment #1.1.2: Type: text/html, Size: 3618 bytes --]

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Brian J. Murrell]

[-- Attachment #1.1: Type: text/plain, Size: 1774 bytes --]

On Sun, 2005-12-04 at 10:14 -0500, Jeffrey B. Ferland wrote:


> To prioritize, you must classify. HTB allows prioritization and
> classification... and limitation as well.

Seems the combination of TBF and PRIO does too.

> Attaching something like this: Root --> TBF --> Prio would be nice,
> but I haven't succeeded in ever attaching anything to a TBF.. or any
> other "classless" qdisc.

Hrm.  I *think* that is what I have done with the help of
http://edseek.com/~jasonb/articles/traffic_shaping/scenarios.html#guarprio

qdisc tbf 1: rate 120000bit burst 1199b lat 4294.9s
 Sent 26658509 bytes 511623 pkt (dropped 176, overlimits 8118 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc prio 2: parent 1:1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 26658509 bytes 511623 pkt (dropped 0, overlimits 0 requeues 8118)
 rate 0bit 0pps backlog 0b 0p requeues 8118
qdisc sfq 10: parent 2:1 limit 128p quantum 1452b perturb 20sec
 Sent 3525247 bytes 56520 pkt (dropped 0, overlimits 0 requeues 88)
 rate 0bit 0pps backlog 0b 0p requeues 88
qdisc sfq 20: parent 2:2 limit 128p quantum 1452b perturb 20sec
 Sent 1939846 bytes 19450 pkt (dropped 0, overlimits 0 requeues 5457)
 rate 0bit 0pps backlog 0b 0p requeues 5457
qdisc sfq 30: parent 2:3 limit 128p quantum 1452b perturb 20sec
 Sent 21193416 bytes 435653 pkt (dropped 0, overlimits 0 requeues 2573)
 rate 0bit 0pps backlog 0b 0p requeues 2573

I'm using iptables/pp2p to classify bittorrent into 2:3 and it seems to
be working just fine (even classifying the outgoing ACKs from the
bittorrent download there) while I have classified "ping" into 2:1 and
it seems to be working there.
b.

-- 
My other computer is your Microsoft Windows server.

Brian J. Murrell

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

RE: [LARTC] HTB - prio and rate

[Mark Lidstone]

Hi,

It's not for a particular use that I was asking, it was just for my
understanding.

So what I think people are saying is:

	1) The sum of all HTB classes under a single HTB qdisc should
add up to the maximum rate of the qdisc
	2) HTB's prio is only used when 'borrowing' bandwidth from other
classes under the same HTB qdisc, then classes with a given prio will
only be able to "borrow" bandwidth when classes with a lower prio have
nothing waiting

Is this correct?

Many thanks,

Mark Lidstone
IT and Network Support Administrator

BMT SeaTech Ltd
Grove House, Meridians Cross, 7 Ocean Way
Ocean Village, Southampton.  SO14 3TJ. UK
Tel: +44 (0)23 8063 5122         
Fax: +44 (0)23 8063 5144

E-Mail:  mailto:mark.lidstone@bmtseatech.co.uk
Website: www.bmtseatech.co.uk
====================================
=
Confidentiality Notice and Disclaimer: 
The contents of this e-mail and any attachments are intended only for
the
use of the e-mail addressee(s) shown. If you are not that person, or one
of those persons, you are not allowed to take any action based upon it
or
to copy it, forward, distribute or disclose the contents of it and you
should please delete it from your system. BMT SeaTech Limited does not
accept liability for any errors or omissions in the context of this
e-mail
or its attachments which arise as a result of Internet transmission, nor
accept liability for statements which are those of the author and not
clearly made on behalf of BMT SeaTech Limited.
====================================
=
  
-----Original Message-----
From: lartc-bounces@mailman.ds9a.nl
[mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Brian J. Murrell
Sent: 02 December 2005 20:31
To: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] HTB - prio and rate

On Fri, 2005-12-02 at 21:25 +0100, Andreas Klauer wrote:
> Actually, a class is always able to use it's rate at any time. The 
> prio has only an effect when the class is trying to borrow bandwidth 
> from others - then the high prio classes are allowed to take what they
need first.

I have wondered about something like this too.  I want to simply
prioritize my upstream bandwidth use, not limit it's use by anything.
Just say (for example) that if an SSH packet is somewhere in the
outbound direction when it hits the queue it gets put to the front of
the queue to minimize the latency of SSH whereas something like
bittorrent waits for SSH but otherwise gets full use of the upstream
bandwidth.  In fact if I were to saturate the upstream with SSH,
something like bittorrent should effectively get no bandwidth at all.

I think this is what Mark wants to, if I'm understanding him correctly.

b.

--
My other computer is your Microsoft Windows server.

Brian J. Murrell
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] HTB - prio and rate

[Andreas Klauer]

On Monday 05 December 2005 10:40, Mark Lidstone wrote:
> 	1) The sum of all HTB classes under a single HTB qdisc should
> add up to the maximum rate of the qdisc

A HTB qdisc does not have a rate; it's the classes that do. And it's not 
all classes, but just parent-children relationship. The sum of the 
children class rates should be the parent class rate. Maximum rate doesn't 
sound right either; just to avoid misunderstandings, we're talking about 
rate here, not ceil. Think of rate as 'this much bandwidth is guaranteed 
at all times for this class (and divided between the children)', then you 
should get it about right.

> 	2) HTB's prio is only used when 'borrowing' bandwidth from other
> classes under the same HTB qdisc, then classes with a given prio will
> only be able to "borrow" bandwidth when classes with a lower prio have
> nothing waiting

"classes under the same HTB qdisc" is too general. You have to respect 
parent / child / sibling relationship as well. A class can't just borrow 
from any other class. For example, if a class has same rate and ceil, it 
won't borrow anything, simply because it doesn't have to. And if the 
parent won't borrow, it's children won't borrow from outside classes 
either, even though they are "under the same qdisc".

> Is this correct?

Getting there, I think.

Regards,
Andreas Klauer
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

RE: [LARTC] HTB - prio and rate

[Mark Lidstone]

Thanks very much for the response Andreas.

Ah ha!  It's just me not explaining myself very well, then.

So, could someone please comment on whether this general rule is correct
please?


                                    root
                                 QDISC(HTB)
                                 handle=1:0
                                     |
                                     |
                                 CLASS(HTB)
                                 classid=1:1
                                 ceil=<max>
                                 rate=<max>
                                     |
           +----------------+--------+--------+----------------+
           |                |                 |                |
       CLASS(HTB)       CLASS(HTB)       CLASS(HTB)       CLASS(HTB)
      classid=1:11     classid=1:12  classid=1:1(<n>-1) classid=1:1<n>
         prio=1           prio=1           prio=2           prio=2
       ceil=<max>       ceil=<max>       ceil=<max>       ceil=<max>
     rate=(<max>/<n>) rate=(<max>/<n>) rate=(<max>/<n>) rate=(<max>/<n>)

So, if (as in this case) there are 4 classes and say the maximum rate
was 100kbps, each would receive an equal amount of guaranteed bandwidth
(<max>/<n> == 100kbps/4 = 25kbps) but if there were spare bandwidth
available, classes 1:11 and 1:12 would share the extra equally (because
they have identical rate values) but if 1:11 and 1:13 were contending
for extra bandwidth (for instance), 1:13 would only receive that which
1:11 didn't use.

Obviously I understand that the child classes could have varying rate
and ceil values to be tuned for whatever specific use someone wanted to
put them to, but this is simply a basic example.

Many thanks,

Mark Lidstone
IT and Network Support Administrator

BMT SeaTech Ltd
Grove House, Meridians Cross, 7 Ocean Way
Ocean Village, Southampton.  SO14 3TJ. UK
Tel: +44 (0)23 8063 5122         
Fax: +44 (0)23 8063 5144

E-Mail:  mailto:mark.lidstone@bmtseatech.co.uk
Website: www.bmtseatech.co.uk
====================================
=
Confidentiality Notice and Disclaimer: 
The contents of this e-mail and any attachments are intended only for
the
use of the e-mail addressee(s) shown. If you are not that person, or one
of those persons, you are not allowed to take any action based upon it
or
to copy it, forward, distribute or disclose the contents of it and you
should please delete it from your system. BMT SeaTech Limited does not
accept liability for any errors or omissions in the context of this
e-mail
or its attachments which arise as a result of Internet transmission, nor
accept liability for statements which are those of the author and not
clearly made on behalf of BMT SeaTech Limited.
====================================
=
  
-----Original Message-----
From: lartc-bounces@mailman.ds9a.nl
[mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Andreas Klauer
Sent: 05 December 2005 18:15
To: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] HTB - prio and rate

On Monday 05 December 2005 10:40, Mark Lidstone wrote:
> 	1) The sum of all HTB classes under a single HTB qdisc should
add up 
> to the maximum rate of the qdisc

A HTB qdisc does not have a rate; it's the classes that do. And it's not
all classes, but just parent-children relationship. The sum of the
children class rates should be the parent class rate. Maximum rate
doesn't sound right either; just to avoid misunderstandings, we're
talking about rate here, not ceil. Think of rate as 'this much bandwidth
is guaranteed at all times for this class (and divided between the
children)', then you should get it about right.

> 	2) HTB's prio is only used when 'borrowing' bandwidth from other

> classes under the same HTB qdisc, then classes with a given prio will 
> only be able to "borrow" bandwidth when classes with a lower prio have

> nothing waiting

"classes under the same HTB qdisc" is too general. You have to respect
parent / child / sibling relationship as well. A class can't just borrow
from any other class. For example, if a class has same rate and ceil, it
won't borrow anything, simply because it doesn't have to. And if the
parent won't borrow, it's children won't borrow from outside classes
either, even though they are "under the same qdisc".

> Is this correct?

Getting there, I think.

Regards,
Andreas Klauer
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

RE: [LARTC] HTB - prio and rate

[Mark Lidstone]

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

--===============0328733572==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5FFC2.69A796BA"

This is a multi-part message in MIME format.

[-- Attachment #2: Type: text/plain, Size: 1186 bytes --]

Jody - Many thanks for taking the time to reply.  It's greatly helped my
understanding.
 
________________________________

From: Jody Shumaker [mailto:jody.shumaker@gmail.com] 
Sent: 12 December 2005 19:14
To: Mark Lidstone
Subject: Re: [LARTC] HTB - prio and rate



	No, I wrote what I meant.  If classes 1:11 and 1:12 are
contending for bandwidth the prio values will have no effect as they are
the same.  I was making the point that they would get equal shares of
the spare bandwidth because they have equal rates (the spare bandwidth
is shared out with classes that have higher rates getting more of the
bandwidth than classes with lower rates).


Ahh,  now that I read it again it does read that way. Sorry about
misreading it.



	
	
	OK, so the _ratio_ of rate values for child classes is only
taken into account when sharing bandwidth with other child classes that
have the same prio value?


That has been my experience.  However, in practice things won't always
confirm to these rules exactly.  I think that is more of caused by how
TCP throttles bandwidth.  In general though the priority does have the
intended effect. 

- Jody




[-- Attachment #3: Type: text/html, Size: 2358 bytes --]