All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Furniss <andy.furniss@dsl.pipex.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] wrr vs. htb
Date: Wed, 27 Jul 2005 22:23:40 +0000	[thread overview]
Message-ID: <42E8096C.4040208@dsl.pipex.com> (raw)
In-Reply-To: <fad9d48405072603541bc984b7@mail.gmail.com>

Kenneth Kalmer wrote:
> On 7/27/05, Peter Surda <surda@shurdix.com> wrote:
> 
>>On Wed, 27 Jul 2005 12:01:06 +0200 Kenneth Kalmer <kenneth.kalmer@gmail.com>
>>wrote:
>>
>>
>>>It's one server, fulfilling two functions, gateway en network service delivery
>>
>>Ok, now I get it. You can use IMQ and that will solve the problem. Or you can
>>use a separate computer as a gateway.
>>
>>
>>>                :0 HTB
>>>              /     \
>>>  (HTB) 1:0     2:0 (HTB)
>>>             |         |
>>>   WRR 1:1     1:2 WRR
>>
>>WRR doesn't like situations like this (don't ask why, some bug somewhere), the
>>computer tends to  freeze unpredictably.
> 
> 
> Ouch, well now each of the WRR discs will be replaced by HTB discs for
> each user, currently 140 discs for each WRR disc... Any other ways to
> do this, or will HTB cope? This can expand up to 2x 509 discs...

Do you really need to shape the local traffic at all though?

I would be tempted to just shape inet traffic.

If you use wrr then you won't be able to ceil each user anymore - if you 
don't mind loosing that, then you could also consider esfq, it's not as 
perfect as wrr but at least you get to choose a queue length more 
suitable for your link speed.

> 
> How can I then handle the equality issues better, should I just pray
> that HTB will divide all excess fairly? Also, I forgot to mention that
> each HTB for each client get's an SFQ as well, just so that they don't
> kill themselves in the process. Is this kosher?

We are talking about shaping downloads here - if so then I think the 
equality problem could be more to do with loosing control while trying 
to shape from the wrong end of the bottleneck.

You may well be dropping packets at ISP/teleco rather than in your 
queues - which with the amount of bandwidth per user you have is going 
to be tricky to sort.

In fact unless you are using limit 10 or something on sfqs you may not 
be dropping any at all.

How many users are active at peak times, are you doing nat and how much 
do they care about latency etc would affect how I would approach this.

Andy.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

      parent reply	other threads:[~2005-07-27 22:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-26 10:54 [LARTC] wrr vs. htb Kenneth Kalmer
2005-07-26 15:00 ` Peter Surda
2005-07-27 10:01 ` Kenneth Kalmer
2005-07-27 13:47 ` Kenneth Kalmer
2005-07-27 22:23 ` Andy Furniss [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=42E8096C.4040208@dsl.pipex.com \
    --to=andy.furniss@dsl.pipex.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 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.