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 and Openvpn
Date: Wed, 06 Oct 2004 10:55:24 +0000	[thread overview]
Message-ID: <4163CF1C.9070704@metamorpher.de> (raw)
In-Reply-To: <Pine.LNX.4.44.0410061153510.2239-100000@george.eliot.priv.at>

Peter Huetmannsberger wrote:
> The idea was that all traffic going through the tunnel would have top 
> priority and the rest share what's left. Sounded simple enough. 

You could use a prio queue for that. Tunnel on band 0, rest on band 1. 
Downside is that there may be nothing left for the rest to share. :-)

> tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit burst 15k

Why make a 10mbit class when it's not used? I find it hard to tell what 
will happen when the rates don't add up properly.

> tc class add dev eth0 parent 1:1 classid 1:10 htb rate 700kbit ceil 1mbit 
> 	burst 15k prio 0

Since the parent has 10mbit which is never fully used, this class will 
most likely always borrow as much as it can. So although it says 700kbit 
it's really a 1mbit class.

> tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1kbit ceil 28800 
> 	burst 15k

This class does not seem to be used at all, why does it exist?

> tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 1mbit 
> 	burst 15k prio 1

Another 1mbit class. The parent has 10mbit, so there's no reason why it 
shouldn't be able to borrow another mbit, no matter what the actual 
priority of that class is. Am I wrong? :)

> Any idea where I could be wrong?

Guesswork:

The logic of your class structure is flawed.

How fast is your connection to the outside world? I guess it's 1mbit, 
because you set the ceil of your VPN/rest class to 1mbit? However, the 
parent class of those two is a 10mbit class, so both borrow one 1mbit 
from that (they don't share the same one single mbit). In that case, no 
proper shaping is done at all.

10mbit then would be your LAN?

Then how about this class setup:

1:1      10mbit (LAN interface)
|
\--- 1:2 09mbit (LAN only traffic)
\--- 1:3 01mbit (Outside world traffic)
      |
      \--- 1:31 700kbit (VPN)
      \--- 1:32 300kbit (Rest)

This is (about) the kind of setup I use at home.
Make sure your rates add up.

If you intend to give your (Rest) class 1kbit only, throw HTB away and 
use PRIO instead. If (Rest) doesn't need any bandwidth at all, you can 
as well let it starve completely by using prio. And that's much less 
complicated than HTB.

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

  reply	other threads:[~2004-10-06 10:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-06 10:01 [LARTC] HTB and Openvpn Peter Huetmannsberger
2004-10-06 10:55 ` Andreas Klauer [this message]
2004-10-06 11:09 ` Peter Huetmannsberger
2004-10-06 13:30 ` 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=4163CF1C.9070704@metamorpher.de \
    --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.