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

Re: priq and bandwidth definition

On Sat, Oct 01, 2005 at 06:53:12PM -0400, Matt Van Mater wrote:
> I have a similar setup to what Daniel specifies in
> http://www.benzedrine.cx/ackpri.html but have a nagging question that
> I haven't been able to find an answer for.
> Why do you need to specify bandwidth on the parent queue in order for
> the prioritizations to work correctly?
  queueing is only able to queue when there's a queue.  there won't
  be (much of) a queue unless the traffic is traversing an interface
  slower then the rate at which it wants to.
  if i had fourteen arms(and a hand on each), and my purpose in life 
  was to carry different coloured blocks from A to B, and i had a traffic
  shaping mechanism by which i would prioritize one colour of block over
  an other (let's say yellow gets high priority, then blue, then black
  gets lowest), and one yellow and one blue block comes in for me
  to pick up, it doesn't matter what the priority is because i have
  12 more arms who aren't used.  my limbs aren't congested, and
  i will be able to deliver the blocks from A to B as quick as my 
  feet can move me.
  if 14 blocks come in, it still doesn't matter, because there
  are no blocks which i have to choose to leave behind; even
  if there are 4 yellow, 5 blue and 5 black, doesn't matter, 
  they all go from A to B at the same rate.
  if 20 blocks come in for me to move, then i have an opportunity
  to prioritize.  if 10 blocks are blue, 4 are yellow and 6 are black,
  i am going to leave those 6 black blocks behind, take the 4 yellow
  and 10 blue with me from A to B, dump them, come back, and 
  then if the number of blocks waiting for me is > 14 again (including
  the 6 old black ones ), then i prioritize again.  if the total
  number of blocks is <= 14, i just pick 'em all up and take 'em.
> Shouldn't the packet scheduler
> always transmit higher priority packets before lower priority packets
> regardless of the bandwidth cap that is specified? 
  i believe that in the general case, or at least in altq, the
  answer is no.
> In my situation,
> the 'lowdelay' SSH sessions are unbearably slow unless I set my
> bandwidth down to 300Kb.  Of course this solves the problem of poor
> interactive SSH performance, but it means I am sacrificing ~200Kb of
> potential speed in order to attain that.
  bandwidth and delay are coupled in priq and cbq schedulers; if
  you need them to be uncoupled, examine hfsc ( it is possible to 
  setup hfsc to be real darn close to priq or real darn close to
  cbq, and then have one or two queues which take advantage of
  hfsc's properties ).
  priq will obey you.  if you set two queues, HI and LO, and
  all the data coming in to HI is enough to fill the pipe, 
  LO will not be serviced until there is room.
  for a simple test, make two queues, one for default and one
  for ICMP; set default higher priority, and set the altq
  bandwidth to something real low, so that you can test it 
  easily (~32Kb or so).  might as well do this on your
  interface between the openbsd and your LAN, so you can be
  sure you can saturate the link with whatever you set altq
  bandwidth to.
  then start something that eats a lot of bandwith; run 
  worms(6) over ssh a couple of times, open up chargen in inetd,
  do an ftp, netcat /dev/zero on one host to /dev/null on another,
  then try pinging the openbsd machine.
  if you setup your queues right, you will not get a reply
  until you stop that other traffic enough so that there is
  bandwidth available for the outgoing echo reply.
  can't explain specifically to you why the ssh is slow unless
  you set the cap down, without seeing the rulset/altq declaration,
  which the example below seems to be a theoretical one and
  not what you're using (?) 
> The parser accepts the following lines
> altq on $ext_if priq queue {default, torrent}
>    queue default priority 15 priq (default)
>    queue torrent priority 1 priq (red)
> ..
> pass out quick on $ext_if from any to any keep state queue (torrent, default)
> and the documentation says that if a limit is not specified, it will
> simply use the maximum rate of the interface specified (which I think
> is translated into 100 mbit in my case).  This interface connects to a
> cable modem that has roughly 4mbit down so of course that 100 mbit
> assumption isn't quite right.
  100 mbit isn't an assumption
  it's the linkspeed of that interface (ethernet between you and
  cable modem)
  also, the download capper between the ISP and you is not the
  issue here.  you could have 44Mb/s download and it won't
  change your scenario as pf sees it; the upload you expect between
  you and the ISP is what you should be concerned with.
  the altq bandwidth is, going along with my crappy hindu god
  analogy up top, setting the number of arms you have.
> I have tried the other schedulers, but can't think of why a simple
> weighted queueing shouldn't work for me.  Can anyone explain this to
> me?
  sounds like you have 6 black blocks waiting at point A while
  > 14 blue or yellow ones keep coming in.
[ openbsd 3.8 GENERIC ( sep 10 ) // i386 ]