From: Kenneth Kalmer <kenneth.kalmer@gmail.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] wrr vs. htb
Date: Wed, 27 Jul 2005 10:01:06 +0000 [thread overview]
Message-ID: <fad9d484050727030145f87c1b@mail.gmail.com> (raw)
In-Reply-To: <fad9d48405072603541bc984b7@mail.gmail.com>
On 7/26/05, Peter Surda <surda@shurdix.com> wrote:
> On Tue, 26 Jul 2005 12:54:17 +0200 Kenneth Kalmer <kenneth.kalmer@gmail.com>
> wrote:
>
> >Guys
> hi
>
> >I don't know how healthy this is, and I don't have a clue on how to
> >improve the performance or lessen the load on the box. I've also been
> >contemplating moving the setup to a WRR-based solution, but I'm not
> >too sure if WRR can equally share local and gateway traffic as
> >different 'flows'.
> I don't understand this "2 kinds of traffic" concept. Where is the server? In
> the internet or local? If local, why the need to shape it at all? I can
> acknowledge though that under certain circumstances when you have several
> parallel WRR qdiscs, it leads to freezes. Perhaps if you explain in more detail
> what the network looks like I can give your more precise answers.
It's one server, fulfilling two functions, gateway en network service delivery
The two flows are as follows:
1. Is internet traffic through this server, acting as the router/firewall.
2. Is the network traffic originating from the (same) server to the network.
The network traffic (2) is mail, audio chat, webcam and a little
website with useful stuff. This is only available to users inside the
network, so no effects on the internet link.
>
> >If possible, just share your thoughts on the best way to handle this
> >scenario with the 'dual' shaping, different speeds for traffic
> >originating from the network server and internet traffic flowing
> >through the server. The main emphasis is on equality, everyone on the
> >network needs to be happy.
> WRR is perfect when you need equality. [advertisement]Check out shurdix cough
> cough[/advertisement].
I had this idea in the shower this morning, comments please:
:0 HTB
/ \
(HTB) 1:0 2:0 (HTB)
| |
WRR 1:1 1:2 WRR
OK, the parent flow is the network link, so it's set to 100mbps rate &
ceil. The first HTB class (1:0) is shaped to the speed of the ADSL
link, and attached to it is a WRR qdisc for equality on that link. The
second HTB class (2:0) is shaped to (network - ADSL) and also has a
WRR qdisc attached for equality on the network.
I don't know if this is possible, or even feasible, but on paper it makes sense.
>
> >Kind regards
> >Kenneth Kalmer
> Yours sincerely,
> Peter
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
--
Kenneth Kalmer
kenneth.kalmer@gmail.com
Folding@home stats
http://vspx27.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next prev parent reply other threads:[~2005-07-27 10:01 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 [this message]
2005-07-27 13:47 ` Kenneth Kalmer
2005-07-27 22:23 ` Andy Furniss
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=fad9d484050727030145f87c1b@mail.gmail.com \
--to=kenneth.kalmer@gmail.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.