All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ed Wildgoose <lists@wildgooses.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] RE: http bandwidth control
Date: Thu, 24 Jun 2004 11:07:27 +0000	[thread overview]
Message-ID: <40DAB5EF.5070608@wildgooses.com> (raw)
In-Reply-To: <1088048331.3736.18.camel@localhost.localdomain>


>The major issue i have is giving incoming priority on VPN clients and
>slowing down incoming email traffic (huge).
>  
>
...

>I'm trying the wondershaper as a quick solution also but don't know how
>"see if it's working or not"... 
>

I would recommend this script as a better starting point
http://digriz.org.uk/jdg-qos-script/

Andy has some other ideas, that perhaps he will post?  However, in your 
case you want to look at the incoming part.  At the moment there is an 
HTB qdisc with an RED queue on it.  I found good results by copying that 
chunk of code and making a 1:22 queue, changing the iptables stuff to 
filter to that one by default and the original queue only for high 
priority incoming (perhaps you could even go further and setup lots of 
incoming for different priorities). 

You then just tweak the ipfilter stuff below to apply appropriate fwmark 
options and then things will end up in the appropriate buckets and be 
rate limited.

You can use the option "pollbuckets" on this script to see whether it's 
working or not.

The key point is that it's hard to control incoming.  All you can really 
do is drop packets.  However, the *idea* of RED is to proactively drop a 
few to try and slow rates down before queing starts.  It is debatable 
whether it works and some people think it may work better to avoid the 
RED altogether...

Of course you can also only queue on an outgoing interface, so you 
either need to have a bridge/router setup so that stuff for your local 
net is effectively "going out" on the local net card.  Or else you use 
the IMQ device to act as a kind of device in front of your normal 
incoming card so that you now have an outbound interface on that (which 
is effectively inbound to your normal internet facing card) - does that 
make sense?  IMQ is like sticking another device in front of your 
existing device?  Anyway, it does what you want.

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

  reply	other threads:[~2004-06-24 11:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-24  3:38 [LARTC] RE: http bandwidth control Guillermo Gomez
2004-06-24 11:07 ` Ed Wildgoose [this message]
2004-06-24 15:58 ` Guillermo Gomez
2004-06-24 20:40 ` Ed Wildgoose
2004-06-25  0:21 ` Guillermo Gomez

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=40DAB5EF.5070608@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.