From: Damion de Soto <damion@snapgear.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] general shaping recommendations
Date: Mon, 22 Dec 2003 03:00:09 +0000 [thread overview]
Message-ID: <marc-lartc-107208749426446@msgid-missing> (raw)
In-Reply-To: <marc-lartc-107179092006530@msgid-missing>
Hi Martin,
> There's no reason not to use ingress policers if you wish. I would
> recommend, however, shaping on both the inbound and outbound traffic.
If I'm running a web proxy on the gateway, then I would need ingress policer to limit
the download bandwith for web requests.
How will the ingress policer on the WAN interface interact with the other egress htb
classes on the LAN interface ?
> I'm fairly certain that the above is not what you desire. When you
> specify a "rate" in a class, that class will ALWAYS consume up to that
> available amount of bandwidth before checking to see if the parent has any
> bandwidth to lend. So, you will want to change this.
Ok, I see this and have fixed it.
So the wondershaper is wrong ? it doesn't use the ceil values and creates rate
values that sum up to a higher value than your ISP bandwidth.
> [ snip ] classid 1:1 htb rate 512kbit burst 6k
> [ snip ] classid 1:10 htb rate 256kbit ceil 512kbit burst 6k prio 1
> [ snip ] classid 1:20 htb rate 96kbit ceil 460kbit burst 6k prio 2
> [ snip ] classid 1:30 htb rate 96kbit ceil 409kbit burst 6k prio 2
>
> Look at the sum of the rates of the children classes, this is
> class 1:10 1:20 1:30
> $ expr 256 + 96 + 96
> 448
Did you just guess at the ceiling numbers, or did you calculate them using some method?
> I don't know if my explanation will help, but check out my description of
> the HTB model [1]. Be sure to read Martin Devera's description [2], and
> also consider Stef Coene's documentation [3] and tests [4]. His tests
> show how bandwidth is distributed/allocated under various
> conditions--essentially these graphs provide a good way to understand the
> behaviour of HTB.
Thanks, I didn't realise there was a 'LARTC HOWTO' and a 'Traffic Control HOWTO'
The latter is much more useful and the diagrams are very helpful.
regards,
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damion de Soto - Software Engineer email: damion@snapgear.com
SnapGear - A CyberGuard Company --- ph: +61 7 3435 2809
| Custom Embedded Solutions fax: +61 7 3891 3630
| and Security Appliances web: http://www.snapgear.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--- Free Embedded Linux Distro at http://www.snapgear.org ---
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
prev parent reply other threads:[~2003-12-22 3:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-18 23:26 [LARTC] general shaping recommendations Damion de Soto
2003-12-19 0:15 ` Martin A. Brown
2003-12-22 3:00 ` Damion de Soto [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-107208749426446@msgid-missing \
--to=damion@snapgear.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.