All of lore.kernel.org
 help / color / mirror / Atom feed
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/

  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.