From: Ed Wildgoose <lists@wildgooses.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Strategy for about 200 part-time users
Date: Tue, 18 May 2004 20:17:07 +0000 [thread overview]
Message-ID: <40AA6F43.7040707@wildgooses.com> (raw)
In-Reply-To: <20040518133713.GA6467@ahau.localdomain>
Jan Wilson wrote:
>* Ed Wildgoose <lists@wildgooses.com> [040518 08:57]:
>
>
>>What is your goal? Why isn't 2 buckets, one for P2P and the everything
>>else bucket (with an SFQ on each) enough for what you want (ie what's
>>your target?) What's wrong with the current setup (apart from wanting
>>to switch to MAC access)?
>>
>>
>
>Well, as I see it (which could easily be wrong), the problem is with
>setting up over 200 buckets, even though only 60 to 90, maybe, are
>active at any one time. With the limited bandwidth we have available
>(it is very expensive here), it makes rather tiny buckets.
>
>
Yeah, but the buckets have a guaranteed bandwidth, and also get to share
the remaining bandwidth between them. So if you have 600 buckets, and
only two are active, then those two buckets should get half the
bandwidth each (if you set it up that way). Perhaps that's really
obvious, but just wanted to be sure
Also, I think you can do your accounting with firewall rules as well as
tc rules. It may be more flexible to seperate accounting from
throttling - perhaps it will give you more options to set this up.
For example, you could setup the rules with the class of traffic at the
top and the users underneath, eg top level is "P2P", "bulk",
"interactive", and under each is a user class (or SFQ, etc). Now you
could limit the P2P to be only 1/3 of total bandwidth, which is then
fought over by the users (each will get a fraction depending on how many
others are using it, not how many classes you have). Perhaps for the
other classes even SFQ will be enough?
The howto mentions some examples of using hashing which may allow you a
concise way to setup these rules by IP for example (even though you
won't be accounting that way).
You then need to look to iptables to see if you can do some standard
rules to account for your traffic. Perhaps someone here could suggest a
neat way?
Good luck. Would be interested to hear your final solution
Ed W
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2004-05-18 20:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-18 13:37 [LARTC] Strategy for about 200 part-time users Jan Wilson
2004-05-18 14:57 ` Ed Wildgoose
2004-05-18 15:42 ` Jan Wilson
2004-05-18 16:31 ` Andreas Klauer
2004-05-18 17:43 ` Jan Wilson
2004-05-18 20:17 ` Ed Wildgoose [this message]
2004-05-18 21:41 ` Jan Wilson
2004-05-18 22:35 ` Ed Wildgoose
2004-05-18 22:44 ` Jason Boxman
2004-05-19 0:39 ` Andreas Klauer
2004-05-19 11:05 ` 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=40AA6F43.7040707@wildgooses.com \
--to=lists@wildgooses.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.