From: Andy Furniss <andy.furniss@dsl.pipex.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design
Date: Wed, 16 Nov 2005 14:55:35 +0000 [thread overview]
Message-ID: <437B4867.4030700@dsl.pipex.com> (raw)
In-Reply-To: <BF782D07436CAE4B931BFA5B2C68FF4F0F8B9E@bmts1.ad.bmtseatech.co.uk>
Mark Lidstone wrote:
> Hi Andy,
>
> The situation is this: there are a total of four companies represented
> in our building. We've all been looking at upgrading our Internet
> connections from ADSL, and as we're all owned by the same parent company
> it made sense to buy our bandwidth "in bulk". As such we're hoping to
> get a 4Mb/4Mb pipe of some description.
>
> One of the drivers for going ahead with this is the fact that one of the
> companies wants to start using some reasonably funky video conferencing
> equipment.
>
> The four companies are not paying the same amount each for the
> connection. Each company has agreed to pay an amount that represents
> their expected usage of the system. To keep things fair, we would like
> to shape the traffic on the link to reflect the amounts people are
> paying. Also, the video conferencing equipment (as it will be available
> to all the companies in the building) will need a guaranteed chunk of
> bandwidth itself.
>
> We've looked at getting our ISP to provide the traffic shaping, but they
> want to charge a large setup fee and quite a bit of money per quarter to
> 'maintain' it (to leave the settings alone, in other words). I'm
> looking at using a spare box we have here as a means of shaping our
> outgoing traffic as an alternative. The idea is that downstream traffic
> will still be better off than with a 20:1 contended ADSL.
>
> The traffic will be split by IP, so the latest incarnation of the rules
> I have are:
>
> SQ="tc qdisc add dev eth0"
> SC="tc class add dev eth0"
> SF="tc filter add dev eth0"
>
> tc qdisc del dev eth0 root
> $SQ root handle 1:0 htb
> $SC parent 1:0 classid 1:1 htb rate 4mbit
> $SC parent 1:1 classid 1:2 htb rate <rate>kbit ceil 4mbit
> $SC parent 1:1 classid 1:3 htb rate <rate>kbit ceil 4mbit
> $SC parent 1:1 classid 1:4 htb rate <rate>kbit ceil 4mbit
> $SC parent 1:1 classid 1:5 htb rate <rate>kbit ceil 4mbit
> $SC parent 1:1 classid 1:6 htb rate <rate>kbit ceil 4mbit
> $SQ parent 1:2 handle 120: pfifo limit 50
> $SQ parent 1:3 handle 130: pfifo limit 50
> $SQ parent 1:4 handle 140: pfifo limit 50
> $SQ parent 1:5 handle 150: pfifo limit 50
> $SQ parent 1:6 handle 160: pfifo limit 50
>
> $SF parent 1:0 protocol ip prio 1 u32 match ip src 1.1.1.5/32 flowid 1:6
> $SF parent 1:0 protocol ip prio 2 u32 match ip src 1.1.1.1/32 flowid 1:2
> $SF parent 1:0 protocol ip prio 3 u32 match ip src 1.1.1.2/32 flowid 1:3
> $SF parent 1:0 protocol ip prio 4 u32 match ip src 1.1.1.3/32 flowid 1:4
> $SF parent 1:0 protocol ip prio 5 u32 match ip src 1.1.1.4/32 flowid 1:5
>
> It's just a very simple 5-child HTB with pfifo queues.
If you give the htb video class prio 0 and the rest 1 then this would be
OK. There are tweaks that you can do if you want the latency even lower
or you could use hfsc - I don't know what jitter is acceptable for you,
as it is I guess 25ms @ 4mbit link speed.
You can't use 4mbit as a ceil for a 4mbit link as this figure will
include overheads that htb doesn't see. I would prefer bfifo to pfifo
and make sure the video class has some spare rate and the rates add up.
>
> I might split things down more later, but this should get things going.
> It's just a pity that the ISP want to charge stupid amounts of money for
> the shaping.
If it's Xdsl in the UK I think they have to pay BT - maybe not with 1:1
products though.
You can still shape or police ingress traffic - the results can't be
guarenteed but you can do alot better than doing nothing. You do need to
sacrifice some bandwidth, depending on your traffic type/link speed and
what latency/jitter you need about 10-20% - with 4mbit the results will
be better than with lower speeds.
Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
prev parent reply other threads:[~2005-11-16 14:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-11 9:50 [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design Mark Lidstone
2005-11-11 14:22 ` Andy Furniss
2005-11-11 16:29 ` Mark Lidstone
2005-11-14 22:36 ` Andy Furniss
2005-11-15 10:31 ` Mark Lidstone
2005-11-15 18:59 ` Stephen Hemminger
2005-11-16 13:12 ` Mark Lidstone
2005-11-16 14:55 ` 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=437B4867.4030700@dsl.pipex.com \
--to=andy.furniss@dsl.pipex.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox