All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] wondershaper prio question
Date: Mon, 12 May 2003 07:12:46 +0000	[thread overview]
Message-ID: <marc-lartc-105272364709062@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105252628702452@msgid-missing>

On Saturday 10 May 2003 02:23, John McCain wrote:
> Referencing the cbq wondershaper as a discussion example, let me ask a
> stupid question with regard to how the rules actually work and what they
> actually do.
>
> "Prio" is discussed in the howto as a qdisc, but in the wondershaper, it
> appears to be a cbq parameter rather than a qdisc in its own right.  My
> question is this:
You have the prio qdisc that can be used to transmit packets.
But you also have the prio option that can be used if you add a class or a 
filter.  For the filters, it detemines the order the filters are checked.  
For the classes, it depends.  For a htb class, it determines the latency and 
the borrowing scheme of the class.  I'm not sure what it does for a cbq 
class, but I think the packets of the lowest prio cbq class or sended first.

> If the outgoing queue is full of traffic identified as "traffic we hate",
> or 1:30 at prio 2, what exactly is the behavior of the system for a ping
> packet, for example, which should classify as 1:10 at prio 1?  Does the
> ping packet bypass the 1:30 line, because it's prio is lower? (discounting
> stochastic fairness behavior)
>
> If, as is the case with 1:20 and 1:30 in the wondershaper, the prio is
> identical but bandwidth is different, how exactly does the system behave?
> Will it look at every outbound packet in the queue, make a bandwidth
> decision, and then either send the packet or skip it?  Let's assume the
> example as above - a queue full of 1:30 traffic, and here comes a 1:20
> packet.  I'm guessing the kernel is cycling through each 1:30 packet and
> deciding not to forward it yet, then coming to the 1:20 packet, and
> forwarding it because 1:20's bandwidth is higher.
>
> As I understand it, if we were to analogize this process with a line (queue
> for our UK friends) at a resturaunt, for example, the first situation, with
> two different prios, would take the form of two differnt lines, such that
> (again, discounting sfq for the purposes of discussion) no one in the prio
> 2 line could be seated if anyone was standing in the prio 1 line.
>
> The second situation, with the same prio level for each queue, would be
> represented by a single line, but where the matre'd asks the first person a
> question to determine their queue class, finds that the resturaunt is at
> its maximum level for that type of "customer", then moves on to the second
> in line and so on until reaching the 1:20 "customer", who then is removed
> from the back of the line and seated.
>
> Is this the meaning of "prio" in the wondershaper?  If not, what's really
> happening?

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

      reply	other threads:[~2003-05-12  7:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-10  0:23 [LARTC] wondershaper prio question John McCain
2003-05-12  7:12 ` Stef Coene [this message]

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=marc-lartc-105272364709062@msgid-missing \
    --to=stef.coene@docum.org \
    --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.