Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
From: Patrick Turley <pturley@rocksteady.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] r2q error with HTB
Date: Fri, 08 Aug 2003 17:06:10 +0000	[thread overview]
Message-ID: <marc-lartc-106036265010309@msgid-missing> (raw)
In-Reply-To: <marc-lartc-106029492417993@msgid-missing>

On Fri, 2003-08-08 at 00:51, Stef Coene wrote:
> On Friday 08 August 2003 00:20, Patrick Turley wrote:
> > (This is a re-statement of a question I asked earlier)
> >
> > I have a number of HTB classes feeding into a root HTB qdisc. Whenever I
> > set the rate on any of the subordinate classes to 78 kpbs or less, I get
> > the following message:
> >
> >
> > HTB : quantum of class <class ID> is small. Consider r2q change.
> >
> >
> > I've done some reading about the meaning of r2q, and I understand it
> > now:
> >
> >     quantum = rate/r2q
> >
> > where:
> >
> >     rate is expressed in kilobits per second
> >     quantum is expressed in bytes
> >     r2q has the appropriate units and is 10 by default
> >
> > Based on what I've read, it's not at all clear why HTB would complain
> > about a rate of 78Kbit. That corresponds to a quantum of 7800 bytes,
> > which is much larger than the maximum Ethernet packet size (1500).
> >
> > Anyone have a clue?
> Yes.  78kbit = 9.75kbyte.  So quantum = 9.75kilobyte/10 = 975byte.
> 
> Stef

<blush>

OK, I wish I hadn't made that silly mistake.

79Kbit = 80896 bits/sec = 10112 bytes/sec

10112 bytes/sec / 10 r2q => quantum > 1000 bytes

I conclude, then, that HTB will spit out a warning when the quantum
implied by the subclass drops below 1000 bytes. This is useful
information.

As I said before, I have a number of classes feeding into the root.
These classes can have widely varying rate limits, and they can change
dynamically. Therefore, to avoid encountering the problem that this
message indicates, I need to estimate the lowest reasonable rate limit
and select an r2q that will just barely keep this rate's quantum above
1000. A lower rate limit of 50Kbit seems reasonable for my application:

50Kbit = 51200 bits/sec = 6400 bytes/sec

6400 bytes/sec / 1000 bytes = 6 r2q

According to Stef's FAQ at
http://qos.dyndns.org:3389/cgi-bin/fom?_highlightWords=r2q&file1, the
buit-in limit for the quantum is 60000 bytes. Even though I've reduced
the value of r2q, I still won't hit this limit until the rate exceeds:

60000 bytes * 6 r2q = 360000 bytes/sec => 2.74Mbit

This is acceptable.


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

      parent reply	other threads:[~2003-08-08 17:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-07 22:20 [LARTC] r2q error with HTB Patrick Turley
2003-08-08  5:51 ` Stef Coene
2003-08-08 17:06 ` Patrick Turley [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-106036265010309@msgid-missing \
    --to=pturley@rocksteady.com \
    --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