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] various questions about tc & htb
Date: Fri, 29 Nov 2002 17:17:04 +0000	[thread overview]
Message-ID: <marc-lartc-103859032602295@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103849092823505@msgid-missing>

On Friday 29 November 2002 14:25, Mathieu Deziel wrote:
> > Prio in htb classes is used to give a) one class the first choice in
> > excess bandwidth and b) to give the class lower delays.
>
> About b) above, will HTB just "do its best" to give classes with lower prio
> a better delay, or will it truly work like a priority queuing mechanism (up
> to the rate, of course)?
That's one of the things I have to figure out.  Htb will give the class with 
the highest priority the lowest delay.  BUT if this class is overlimited (if 
it sends more then it's rate), the underlimited part (the other classes) are 
serverd first and the delays increases a lot.  See htb "USer Guid" on the htb 
homepage.  
So if you want a class with very low delays, you can give it a lower prio, BUT 
make sure the class is never overlimited or the delay will increase a lot.  
I'm planning to do some tests.  I think it's possible to use the policer in 
the filters to make sure the class is never overlimited.

> In other words, how does the scheduling algorithm deals with "prio" in HTB
> ? I think the answer to this question is a very inportant for anyone who is
> considering to have EF traffic in HTB.  I was not able to find a technical
> and precise answer to it up to now.
Me neither.  I'm planning to do some tests and read some sources around the 
problem so I can clear it out.  I did the same with the quantum parameter and 
Devik was so nice to answer all my mails.  But I promised him some good 
Belgium beer, so he had no choice :)

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/

      parent reply	other threads:[~2002-11-29 17:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-28 13:40 [LARTC] various questions about tc & htb Abraham van der Merwe
2002-11-28 15:56 ` Stef Coene
2002-11-28 16:45 ` Abraham van der Merwe
2002-11-28 17:18 ` Stef Coene
2002-11-28 17:22 ` Stef Coene
2002-11-28 17:59 ` Abraham van der Merwe
2002-11-29 12:56 ` Mathieu Deziel
2002-11-29 13:25 ` Mathieu Deziel
2002-11-29 17:11 ` Stef Coene
2002-11-29 17:17 ` 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-103859032602295@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.