All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Klauer <Andreas.Klauer@metamorpher.de>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] HTB, strange capacity distribution
Date: Wed, 22 Feb 2006 17:15:42 +0000	[thread overview]
Message-ID: <20060222171542.GA10856@EIS> (raw)
In-Reply-To: <131577286.20060220225933@elusion.sk>

On Tue, Feb 21, 2006 at 02:21:36PM +0100, Boris Gereg wrote:
> thanks Andreas, I reconfigured HTB to get your suggested hierarhy:

One thing I forgot in my graph: Make sure that the rates always add up, 
i.e. the sum of the child class rates should equal the parent class rate. 
It's unlikely to be the cause of your problem, but it's important to get 
this right nevertheless.

> Any other things to test, please?

Just to see wether we are going into the right direction at all, could 
you run the following experiment:

- Lower the rate and ceil of class 1:2 to 8096kbit.
- Lower the rate and ceil of class 1:2000 to 7072kbit.
- Lower the rate and ceil of class 1:3000 to 1024kbit.
- For class 1:3010, set rate to 64kbit, ceil to 256kbit.
- For class 1:3020, set rate to 128kbit, ceil to 768kbit.
- For class 1:3040, set rate to 704kbit, ceil to 1024kbit.
- For class 1:5040, set rate to 128kbit, ceil to 1024kbit.

(You can adjust the rates for these classes as you like, just make sure 
 that the sum is 1024kbit)

If in this setup the shaping works as expected - WWW should get 704kbit 
at all times, P2P only slightly more than 128kbit while WWW downloads 
are active - then the limiting and distribution of HTB most likely works, 
and it's just too high rates or r2q/quantum that make it go bad. In this 
case, you'd have to measure realistic throughput rates of your network 
(even a 100mbit LAN may not be able to guarantee 100000kbit at all times) 
and of your internet connection (may not be able to serve 2048kbit at 
all times). For downstream shaping to work, you have to be the bottleneck.

If you get the same problem in this setup (P2P taking all the bandwidth 
away from WWW), then the problem is most likely something different, 
and we have to look at it from a different angle.

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

  parent reply	other threads:[~2006-02-22 17:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-20 21:59 [LARTC] HTB, strange capacity distribution Boris Gereg
2006-02-20 22:59 ` Andreas Klauer
2006-02-21  7:52 ` Andreas Klauer
2006-02-21 13:21 ` Boris Gereg
2006-02-22 17:15 ` Andreas Klauer [this message]
2006-02-23  7:11 ` Andreas Klauer

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=20060222171542.GA10856@EIS \
    --to=andreas.klauer@metamorpher.de \
    --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.