Patrick McHardy wrote:
This is currently all there is. If you have some specific questions, just ask (but please CC lartc). If anyone wants to write some documentation I'd be happy to help, but I don't have time for it myself.
I am not sure if the original poster has specific questions, but I sure do.
I just recently got into this HFSC mess myself, so I'm a bit fuzzy in all the terms and differences in implementation. I read the paper (SIGCOM97) on HFSC and I think I understood most of it. But there are some things in the implementation that I couldn't really realize.
I'll quote the usage here for reference:
,----
| Usage: ... hfsc [ rt SC ] [ ls SC ] [ ul SC ]
| | SC := [ [ m1 BPS ] [ d SEC ] m2 BPS
| | m1 : slope of first segment
| d : x-coordinate of intersection
| m2 : slope of second segment
`----
Okay, the SC parameters I think I understand rather well - they are there to define the service curve itself. But the way hfsc takes three optional parameters of service curves puzzles me.
I believe 'rt' referes to 'Real-Time Service Curve', 'ls' to 'Link Sharing Service Curve' and 'ul' to 'Upper Limit Service Curve'. If I understand correctly, the SIGCOM97 paper mentioned that the link sharing selection need not be the same as the real time selection, but in examples assumed for simplicity that they were. Also, from the source I conclude that 'Upper Limit Service Curve' cannot be specified without 'Link Sharing Service Curve'.
Correct so far.
So, this, all in all, baffles me :-)
The possible combinations I can make here are:
Real-Time Link-Sharing Real-Time, Link-Sharing Link-Sharing, Upper-Limit Real-Time, Link-Sharing, Upper-Limit
How do these behave? If I specify *only* the real-time curve, what is used for the link-sharing part? Or does that mean that there is no sharing? Or if I only specify the link-sharing curve, does that mean that no specific deadlines are for packets, just that they are sent based on the link-sharing model? And what actually is the upper-limit service curve? I take it that it is some kind of a packet drop curve, but I don't know how it would behave - nor why it would require the link-sharing curve.
The combinations you list are correct. Real-time curves are only valid for leaf-classes, whereas link-sharing and upper-limit curves are valid for all classes in the heirarchy. When multiple curves are used, the following must hold: rt <= ls <= ul
To understand why there are two (forgetting about upper-limit curves for now) different curves your need to know that scheduling in HFSC is based on two criteria: the real-time criterion which ensures that the guarantees of leaf-classes are met and the link-sharing criterion which tries to satisfy the service curves of intermediate classes and distributes excess bandwidth fairly. The reason why there are two different criteria is that in the Fair Service Link-sharing model that is approximated by HFSC it is not always possible to guarantee the service of all classes simultaneously at all times (with non-linear service curves). HFSC chooses to guarantee the service curves of (real-time) leaf-classes (because only leaves carry packets), and uses the link-sharing criterion to minimize the discrepancy between the actual service received and the service defined by the Fair Service Link-sharing Model.
The upper-limit curve is used to limit the link-sharing curve. Without an upper-limit curve, packets are dequeued at the speed the underlying device is capable of. For example in the case of software devices, this is not very desireable, so you can limit the total output rate.
For your other questions: - If you specify only a real-time service curve the class will not participate in link-sharing. This means it can only send at it's configured rate. The difference two a link-share+upper-limit curve is that the service is guaranteed.
- If you specify only a link-share curve their are no deadlines and no guarantees can be given.
Some other notes you might find helpful: - The sum of all real-time curves must not exceed 100%.
- The actual bandwidth assigned to link-sharing classes doesn't matter, only the relative difference between sibling-classes is important
So, any pointers on these would be helpful, or if you manage to get the time to explain it specifically.
I will probably cook up atleast an example script using HFSC for normal QoS if I manage to understand how it works, perhaps even some documentation.
Great! I started some documentation last year, but never got to finishing it. I can send it to you in private, but I don't want to publish it as long as it's unfinished.
Regards Patrick
-- Naked
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
