Linux Advanced Routing and Traffic Control list
 help / color / mirror / Atom feed
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

      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