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] Excess bandwidth sharing
Date: Wed, 08 Oct 2003 17:15:53 +0000	[thread overview]
Message-ID: <marc-lartc-106563346415653@msgid-missing> (raw)
In-Reply-To: <marc-lartc-106561858328271@msgid-missing>

On Wednesday 08 October 2003 15:08, Tom Olexa wrote:
> Hello there,
>
> I do
> tc qdisc add dev eth0 root handle 1: htb r2q 1 default 12
> tc class add dev eth0 parent 1:1 classid 1:10 htb rate 64kbit
> ceil 512kbit tc class add dev eth0 parent 1:1 classid 1:11 htb
> rate 256kbit ceil 512kbit
>
> tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
>         match ip dst 195.28.103.7 flowid 1:10
> tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
>         match ip dst 195.28.103.5 flowid 1:11
>
> and I expect both streams to share the total 512kbit in
> proportion of their rates (1/4). Unfortunately the rates are some
> 100/120, total 512kbit.
> Can anyone tell me whatsda problem?
Your commands :

tc qdisc add dev eth0 root handle 1: htb r2q 1 default 12
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 64kbit ceil 512kbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 256kbit ceil 512kbit

And I think you miss this rule :
tc class add dev eth0 parent 1: classid 1:1 htb rate 512kbit ceil 512kbit

12 is your default class, but you never defined a 1:12 class.

This will happen :
1:10 : 64kbit (the configured rate)
1:11 : 256kbit (the configured rate)
Together : 320kbit

But the total is 512kbit, so 512-320 = 192kbit.
So class 1:10 get's an additional 192 * 64 / (64 + 256 ) = 38.4 kbit
So class 1:11 get's an additional 192 * 256 / (64 + 256 ) = 153.6 kbit
Actually, this is related to the quantum of the class.  But you never 
overruled the quantum, so the quantum of the class is rate / 1 (r2q 
parameter.  But 512kbit means a quantum of 512 / 8 = 64kilo byte and I think 
this is maybe too big.  Don't you have htb errors in your kernel log files ??

If you are interested in more tests and extra information, see www.docum.org 
on my tests pages.

Stef

-- 
stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.openprojects.net

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

      reply	other threads:[~2003-10-08 17:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-08 13:08 [LARTC] Excess bandwidth sharing Tom Olexa
2003-10-08 17:15 ` 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-106563346415653@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.