Linux Advanced Routing and Traffic Control list
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox