[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Specific HFSC questions



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 ]