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/
next prev parent 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.