From: Andy Furniss <andyqos@ukfsn.org>
To: Andrew Beverley <andy@andybev.com>
Cc: netfilter@vger.kernel.org
Subject: Re: PortalShaper - details of scripts for a captive portal and traffic shaper
Date: Fri, 25 Nov 2011 12:58:48 +0000 [thread overview]
Message-ID: <4ECF9108.4030506@ukfsn.org> (raw)
In-Reply-To: <1321999757.2382.2523.camel@andybev-desktop>
Andrew Beverley wrote:
> Hi all,
>
> I'm posting this for people's interest, in case it is of use to anybody.
>
> I have created a set of scripts (called PortalShaper) to do the
> following:
> * Traffic shape the internet connection to optimise its speed
Just looking at this bit.
Generally, I think doing Qos on low bandwidth lines is in need of
tweaking on a per case basis, depending on requirements and the usage
patterns of the users.
I've only ever played with my home dsl and go for game latency as top
prio, with any bulk traffic of whatever nature easily classified.
So the points below really apply just to my personal experience - for
other use the script looks fine and is as good as any. None are going to
be perfect without tweaking for individual cases and getting a lot of
users sharing low bandwidth dsl is never going to be nice.
Random observations.
I've never used squid, but it looks like it is exempt from shaping.
You could tweak things so you don't have to back off more than a few
kbit/s on upstream and it wouldn't fail if there were lots of small
packets. I can't say from personal use because I do it with patched TC,
but it is possible to specify atm and an overhead with htb and tc will
use the atm size of the packets.
The reason I don't use it is that I shape for pppoa vc mux on an eth
interface and tc on eth sees packets as iplen + 14 so I would need a
negative overhead. For ppp tc sees ip length. It's tricky for a general
script, of course, because you need to know exactly the overhead to use
which is different for different ppps and shaping interfaces.
On bulk btb classes I found it best for latency to set burst and cburst
to 10 - effectively off (can't remember why I didn't use 1 - I know 0
didn't work).
To get the best possible latency with htb it's best to allocate way more
bandwidth than the class needs and set big bursts, this is not so good
if your classification fails though.
prev parent reply other threads:[~2011-11-25 12:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-22 22:09 PortalShaper - details of scripts for a captive portal and traffic shaper Andrew Beverley
2011-11-25 12:58 ` Andy Furniss [this message]
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=4ECF9108.4030506@ukfsn.org \
--to=andyqos@ukfsn.org \
--cc=andy@andybev.com \
--cc=netfilter@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).