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] Comments on my set-up please
Date: Sat, 03 May 2003 10:29:12 +0000	[thread overview]
Message-ID: <marc-lartc-105195816321597@msgid-missing> (raw)

I finally had some time to examine your setup.  And I have some remarks.
I deleted the unrelevant parts of your post.

> - Firewall/Router/Gateway: P200, 48MB RAM, RedHat 9 -- shares internet
> with all other machines through a 1.5Mbit/192Kbit cable connection
> (mine)

> First and foremost I want to ensure that the UT2003 server/players and
> Microsoft Gamvoice have guaranteed bandwidth regardless of what is
> happening elsewhere.
>
> Second, I want keep the neighbour's use of Kaazaa to flood my upstream
> and downstream bandwidth.
>
> Third, I would like to shape my traffic to give interactive traffic
> priority.
>

> ############## HTB DOWNSTREAM #################
>
> # create qdisc - eth0 is my internal nic
> tc qdisc add dev eth0 root handle 1: htb default 50
I have some remarks on how you created your classes.  I also changed some of 
the rate and ceil parameters of the class.  I should do it like this:
name      ceil        rate        prio 
1:1       100000kbit  100000kbit
 1:2      100000kbit   98500kbit    3  traffic from firewall to LAN
 1:3      1500kbit      1500kbit       traffic from internet to LAN
    1:10  1480kbit       725kbit    3  neighbour traffic
    1:20  1480kbit       725kbit    3  our traffic
    1:30    10kbit        40kbit    2  ut3k3
    1:40  1480kbit        10kbit    3  other traffic

Some explanation.  The sum of the rates should be equal to the parent rate. 
The rate is the guaranteed bandwidth.
By giving the classes a ceil of 1480, I make sure that ut2k3 always has 20kbit 
left to use instantly.  Ut2k3 can use 40kbit even if all other classes are 
sending all they can.
I also gave your neighbours a ceil of 1480 so they can use full bandwidth if 
there is no other traffic on the link.
I splitted the traffic in 2 classes so internet traffic and local traffic are 
seperated.


> tc qdisc add dev eth0 parent 1:10 handle 110: sfq perturb 10
> tc qdisc add dev eth0 parent 1:20 handle 120: sfq perturb 10
> tc qdisc add dev eth0 parent 1:40 handle 140: sfq perturb 10
> tc qdisc add dev eth0 parent 1:50 handle 150: sfq perturb 10

For the 1:30 class, you can add a small prio to get lower delays.

> # not sure how to separate my upstream from neighbour's upstream
You can do this if you mark the packets on eth1 when they enter your firewall 
with iptables.  Give each neighbour a different mark.  That mark can be sued 
on eth0 to classify the packets.

Stef

-- 

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

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

             reply	other threads:[~2003-05-03 10:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-03 10:29 Stef Coene [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-04-29 22:21 [LARTC] Comments on my set-up please ambitious_llama

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-105195816321597@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.