Hfsc and linkshare option



  • Hello there i've recently started to read about the hfsc scheduler and would like to understand what the linkshare option actually does.
    Anyone could explain it to me or give me a link to read so that i can understand? How does the excess bandwidth that linkshare uses for queues get calculated? Thanks in advance.



  • Example: There are four active queues with linkshare = 1, 2, 3 and 4 kb/s respectively, sharing 1 mb/s downlink. Then the actual bandwith allocated to them would be 100, 200, 300 and 400 kb/s respectively.

    See Stoica, Zhang, and T. S. Eugene Ng. 1997: http://www.cs.cmu.edu/~hzhang/HFSC/main.html for more details.



  • Well i found this page and would like some comments on those examples there if possible by anyone who is willing to do so.
    Let's say we have 1Mbit downlink and set the root queue to bandwidth 1Mb.Now let's say we have two other queues```
    queue oDly bandwidth 0Kb hfsc( realtime 300Kb linkshare 128Kb )
    queue 1Dly bandwidth 0Kb hfsc( realtime 200Kb linkshare 256Kb )

    So let's say in the above example that both realtime service curves are quaranteed and in effect,so the next thing is for linkshare to come forth.From the remaining 500Kb the first queue will get 166Kb and the second 334Kb according to the ratios of the linkshare options?


  • @dpetka2001:

    Let's say we have 1Mbit downlink and set the root queue to bandwidth 1Mb.Now let's say we have two other queues```
    queue oDly bandwidth 0Kb hfsc( realtime 300Kb linkshare 128Kb )
    queue 1Dly bandwidth 0Kb hfsc( realtime 200Kb linkshare 256Kb )

    So let's say in the above example that both realtime service curves are quaranteed and in effect,so the next thing is for linkshare to come forth.From the remaining 500Kb the first queue will get 166Kb and the second 334Kb according to the ratios of the linkshare options?
    

    The linkshare curves tell us that the queue oDly gets 128/(128+256) = 1/3 bandwidth = 333.3 kb/s and the queue 1Dly gets 256/(128+256) = 2/3 bandwidth = 666.7 kb/s when both queues are active. When only one of them is active it gets the full bandwidth (= 1 mb/s).

    This is consistent with the real-time curves which guarantee minimal bandwith 300 kb/s for oDly and 200 kb/s for 1Dly.



  • Thank you for your explanation,it really helps me a lot. I have a few more questions.
    In the above examples it uses the parameter bandwidth equal to 0.
    In this page it says the following```
    In the child "queue" line(s) this directive specifies the maximum bit rate to be processed by the queue at any one time.

    And as far as the upperlimit is concerned i can use it with both realtime and linkshare parameters(or even as a standalone parameter in a queue)? Because i've read that it can be used only as an extension of linkshare.


  • @dpetka2001:

    Thank you for your explanation,it really helps me a lot. I have a few more questions.
    In the above examples it uses the parameter bandwidth equal to 0.
    In this page it says the following```
    In the child "queue" line(s) this directive specifies the maximum bit rate to be processed by the queue at any one time.

    And as far as the upperlimit is concerned i can use it with both realtime and linkshare parameters(or even as a standalone parameter in a queue)? Because i've read that it can be used only as an extension of linkshare.
    

    Short answer: since the 'linkshare' is specified, the 'bandwidth' has no meanings. It is there just by a syntax rule. So, it does not matter if you put there 0 or 100Kb.

    For a long answer, see this sticky thread: http://forum.pfsense.org/index.php/topic,3050.0.html .



  • As for upper-limit curves:

    The upper-limit curve specifies maximal bandwidth (i.e. minimal delay), wheas the real-time curve specifies minimal bandwith (i.e. maximal delay) and the link-share curve specifies 'rational' (read: average) bandwith. (Indeed,  in a very busy environment, if all link-share curves sum to the link bandwith then their bandwith would exactly match the actually observable bandwith utilizations of the queues.)

    Thus the three curves are quite independent and may be used (or unused) in any combination, subjected to the obvious constraint that real-time must be less or equal to upper-limit.

    More details come here: http://forum.pfsense.org/index.php/topic,22885.msg117781.html#msg117781



  • Thank you for your thorough explanation. I will look into it and read very carefully the links you suggested aswell. If I have any more questions i will post back here and hope that i don't put you too much trouble.
    Thank you again for your help.



  • So if I want to limit a queue up to a certain amount of bandwidth I should use the bandwidth parameter without setting linkshare,correct? Or would it be better practice to limit it using upperlimit?



  • @dpetka2001:

    So if I want to limit a queue up to a certain amount of bandwidth I should use the bandwidth parameter without setting linkshare,correct?

    No. Because the Bandwidth is the Linkshare, i.e. it specifies "rational" bandwidth, not the maximal one.

    @dpetka2001:

    Or would it be better practice to limit it using upperlimit?

    Yes. And this is the only way to do that.



  • I think you might take a look to the book Building Firewalls with OpenBSD and PF from Jacek Artymiak, I think its a very good reference. Hope this help


Locked