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=100kbit
ceil=100kbit
/ / \ \
_______________/ / \ \______________
| ______/ \______ |
| | | |
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.
=========================================================================
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
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
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
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 fairnessSurely 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 _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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
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 _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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
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
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 > 1540Precisely 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: sfqIt 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/
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
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 _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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 _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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 _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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 theyneed 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
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 qdiscA 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
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
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 _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc