-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Let''s say that my ISP gives me 5000Kbit guaranteed bandwidth. I''m starting a HTB traffic shape like this: tc qdisc add dev eth1 root handle 11: htb default 99 tc class add dev eth1 parent 11:0 classid 11:1 htb rate 10000Kbit burst ceil 10000Kbit prio 0 tc class add dev eth1 parent 11:1 classid 11:2 htb rate 5000Kbit ceil 5000Kbit prio 5 [here I have a lot of sub-classes that borrow from parent 11:2] I''ll let HTB to automatically compute the values for ''burst'' and ''cburst''. The problem is elsewhere. What are the correct values for ''rate'' and ''ceil'' of 11:2 class in this case? In fact, total value of ''ceil''s from all sub-classes exceeds 5000Kbit, so there are moments when the bandwidth that comes from my ISP is bigger than guaranteed bandwidth. Is there some kind a theory that says how to establish the values of ''rate''s and ''ceil''s from the parent and its sub-classes? TIA. - -- Catalin Bucur mailto:cata@geniusnet.ro NOC @ Genius Network SRL - Galati - Romania -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE99M+LpDe20wwI9oIRArXvAJ0X0/DPxUjSjuS9lcy+IABExW0NSgCeJVgp mzXkUhmuqLacv+Zq6DJTuCM=VZvr -----END PGP SIGNATURE----- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Monday 09 December 2002 18:14, Catalin Bucur wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > Let''s say that my ISP gives me 5000Kbit guaranteed bandwidth. I''m > starting a HTB traffic shape like this: > > tc qdisc add dev eth1 root handle 11: htb default 99 > tc class add dev eth1 parent 11:0 classid 11:1 htb rate 10000Kbit burst > ceil 10000Kbit prio 0 > tc class add dev eth1 parent 11:1 classid 11:2 htb rate 5000Kbit ceil > 5000Kbit prio 5 > [here I have a lot of sub-classes that borrow from parent 11:2] > > I''ll let HTB to automatically compute the values for ''burst'' and > ''cburst''. The problem is elsewhere. What are the correct values for > ''rate'' and ''ceil'' of 11:2 class in this case? In fact, total value of > ''ceil''s from all sub-classes exceeds 5000Kbit, so there are moments when > the bandwidth that comes from my ISP is bigger than guaranteed bandwidth. > Is there some kind a theory that says how to establish the values of > ''rate''s and ''ceil''s from the parent and its sub-classes?There are some rules : ceil of child <= ceil of parent, sum (child rates) <= rate of parent .... You don''t have to follow this rules, but the final shaping result can be strange. See the faq page on www.docum.org. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stef Coene wrote: | On Monday 09 December 2002 18:14, Catalin Bucur wrote: | |>Let''s say that my ISP gives me 5000Kbit guaranteed bandwidth. I''m |>starting a HTB traffic shape like this: |> |>tc qdisc add dev eth1 root handle 11: htb default 99 |>tc class add dev eth1 parent 11:0 classid 11:1 htb rate 10000Kbit burst |>ceil 10000Kbit prio 0 |>tc class add dev eth1 parent 11:1 classid 11:2 htb rate 5000Kbit ceil |>5000Kbit prio 5 |>[here I have a lot of sub-classes that borrow from parent 11:2] |> |>I''ll let HTB to automatically compute the values for ''burst'' and |>''cburst''. The problem is elsewhere. What are the correct values for |>''rate'' and ''ceil'' of 11:2 class in this case? In fact, total value of |>''ceil''s from all sub-classes exceeds 5000Kbit, so there are moments when |>the bandwidth that comes from my ISP is bigger than guaranteed bandwidth. |>Is there some kind a theory that says how to establish the values of |>''rate''s and ''ceil''s from the parent and its sub-classes? | | There are some rules : ceil of child <= ceil of parent, sum (child rates) <| rate of parent .... You don''t have to follow this rules, but the final | shaping result can be strange. | See the faq page on www.docum.org. | I''ve already seen it :-) But it doesn''t say anything like: sum (child ceils) <= ceil of parent Is there such a rule? Am I forced somehow to limit ''rate'' of class 11:2 under the guaranteed value (5000Kbit), but let the ''ceil'' equal to this value? It''s better to give the clients let''s say 95% of guaranteed bandwidth instead of 100%? - -- Catalin Bucur mailto:cata@geniusnet.ro NOC @ Genius Network SRL - Galati - Romania -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE99Py7pDe20wwI9oIRAp09AJ9eaj7A/GoKOUmKTGp2j+MqZxAR3ACeIyiV KxnF8AQ13K1fyM8eOaf5wfw=YVIk -----END PGP SIGNATURE----- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> | rate of parent .... You don''t have to follow this rules, but the final > | shaping result can be strange. > | See the faq page on www.docum.org. > > I''ve already seen it :-) But it doesn''t say anything like: > sum (child ceils) <= ceil of parent > Is there such a rule?Yes : child ceil <= ceil of parent (I just added it to the faq page)> Am I forced somehow to limit ''rate'' of class 11:2 under the guaranteed > value (5000Kbit), but let the ''ceil'' equal to this value? It''s better to > give the clients let''s say 95% of guaranteed bandwidth instead of 100%?You can argument that limit a client to 95% will leave 5% for someone else. But I think 100% is a better choice. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stef Coene wrote: | | Yes : child ceil <= ceil of parent (I just added it to the faq page) | | Stef | So far, so good. But what if I want to give my clients a little more bandwidth than (parent ceil) / (no. of clients)? Let''s suppose that I have 10 clients, and guaranteed bandwidth is 5000Kbit. The parent ceil is 5000Kbit, childs'' ceils are equal with 500Kbit every each. But I want to give - for example - 800Kbit for each one, so the parent ceil must be equal or greater than 8000Kbit. That is the problem, I don''t think is a such good ideea to give the parent a ceil that is greater than guaranteed bandwidth; the result could be unpredictable. Thank you for your answers, - -- Catalin Bucur mailto:cata@geniusnet.ro NOC @ Genius Network SRL - Galati - Romania -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE99Q8EpDe20wwI9oIRAqFoAJ0WW2Rw/AhQ124pT4BsqoF1d+eHtQCdF7Ns 664kC8gcjBqCxZHBRnErI54=grKv -----END PGP SIGNATURE----- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi Stef!> > I''ll let HTB to automatically compute the values for ''burst'' and > > ''cburst''. The problem is elsewhere. What are the correct values for > > ''rate'' and ''ceil'' of 11:2 class in this case? In fact, total value of > > ''ceil''s from all sub-classes exceeds 5000Kbit, so there are moments when > > the bandwidth that comes from my ISP is bigger than guaranteed bandwidth. > > Is there some kind a theory that says how to establish the values of > > ''rate''s and ''ceil''s from the parent and its sub-classes? > There are some rules : ceil of child <= ceil of parent, sum (child rates) <= > rate of parent .... You don''t have to follow this rules, but the final > shaping result can be strange. > See the faq page on www.docum.org.What would be nice is if you could document what happens when a) child ceil > parent ceil b) child rate > parent ceil c) child ceil > parent rate d) child rate > parent rate How does this influence the shaping results and the shaping of other classes? I''ve actually asked a similar question before: If you have 1:1 / \ / \ 1:2 1:3 /|\ \------ / | \ \ \ 1:4 1:5 1:6 1:7 1:8 if 1:7 and 1:8 respects the rate/ceil of 1:3 and 1:3 respects the rate/ceil of 1:1, but 1:4 does not respect the rate/ceil of 1:2 and 1:2 respects the rate/ceil of 1:1, does the shaping of 1:3 work as normal and only those classes under 1:2 are adversely affected or not? from your previous answer, it seems that the classes under 1:3 would not be affected, but I would love to know why. what happens with 1:4 requests some bandwidth which 1:2 does not have... -- Regards Abraham NEWARK has been REZONED!! DES MOINES has been REZONED!! ___________________________________________________ Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks P.O. Box 3472, Matieland, Stellenbosch, 7602 Cell: +27 82 565 4451 Http: http://www.frogfoot.net/ Email: abz@frogfoot.net
On Monday 09 December 2002 22:45, Catalin Bucur wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Stef Coene wrote: > | Yes : child ceil <= ceil of parent (I just added it to the faq page) > | > | Stef > > So far, so good. But what if I want to give my clients a little more > bandwidth than (parent ceil) / (no. of clients)? > Let''s suppose that I have 10 clients, and guaranteed bandwidth is > 5000Kbit. The parent ceil is 5000Kbit, childs'' ceils are equal with > 500Kbit every each. But I want to give - for example - 800Kbit for each > one, so the parent ceil must be equal or greater than 8000Kbit. That is > the problem, I don''t think is a such good ideea to give the parent a > ceil that is greater than guaranteed bandwidth; the result could be > unpredictable.The rule is : child ceil <= ceil of parent So a child with ceil = 800 kbit and a parent with ceil = 5000 kbit is no problem. Or are you speaking about rates : sum (rate child ) = rate of parent You don''t have to follow this rule, but it will make things more unpredictable. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Monday 09 December 2002 23:18, Abraham van der Merwe wrote:> Hi Stef! > > > > I''ll let HTB to automatically compute the values for ''burst'' and > > > ''cburst''. The problem is elsewhere. What are the correct values for > > > ''rate'' and ''ceil'' of 11:2 class in this case? In fact, total value of > > > ''ceil''s from all sub-classes exceeds 5000Kbit, so there are moments > > > when the bandwidth that comes from my ISP is bigger than guaranteed > > > bandwidth. Is there some kind a theory that says how to establish the > > > values of ''rate''s and ''ceil''s from the parent and its sub-classes? > > > > There are some rules : ceil of child <= ceil of parent, sum (child rates) > > <= rate of parent .... You don''t have to follow this rules, but the > > final shaping result can be strange. > > See the faq page on www.docum.org. > > What would be nice is if you could document what happens when> > a) child ceil > parent ceilChild ceil is used as maximum.> b) child rate > parent ceilIt depends on the child ceil. Parent ceil is never used to limit the bandwidth.> c) child ceil > parent rate > d) child rate > parent rateIt''s more complicated then this. Other classes are also important.> How does this influence the shaping results and the shaping of other > classes? I''ve actually asked a similar question before: If you have > > 1:1 > / \ > / \ > 1:2 1:3 > /|\ \------ > / | \ \ \ > 1:4 1:5 1:6 1:7 1:8 > > if 1:7 and 1:8 respects the rate/ceil of 1:3 and 1:3 respects the rate/ceil > of 1:1, but 1:4 does not respect the rate/ceil of 1:2 and 1:2 respects the > rate/ceil of 1:1, does the shaping of 1:3 work as normal and only those > classes under 1:2 are adversely affected or not? from your previous answer, > it seems that the classes under 1:3 would not be affected, but I would love > to know why. what happens with 1:4 requests some bandwidth which 1:2 does > not have...It''s easier if you add some numbers of ceil/rate to understand the question. I''m going to create an extra page on www.docum.org with your questions and my answer to explain how rate and ceil of classes and parent classes are used. Ok? Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi Stef!> > How does this influence the shaping results and the shaping of other > > classes? I''ve actually asked a similar question before: If you have > > > > 1:1 > > / \ > > / \ > > 1:2 1:3 > > /|\ \------ > > / | \ \ \ > > 1:4 1:5 1:6 1:7 1:8 > > > > if 1:7 and 1:8 respects the rate/ceil of 1:3 and 1:3 respects the rate/ceil > > of 1:1, but 1:4 does not respect the rate/ceil of 1:2 and 1:2 respects the > > rate/ceil of 1:1, does the shaping of 1:3 work as normal and only those > > classes under 1:2 are adversely affected or not? from your previous answer, > > it seems that the classes under 1:3 would not be affected, but I would love > > to know why. what happens with 1:4 requests some bandwidth which 1:2 does > > not have... > It''s easier if you add some numbers of ceil/rate to understand the question. > > I''m going to create an extra page on www.docum.org with your questions and my > answer to explain how rate and ceil of classes and parent classes are used. > Ok?That would be great, thanks -- Regards Abraham If you didn''t have most of your friends, you wouldn''t have most of your problems. ___________________________________________________ Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks P.O. Box 3472, Matieland, Stellenbosch, 7602 Cell: +27 82 565 4451 Http: http://www.frogfoot.net/ Email: abz@frogfoot.net
On Tuesday 10 December 2002 14:28, Abraham van der Merwe wrote:> Hi Stef! > > > > How does this influence the shaping results and the shaping of other > > > classes? I''ve actually asked a similar question before: If you have > > > > > > 1:1 > > > / \ > > > / \ > > > 1:2 1:3 > > > /|\ \------ > > > / | \ \ \ > > > 1:4 1:5 1:6 1:7 1:8 > > > > > > if 1:7 and 1:8 respects the rate/ceil of 1:3 and 1:3 respects the > > > rate/ceil of 1:1, but 1:4 does not respect the rate/ceil of 1:2 and 1:2 > > > respects the rate/ceil of 1:1, does the shaping of 1:3 work as normal > > > and only those classes under 1:2 are adversely affected or not? from > > > your previous answer, it seems that the classes under 1:3 would not be > > > affected, but I would love to know why. what happens with 1:4 requests > > > some bandwidth which 1:2 does not have... > > > > It''s easier if you add some numbers of ceil/rate to understand the > > question. > > > > I''m going to create an extra page on www.docum.org with your questions > > and my answer to explain how rate and ceil of classes and parent classes > > are used. Ok? > > That would be great, thanksI wrote some more information about ceil and rate. You can find it on the faq page on www.docum.org under "Basic rules for traffic shaping with HTB". If you have more questions, let me know and I will try to answer them. Remember, htb will work if you don''t follow this rule. But it will be less obviuos to figure out how the bandwidth will be distributed. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi Stef!> > > > How does this influence the shaping results and the shaping of other > > > > classes? I''ve actually asked a similar question before: If you have > > > > > > > > 1:1 > > > > / \ > > > > / \ > > > > 1:2 1:3 > > > > /|\ \------ > > > > / | \ \ \ > > > > 1:4 1:5 1:6 1:7 1:8 > > > > > > > > if 1:7 and 1:8 respects the rate/ceil of 1:3 and 1:3 respects the > > > > rate/ceil of 1:1, but 1:4 does not respect the rate/ceil of 1:2 and 1:2 > > > > respects the rate/ceil of 1:1, does the shaping of 1:3 work as normal > > > > and only those classes under 1:2 are adversely affected or not? from > > > > your previous answer, it seems that the classes under 1:3 would not be > > > > affected, but I would love to know why. what happens with 1:4 requests > > > > some bandwidth which 1:2 does not have... > > > > > > It''s easier if you add some numbers of ceil/rate to understand the > > > question. > > > > > > I''m going to create an extra page on www.docum.org with your questions > > > and my answer to explain how rate and ceil of classes and parent classes > > > are used. Ok? > > > > That would be great, thanks > I wrote some more information about ceil and rate. You can find it on the faq > page on www.docum.org under "Basic rules for traffic shaping with HTB". If > you have more questions, let me know and I will try to answer them. > Remember, htb will work if you don''t follow this rule. But it will be less > obviuos to figure out how the bandwidth will be distributed.I think your explanation of "rate of class" in your FAQ is wrong. it caught me as well, but from devik''s faq page (http://luxik.cdi.cz/~devik/qos/htb/htbfaq.htm): ------------< snip <------< snip <------< snip <------------ What if sum of child rates is greater than parent rate ? Then interesting things can happen. Total rate delivered by children can be higher that parent''s rate (thus its rate is not respected). However when sum of actual child rates are under parent''s rate then borrowing will occur like in regular case. ------------< snip <------< snip <------< snip <------------ Thus, if sum (rate of childs) > parent rate, then the parent rate is _not respected_. -- Regards Abraham An American''s a person who isn''t afraid to criticize the president but is always polite to traffic cops. ___________________________________________________ Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks P.O. Box 3472, Matieland, Stellenbosch, 7602 Cell: +27 82 565 4451 Http: http://www.frogfoot.net/ Email: abz@frogfoot.net
On Thursday 12 December 2002 09:36, Abraham van der Merwe wrote:> Hi Stef! > I think your explanation of "rate of class" in your FAQ is wrong. it > caught me as well, but from devik''s faq page > (http://luxik.cdi.cz/~devik/qos/htb/htbfaq.htm): > > ------------< snip <------< snip <------< snip <------------ > What if sum of child rates is greater than parent rate ? > > Then interesting things can happen. Total rate delivered by children can be > higher that parent''s rate (thus its rate is not respected). However when > sum of actual child rates are under parent''s rate then borrowing will occur > like in regular case. > > ------------< snip <------< snip <------< snip <------------ > > Thus, if sum (rate of childs) > parent rate, then the parent rate is _not > respected_.:) Devik is right, I''m wrong. Do you know why I was convinced that my rule was OK? Because I always followed my own rules :) I did some small tests : ceil rate 1 200 200 \- 10 200 100 \- 100 200 100 \- 101 200 100 \- 20 200 100 Traffic in 100, 101 and 20 : each gets 67 (33%) Parent rate (10) is not respected otherwise 10 should share 50% with 20. Traffic in 100 and 20 : each gets 100 (50%) If you respect "sum (rate of childs) = parent rate" it works like expected : ceil rate 1 200 200 \- 10 200 100 \- 100 200 50 \- 101 200 50 \- 20 200 100 Traffic in 100, 101 and 20 : 20 gets 100 (50%), 101 50 (25%) and 101 50 (25%). Traffic in 100 and 20 : each gets 100 (50%) Conclusion : if you want to know how traffic will be shaped, you have to follow some basic rules. I will update docum.org tonight. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi Stef!> I did some small tests :[snip]> Conclusion : if you want to know how traffic will be shaped, you have to > follow some basic rules. > I will update docum.org tonight.You''re right. I did some tests this weekend as well and realised that you have to stick with the basics. The problem was that it was not so clear to me how HTB behaves when the child''s rates/ceil exceed the parent''s. Some other questions I''d like to ask you while I''m at it: 1) if you have: 1:1 / \ / \ 1:2 1:3 / \ / \ / \ / \ 1:4 1:5 1:6 1:7 If 1:2 = prio 1 1:3 = prio 2 1:4 = prio 10 1:5 = prio 11 1:6 = prio 5 1:7 = prio 6 Is 1:4, 1:5 evaluated first or 1:6, 1:7? Iow, does HTB start at the root node, prioritize its children and, subprioritize their children, etc. or is only the leaf nodes'' priorities important (i.e. 1:6, 1:7, 1:4, 1:5) 2) if a class is evaluated and there is some bandwidth available to borrow, is the first non-congested child given all bandwidth that is available and then the next is given the rest and so on or is each child given a quantum of bandwidth, then if there is some bandwidth left, a second round and so on? -- Regards Abraham History repeats itself. That''s one thing wrong with history. ___________________________________________________ Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks P.O. Box 3472, Matieland, Stellenbosch, 7602 Cell: +27 82 565 4451 Http: http://www.frogfoot.net/ Email: abz@frogfoot.net
On Thursday 12 December 2002 12:19, Abraham van der Merwe wrote:> Hi Stef! > > > I did some small tests : > > [snip] > > > Conclusion : if you want to know how traffic will be shaped, you have to > > follow some basic rules. > > I will update docum.org tonight. > > You''re right. I did some tests this weekend as well and realised that you > have to stick with the basics. The problem was that it was not so clear to > me how HTB behaves when the child''s rates/ceil exceed the parent''s. > > Some other questions I''d like to ask you while I''m at it: > > 1) if you have: > > 1:1 > / \ > / \ > 1:2 1:3 > / \ / \ > / \ / \ > 1:4 1:5 1:6 1:7 > > If > > 1:2 = prio 1 > 1:3 = prio 2 > > 1:4 = prio 10 > 1:5 = prio 11 > > 1:6 = prio 5 > 1:7 = prio 6 > > Is 1:4, 1:5 evaluated first or 1:6, 1:7? Iow, does HTB start at the root > node, prioritize its children and, subprioritize their children, etc. or > is only the leaf nodes'' priorities important (i.e. 1:6, 1:7, 1:4, 1:5)I don''t know. But I think only the leaf nodes are important. I have some work to do tonight, but I hope to test it this evening.> 2) if a class is evaluated and there is some bandwidth available to borrow, > is the first non-congested child given all bandwidth that is available and > then the next is given the rest and so on or is each child given a quantum > of bandwidth, then if there is some bandwidth left, a second round and so > on?If each class received his rate and the parent has some bandwidth left, the bandwidth is distributed in a round robin so each class can send quantum bytes. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/