On Mon, Jan 03, 2005 at 02:33:37PM -0800, John Ricardo wrote:
> 1. In general, where does "priority" count? Are priority values only
> considered at a parent queue with respect to the child queues, or are
> they considered at the root with respect to all the leaf queues, or...?
i am currently unsure myself how to extract much use out of priority,
and have stopped using it entirely.
perhaps it works best if _not_ combined with actual service curves,
but just flat bandwidth declarations -- but in that case it would
seem to me that you're kinda just doing cbq with a little bit of
finer granularity, rather than actually trying to get the most out of
hfsc?
i try to set good <sc> values, and as an experiment while on a
couple bittorrents ( each individual torrent had its own queue ),
i set the priority of one higher than the other and restarted them.
i didn't see any difference at all after the queues settled into
stride than when they were the same priority, but that is, i would
estimate, a fault of my configuration and not a fault of the mechanism.
> 2. Does "realtime" imply that the bandwidth specified is left unused
> unless that queue sees packets, or is it simply a priority mechanism?
"realtime" is the bandwidth that each queue is absolutely guaranteed
to get in any circumstance where data is being queued into said queue
( ie - that queue is actively pumping data ). that might be an
inaccruate explanation technically, but it seems at least as a decent
mental-model foundation.
"linkshare" is each queue's ability to suck down extra bandwidth
from surplus after the active queues' realtimes have been satisfied.
"upperlimit" is the maximum bandwidth a queue can consume if there's
still bandwidth left over after satisfying linkshares.
i guess i am thinking of surplus as a condition where the amount
of data being queued is less than the sum of bandwidth expressed
by the culimation of all "realtime"s.
to directly answer your question, yes, the bandwidth specified is
unused unless the queue sees packets, and no, it is not *simply*
a priority mechansim - it is a guarantee-of-bandwidth mechanism which
can be setup to imply priority but doesn't necessarily have to always
mean priority.
if you have 4 queues, each split the same way for simplicity:
( i will also set flat non-curve service classes for simplicity )
---
altq on $e hfsc bandwidth 512Kb queue{ q-1 q-2 q-3 q-4 }
queue q-1 bandwidth 10% hfsc(default realtime 20% linkshare 10%
upperlimit 100%)
queue q-2 bandwidth 10% hfsc(realtime 20% linkshare 10% upperlimit 100%)
queue q-3 bandwidth 10% hfsc(realtime 20% linkshare 10% upperlimit 100%)
queue q-4 bandwidth 10% hfsc(realtime 20% linkshare 10% upperlimit 100%)
---
if at a specific moment, you only have data queued in q-2 and q-3, say,
and that's all that is happening, each one wil first satisfy itself
from the realtime allocation. that means they'll stake out 20% of
the bandwidth each ( total 40% ), and if after that has been allocated
to them, they look around and see surplus bandwidth ( the rest of the 60% ),
they will take their linkshare percentages also, and as long as nobody
else competes for linkshare, they will each try to approach 100%, which,
as they are set equally, provided the connection at the other end of
the transmissions are equal, they will ride along at about the same
usage %.
perhaps in this case if you set priority of one of them higher than the
other, you might see the higher priority queue realizing more bandwidth.
if i used '25%' for realtime and all queues were in FULL SATURATED
use, there wouldn't be any linkshare left because they'd each be seeing
25% of the altq's bw. if they were each 25% and not in full saturated
use, then there is linkshare left, until such a point as they would
all become fully saturated. then someone who had previously been
using more than their 25% realtime would have to relinquish some bw.
> 3. How does queue priority, implemented with the "priority" keyword,
> interact with the "realtime" specification? That is, where does the
> "realtime" part come into play vs. the "priority" property?
see re: #1. hopefully someone else can come trotting and make me
sound dumb about priority, as i'm still kinda flailing around
to get a successful config where it makes a difference.
> 4. Along the lines of what was brought up before, what is the
> difference between "linkshare" and the "bandwidth" specification? I'm
> aware that "bandwidth" is intended to be a quick way to specify things,
> but if we are using "linkshare", can it be omitted? If not, what is
> the interaction between the two?
the actual bandwidth specification i am not sure about. i noticed
that if i omitted it, pfctl would complain about the bandwidth
allocations having achieved 100% before all queues were parsed.
( and haven't tried again since about 3.4-current afair ).
i also noticed that my hfsc serviceclasses seem to be authoritative
over the bandwidth declaration. at the moment, i just set the
bandwidth % low enough so that the sum of all of them is less than
the altq's bandwidth setting, to keep pfctl from hating me, and then
i do my work in the serviceclasses.
> 5. Is it necessary to provide bandwidth/scheduler specifications for
> parent queues if specifications are given for all the leaf queues? Is
> there any benefit to doing so?
it is not necessary to specify parent specs if specs are given for
leaves.
i am at this moment unsure if one can queue into an actual parent
queue/node if it has child/leaf nodes.
i don't see there being any benefit to doing so over the benefit
of having a properly setup leaf node used for that purpose.
worth mentioning in this case is that the sum of all the leaves
on a particular branch is relative to its parent and not the
tree as a whole. i think that used to be different, and was
was an issue a while ago and was fixed -- i seem to have a foggy
memory of that.
for instance, here is my altq on the machine on the LAN i do
the bittorrent on. i have bittorrent queues setup in consideration
of my actual bandwidth up to my ISP, and the rest of it i
use very simple queue strategy for this machine's traffic which
will never leave the LAN.
------
i="dc0"
btqueue="512Kb"
altq on $i hfsc bandwidth 100Mb tbrsize 1500 queue { data, ack,
bittorrent, crapola }
queue data bandwidth 80% hfsc(realtime (25% 250 10%) linkshare (45% 500
10%) upperlimit 96% default ) qlimit 1000
queue ack bandwidth 5% hfsc(realtime (10% 100 1%) linkshare (10% 100 1%)
upperlimit 4% ) qlimit 1000
queue bittorrent bandwidth $btqueue hfsc(realtime 1Kb upperlimit $btqueue )\
{ bt_def bt_6881 bt_6882 bt_6883 bt_6884 bt_6885 bt_6886 bt_6887
bt_6888 bt_6889 }
queue bt_def bandwidth 9% hfsc(realtime(10% 100 1%) linkshare(0% 80000 2%)
upperlimit 100Kb) qlimit 2000
queue bt_6881 bandwidth 9% hfsc(realtime(10% 1000 1%) linkshare(0% 30000
5%) upperlimit $btqueue) qlimit 2000
queue bt_6882 bandwidth 9% hfsc(realtime(10% 1000 1%) linkshare(0% 30000
5%) upperlimit $btqueue) qlimit 2000
queue bt_6883 bandwidth 9% hfsc(realtime(10% 1000 1%) linkshare(0% 30000
5%) upperlimit $btqueue) qlimit 2000
queue bt_6884 bandwidth 9% hfsc(realtime(10% 1000 1%) linkshare(0% 30000
5%) upperlimit $btqueue) qlimit 2000
queue bt_6885 bandwidth 9% hfsc(realtime(10% 1000 1%) linkshare(0% 30000
5%) upperlimit $btqueue) qlimit 2000
queue bt_6886 bandwidth 9% hfsc(realtime(10% 1000 1%) linkshare(0% 30000
5%) upperlimit $btqueue) qlimit 2000
queue bt_6887 bandwidth 9% hfsc(realtime(10% 1000 1%) linkshare(0% 30000
5%) upperlimit $btqueue) qlimit 2000
queue bt_6888 bandwidth 9% hfsc(realtime(10% 1000 1%) linkshare(0% 30000
5%) upperlimit $btqueue) qlimit 2000
queue bt_6889 bandwidth 9% hfsc(realtime(10% 1000 1%) linkshare(0% 30000
5%) upperlimit $btqueue) qlimit 2000
queue crapola bandwidth 100b hfsc qlimit 10
-----
i set tbrsize because i wanted to adjust that to be more like what
the tbrsize is calculated to be if 'altq bandwidth' is accurate
to what my internet connection upstream is, which is certainly
not 100Mb/s.
that "crossbow" HFSC page... go read it like 90 more times.
every time i read it i get a little closer to understanding
HFSC. i love that page.
jared
ps - one real bitchin' thing i have, is on the external ISP-facing
gateway, i have a queue setup for pings-to-me, and have the
bandwidth allocated to my ICMP_REPLYs really castrated.
it took me about 5min worth of time and math to get it right, but
basically it is setup to allocate just enough bandwidth to the
outgoing replies so that if one ping-per-second to me, the ping
is accurate and fast, but if more than one ping-per-second to me,
it is entertaining to watch the RTT grow and grow -- and then
if you stop/cancel one of the pings, the RTT goes back down to
normal. i must mention two things: 1) it is of course with
respect to a normal default pingsize in openbsd, and 2) i
am doing this not because i think it makes me UltraSecure
ZoneAlarmPIXSonicWall Secure(tm), but because it was a learning
excercise for hfsc.
---
queue icmpreply bandwidth 64b hfsc( red realtime(0b 100 512b) \
linkshare( 0b 10000 1024b) upperlimit 1024b ) qlimit 500
---
if you want to see it in action, 65.37.7.224. if you are on
stupid windows, don't forget -t and to set -w to stupid high.
if you see anything greater than about 200ms from anywhere in
usa, maybe someone else is playing with it now?. i should be
somewhere < 40ms from most places in NY typically.
jared
--
[ openbsd 3.6 GENERIC ( dec 11 ) // i386 ]
