From: Patrick McHardy <kaber@trash.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] HFSC and prioritization
Date: Fri, 12 May 2006 16:56:38 +0000 [thread overview]
Message-ID: <4464BE46.4080609@trash.net> (raw)
In-Reply-To: <0633E0EDB4F25F43A2D7179CA11FAFAB25533F@xavier.staff.greatlakes.net>
Jody Shumaker wrote:
>> HFSC doesn't support strict priorities (and neither does HTB, the
>> priorities just affect unused bandwidth and is still limited by the
>> ceiling). At least in the case of HFSC this is intentional, strict
>> priority is not very friendly because it allows traffic to be
>> entirely excluded, HFSC's goals are to enable flexible sharing by
>> allowing to seperately specify bandwidth and delay requirements.
>> If you really want strict priority you can use the prio qdisc as
>> _child_ of HFSC.
>>
>
> I always forget this about the prio and HTB. With HSFC does use of
> the the max latency settings possibly get the desired goal from using
> prio? I think this is what always appealed to me about HSFC from the
> little I could understand. That if I had an interactive class, it'd
> always favor getting those packets through sooner than others, trying
> to honor a latency, if I set it up correctly.
Exactly. I think strict priority is mostly used because of laziness,
unknown conditions or unflexible algorithms. You almost never want
one kind of traffic to be able to stall everything else (which BTW
raises some doubts about Linux's default choice of a 3band prio qdisc).
HFSC solves one and a half of these problems: without seperated
bandwidth/delay specifications you are unable to express that some
traffic should get good delay but doesn't need much guaranteed
bandwidth, so you have to use priorities. The half solved problem
is unknown conditions, it can also work in work-conserving mode,
which means that it will work fine on wireless or similar networks
or without any maximum bandwidth specification, but in that case
it can only provide fair sharing, no absolute guarantees. Only
half-solved because the unknown condition could also be the amount
of bandwidth or the delay required, in which case strict priority
might be the only viable option.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next prev parent reply other threads:[~2006-05-12 16:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-11 17:02 [LARTC] HFSC and prioritization Eliot, Wireless and Server Administrator, Great Lakes Internet
2006-05-11 20:19 ` Jody Shumaker
2006-05-12 5:24 ` Patrick McHardy
2006-05-12 5:31 ` Patrick McHardy
2006-05-12 8:03 ` Patrick McHardy
2006-05-12 13:33 ` Andy Furniss
2006-05-12 15:30 ` Jody Shumaker
2006-05-12 16:42 ` Patrick McHardy
2006-05-12 16:56 ` Patrick McHardy [this message]
2006-05-12 17:49 ` Alexandru Dragoi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4464BE46.4080609@trash.net \
--to=kaber@trash.net \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.