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] Prio and latency with HTB Classes
Date: Sun, 25 May 2003 17:51:14 +0000	[thread overview]
Message-ID: <marc-lartc-105388518911634@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105388139909161@msgid-missing>

On Sunday 25 May 2003 18:46, GoMi wrote:
> Sorry if you have already answered this question, but i have a big mess
> right now.. I red the lartg FAQ and it literally says:
>
> "If you have 2 htb classes with different prio parameters, the class with
> the lowest prio parameter gets all the remaining bandwidth from the parent
> (after the other class has received its rate). The class with the lowest
> parameter will also the class with the lowest latency. However, if this
> class is overlimited (there is more traffic then the configured rate), the
> latency can go up. "
>
>
> I have to classes, and i have interactive traffic and non-interactive
> traffic, each assigned to one of these classes.
>
> When i get lots of tcp connections to the non-interactive and it begins to
> ceil, then it seems not to lend that bw again whenever the
> interactive-class needs it. They are configured like this:
It can take some time before the non-interactive traffic will slow down if you 
generate interactive traffic.  You can prevent this by ceiling the 
non-interactive traffic so there is always some minimal bandwidth left for 
the interactive traffic.

> tc class add dev ${DEV} parent 1:1 classid 1:10 htb prio 1 rate 200kbit
> ceil 300kbit
> tc class add dev ${DEV} parent 1:1 classid 1:20 htb prio 2 rate 100kbit
> ceil 300kbit
>
>
> I dont understand this " However, if this class is overlimited (there is
> more traffic then the configured rate), the latency can go up. " <-- What
> should i do? Which prio should i set, so that interactive traffic class has
> low latency and has the highest prio?
You have to create a low prio class for your interactive class with rate = 
maximum traffic that you ever expect in that class.  If you send more data in 
the class, the latency will go up.  Example :
class 1, rate 50 kbit
  class 10, prio 1, rate 10 kbit
  class 11, prio 2, rate 10 kbit
  class 12, prio 2, rate 80 kbit

If class 10 is sending less then 10kbit, the latency will be low.  But if that 
class sends more then 10kbit, the latency will go up.  You can prevent this 
by using policers in your filters so you can control how many packets are 
sended to class 10.

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-25 17:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-25 16:46 [LARTC] Prio and latency with HTB Classes GoMi
2003-05-25 17:51 ` 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-105388518911634@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.