* Re: [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design
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
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Andy Furniss @ 2005-11-11 14:22 UTC (permalink / raw)
To: lartc
Mark Lidstone wrote:
> Hi all,
>
> I've done a search through the archives but I can't find a
> cause/solution to this.
>
> I'm running a FC4 box with the stock 2.6.12 kernel and a FC2 box with a
> stock 2.6.9 kernel. I'm obviously using
> iproute2 and the patched tc.
>
> When I clear down the qdiscs with "tc qdisc del dev <DEV> root" I get
> the following in response to "tc qdisc":
>
> qdisc pfifo_fast 0: dev eth0 [Unknown qdisc, optlen ]
> qdisc pfifo_fast 0: dev eth1 [Unknown qdisc, optlen ]
>
> Unfortunately I cannot add pfifo_fast as a queue type (I was hoping to
> use one - see below). Have I missed something?
pfifo_fast is what you get as default on interfaces - it's just like
prio but not meant to be used by you - I suppose you could nest prios,
but in this case I think what you need is just pfifo or bfifo.
>
> Secondly, I was wondering if anyone could look over what I am trying to
> do and point out any stupid mistakes I've made. I am trying to get the
> following setup working:
>
> root
> |
> |
> PRIO
> / | \
> ______/ | \______
> | | |
> 0 | 2
> pfifo_fast 1 sfq
> HTB__________
> / | \ \
> ______/ | \______ \______
> | | | |
> sfq sfq sfq sfq
>
> Basically, we have 4 companies that will be sharing bandwidth on a
> connection (the four sfq's at the bottom) and some video conferencing
> equipment that needs priority over everything (the pfifo_fast). Have I
> misunderstood anything vital here?
You would be better off having htb as root so you can throttle traffic
to below link speed. You can htb's prio parameter to do much the same.
Sfq is nice but the perturb causes packet reordering I would think about
trying to seperate each customers traffic into bulk and interactive
aswell and just use sfq on bulk.
Andy.
>
> Many thanks,
>
> Mark Lidstone
> IT and Network Support Administrator
>
> BMT SeaTech Ltd
> Grove House, Meridians Cross, 7 Ocean Way Ocean Village, Southampton.
> SO14 3TJ. UK
> Tel: +44 (0)23 8063 5122
> Fax: +44 (0)23 8063 5144
>
> E-Mail: mailto:mark.lidstone@bmtseatech.co.uk
> Website: www.bmtseatech.co.uk
> ====================================
> =
> Confidentiality Notice and Disclaimer:
> The contents of this e-mail and any attachments are intended only for
> the use of the e-mail addressee(s) shown. If you are not that person, or
> one of those persons, you are not allowed to take any action based upon
> it or to copy it, forward, distribute or disclose the contents of it and
> you should please delete it from your system. BMT SeaTech Limited does
> not accept liability for any errors or omissions in the context of this
> e-mail or its attachments which arise as a result of Internet
> transmission, nor accept liability for statements which are those of the
> author and not clearly made on behalf of BMT SeaTech Limited.
> ====================================
> =
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design
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
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Mark Lidstone @ 2005-11-11 16:29 UTC (permalink / raw)
To: lartc
Hi Andy,
Many thanks for the reply.
Is there a reason why the user is not supposed to use pfifo_fast? I
don't think I need a full-on PRIO (surely pfifo_fast is more efficient
if it is classless?). Sorry for asking, but I didn't come across this
limitation in the documentation.
Following your suggestions, I've come up with the following:
#!/bin/sh
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 4096kbit
$SC parent 1:1 classid 1:2 htb prio 0 rate 768kbit #Video
Conferencing
$SC parent 1:1 classid 1:3 htb prio 1 rate 1545kbit #Company 1
$SC parent 1:1 classid 1:4 htb prio 1 rate 832kbit #Company 2
$SC parent 1:1 classid 1:5 htb prio 1 rate 713kbit #Company 3
$SC parent 1:1 classid 1:6 htb prio 1 rate 238kbit #Company 4
$SQ parent 1:2 handle 5:0 prio #Video Conferencing
$SQ parent 1:3 handle 6:0 prio #Company 1
$SQ parent 1:4 handle 7:0 prio #Company 2
$SQ parent 1:5 handle 8:0 prio #Company 3
$SQ parent 1:6 handle 9:0 prio #Company 4
$SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.4/32
flowid 5:0
$SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.5/32
flowid 6:0
$SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.6/32
flowid 7:0
$SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.7/32
flowid 8:0
$SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.8/32
flowid 9:0
(I've a horrible feeling there's something obviously and fundamentally
wrong with this)
What happens with any traffic not from these IPs?
Many thanks,
Mark Lidstone
IT and Network Support Administrator
BMT SeaTech Ltd
Grove House, Meridians Cross, 7 Ocean Way
Ocean Village, Southampton. SO14 3TJ. UK
Tel: +44 (0)23 8063 5122
Fax: +44 (0)23 8063 5144
E-Mail: mailto:mark.lidstone@bmtseatech.co.uk
Website: www.bmtseatech.co.uk
====================================
=
Confidentiality Notice and Disclaimer:
The contents of this e-mail and any attachments are intended only for
the
use of the e-mail addressee(s) shown. If you are not that person, or one
of those persons, you are not allowed to take any action based upon it
or
to copy it, forward, distribute or disclose the contents of it and you
should please delete it from your system. BMT SeaTech Limited does not
accept liability for any errors or omissions in the context of this
e-mail
or its attachments which arise as a result of Internet transmission, nor
accept liability for statements which are those of the author and not
clearly made on behalf of BMT SeaTech Limited.
====================================
=
-----Original Message-----
From: Andy Furniss [mailto:andy.furniss@dsl.pipex.com]
Sent: 11 November 2005 14:22
To: Mark Lidstone
Cc: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic
design advice
Mark Lidstone wrote:
> Hi all,
>
> I've done a search through the archives but I can't find a
> cause/solution to this.
>
> I'm running a FC4 box with the stock 2.6.12 kernel and a FC2 box with
> a stock 2.6.9 kernel. I'm obviously using
> iproute2 and the patched tc.
>
> When I clear down the qdiscs with "tc qdisc del dev <DEV> root" I get
> the following in response to "tc qdisc":
>
> qdisc pfifo_fast 0: dev eth0 [Unknown qdisc, optlen ]
> qdisc pfifo_fast 0: dev eth1 [Unknown qdisc, optlen ]
>
> Unfortunately I cannot add pfifo_fast as a queue type (I was hoping to
> use one - see below). Have I missed something?
pfifo_fast is what you get as default on interfaces - it's just like
prio but not meant to be used by you - I suppose you could nest prios,
but in this case I think what you need is just pfifo or bfifo.
>
> Secondly, I was wondering if anyone could look over what I am trying
> to do and point out any stupid mistakes I've made. I am trying to get
> the following setup working:
>
> root
> |
> |
> PRIO
> / | \
> ______/ | \______
> | | |
> 0 | 2
> pfifo_fast 1 sfq
> HTB__________
> / | \ \
> ______/ | \______ \______
> | | | |
> sfq sfq sfq sfq
>
> Basically, we have 4 companies that will be sharing bandwidth on a
> connection (the four sfq's at the bottom) and some video conferencing
> equipment that needs priority over everything (the pfifo_fast). Have
> I misunderstood anything vital here?
You would be better off having htb as root so you can throttle traffic
to below link speed. You can htb's prio parameter to do much the same.
Sfq is nice but the perturb causes packet reordering I would think about
trying to seperate each customers traffic into bulk and interactive
aswell and just use sfq on bulk.
Andy.
>
> Many thanks,
>
> Mark Lidstone
> IT and Network Support Administrator
>
> BMT SeaTech Ltd
> Grove House, Meridians Cross, 7 Ocean Way Ocean Village, Southampton.
> SO14 3TJ. UK
> Tel: +44 (0)23 8063 5122
> Fax: +44 (0)23 8063 5144
>
> E-Mail: mailto:mark.lidstone@bmtseatech.co.uk
> Website: www.bmtseatech.co.uk
> ===================================
> =
> =
> Confidentiality Notice and Disclaimer:
> The contents of this e-mail and any attachments are intended only for
> the use of the e-mail addressee(s) shown. If you are not that person,
> or one of those persons, you are not allowed to take any action based
> upon it or to copy it, forward, distribute or disclose the contents of
> it and you should please delete it from your system. BMT SeaTech
> Limited does not accept liability for any errors or omissions in the
> context of this e-mail or its attachments which arise as a result of
> Internet transmission, nor accept liability for statements which are
> those of the author and not clearly made on behalf of BMT SeaTech
Limited.
> ===================================
> =
> =
>
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design
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
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Andy Furniss @ 2005-11-14 22:36 UTC (permalink / raw)
To: lartc
Mark Lidstone wrote:
> Hi Andy,
>
> Many thanks for the reply.
>
> Is there a reason why the user is not supposed to use pfifo_fast? I
> don't think I need a full-on PRIO (surely pfifo_fast is more efficient
> if it is classless?). Sorry for asking, but I didn't come across this
> limitation in the documentation.
Not sure really.
>
> Following your suggestions, I've come up with the following:
>
> #!/bin/sh
> 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 4096kbit
> $SC parent 1:1 classid 1:2 htb prio 0 rate 768kbit #Video
> Conferencing
> $SC parent 1:1 classid 1:3 htb prio 1 rate 1545kbit #Company 1
> $SC parent 1:1 classid 1:4 htb prio 1 rate 832kbit #Company 2
> $SC parent 1:1 classid 1:5 htb prio 1 rate 713kbit #Company 3
> $SC parent 1:1 classid 1:6 htb prio 1 rate 238kbit #Company 4
> $SQ parent 1:2 handle 5:0 prio #Video Conferencing
> $SQ parent 1:3 handle 6:0 prio #Company 1
> $SQ parent 1:4 handle 7:0 prio #Company 2
> $SQ parent 1:5 handle 8:0 prio #Company 3
> $SQ parent 1:6 handle 9:0 prio #Company 4
>
> $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.4/32
> flowid 5:0
> $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.5/32
> flowid 6:0
> $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.6/32
> flowid 7:0
> $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.7/32
> flowid 8:0
> $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.8/32
> flowid 9:0
>
> (I've a horrible feeling there's something obviously and fundamentally
> wrong with this)
>
> What happens with any traffic not from these IPs?
You can use a catch all filter after the others ... u32 match u32 0 0 ..
Unlike htb prio 1 is the top prio for filters.
Without knowing what your setup is it's hard to say what's the best way
in detail eg. where and what bandwidth are the bottleneck links and
which end of them you are shaping.
Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design
2005-11-11 9:50 [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design Mark Lidstone
` (2 preceding siblings ...)
2005-11-14 22:36 ` Andy Furniss
@ 2005-11-15 10:31 ` Mark Lidstone
2005-11-15 18:59 ` Stephen Hemminger
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Mark Lidstone @ 2005-11-15 10:31 UTC (permalink / raw)
To: lartc
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.
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.
Many thanks,
Mark Lidstone
IT and Network Support Administrator
BMT SeaTech Ltd
Grove House, Meridians Cross, 7 Ocean Way
Ocean Village, Southampton. SO14 3TJ. UK
Tel: +44 (0)23 8063 5122
Fax: +44 (0)23 8063 5144
E-Mail: mailto:mark.lidstone@bmtseatech.co.uk
Website: www.bmtseatech.co.uk
====================================
=
Confidentiality Notice and Disclaimer:
The contents of this e-mail and any attachments are intended only for
the
use of the e-mail addressee(s) shown. If you are not that person, or one
of those persons, you are not allowed to take any action based upon it
or
to copy it, forward, distribute or disclose the contents of it and you
should please delete it from your system. BMT SeaTech Limited does not
accept liability for any errors or omissions in the context of this
e-mail
or its attachments which arise as a result of Internet transmission, nor
accept liability for statements which are those of the author and not
clearly made on behalf of BMT SeaTech Limited.
====================================
=
-----Original Message-----
From: Andy Furniss [mailto:andy.furniss@dsl.pipex.com]
Sent: 14 November 2005 22:36
To: Mark Lidstone
Cc: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic
design advice
Mark Lidstone wrote:
> Hi Andy,
>
> Many thanks for the reply.
>
> Is there a reason why the user is not supposed to use pfifo_fast? I
> don't think I need a full-on PRIO (surely pfifo_fast is more efficient
> if it is classless?). Sorry for asking, but I didn't come across this
> limitation in the documentation.
Not sure really.
>
> Following your suggestions, I've come up with the following:
>
> #!/bin/sh
> 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 4096kbit
> $SC parent 1:1 classid 1:2 htb prio 0 rate 768kbit #Video
> Conferencing
> $SC parent 1:1 classid 1:3 htb prio 1 rate 1545kbit #Company 1
> $SC parent 1:1 classid 1:4 htb prio 1 rate 832kbit #Company 2
> $SC parent 1:1 classid 1:5 htb prio 1 rate 713kbit #Company 3
> $SC parent 1:1 classid 1:6 htb prio 1 rate 238kbit #Company 4
> $SQ parent 1:2 handle 5:0 prio #Video Conferencing
> $SQ parent 1:3 handle 6:0 prio #Company 1
> $SQ parent 1:4 handle 7:0 prio #Company 2
> $SQ parent 1:5 handle 8:0 prio #Company 3
> $SQ parent 1:6 handle 9:0 prio #Company 4
>
> $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.4/32
flowid
> 5:0
> $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.5/32
flowid
> 6:0
> $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.6/32
flowid
> 7:0
> $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.7/32
flowid
> 8:0
> $SF parent 1:0 protocol ip prio 0 u32 match ip src 1.2.3.8/32
flowid
> 9:0
>
> (I've a horrible feeling there's something obviously and fundamentally
> wrong with this)
>
> What happens with any traffic not from these IPs?
You can use a catch all filter after the others ... u32 match u32 0 0 ..
Unlike htb prio 1 is the top prio for filters.
Without knowing what your setup is it's hard to say what's the best way
in detail eg. where and what bandwidth are the bottleneck links and
which end of them you are shaping.
Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design
2005-11-11 9:50 [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design Mark Lidstone
` (3 preceding siblings ...)
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
6 siblings, 0 replies; 8+ messages in thread
From: Stephen Hemminger @ 2005-11-15 18:59 UTC (permalink / raw)
To: lartc
On Fri, 11 Nov 2005 09:50:03 -0000
"Mark Lidstone" <mark.lidstone@bmtseatech.co.uk> wrote:
> Hi all,
>
> I've done a search through the archives but I can't find a
> cause/solution to this.
>
> I'm running a FC4 box with the stock 2.6.12 kernel and a FC2 box with a
> stock 2.6.9 kernel. I'm obviously using
> iproute2 and the patched tc.
>
> When I clear down the qdiscs with "tc qdisc del dev <DEV> root" I get
> the following in response to "tc qdisc":
>
> qdisc pfifo_fast 0: dev eth0 [Unknown qdisc, optlen ]
> qdisc pfifo_fast 0: dev eth1 [Unknown qdisc, optlen ]
>
Current versions of iproute2 know about pfifo_fast.
> Unfortunately I cannot add pfifo_fast as a queue type (I was hoping to
> use one - see below). Have I missed something?
pfifo_fast is only suitable as a baseline with no other qdisc's
involved. It can only sit directly on the device (at the bottom).
It shouldn't be that much faster than doing it with prio and fifo for
most things. The additional overhead of prio and fifo are mostly because
they are in separate modules and that adds some memory locality penalty.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design
2005-11-11 9:50 [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design Mark Lidstone
` (4 preceding siblings ...)
2005-11-15 18:59 ` Stephen Hemminger
@ 2005-11-16 13:12 ` Mark Lidstone
2005-11-16 14:55 ` Andy Furniss
6 siblings, 0 replies; 8+ messages in thread
From: Mark Lidstone @ 2005-11-16 13:12 UTC (permalink / raw)
To: lartc
Hi Stephen,
Many thanks for that information. I thought my iproute2 was up to date,
but I must have made a mistake somewhere. I'll go and grab it again.
I can see your point about prio or (p/b)fifo not being much slower, but
this will be running on an oldish Celeron box so I wanted to make things
as memory efficient as possible.
Again, many thanks for clearing that up.
Mark Lidstone
IT and Network Support Administrator
BMT SeaTech Ltd
Grove House, Meridians Cross, 7 Ocean Way
Ocean Village, Southampton. SO14 3TJ. UK
Tel: +44 (0)23 8063 5122
Fax: +44 (0)23 8063 5144
E-Mail: mailto:mark.lidstone@bmtseatech.co.uk
Website: www.bmtseatech.co.uk
====================================
=
Confidentiality Notice and Disclaimer:
The contents of this e-mail and any attachments are intended only for
the
use of the e-mail addressee(s) shown. If you are not that person, or one
of those persons, you are not allowed to take any action based upon it
or
to copy it, forward, distribute or disclose the contents of it and you
should please delete it from your system. BMT SeaTech Limited does not
accept liability for any errors or omissions in the context of this
e-mail
or its attachments which arise as a result of Internet transmission, nor
accept liability for statements which are those of the author and not
clearly made on behalf of BMT SeaTech Limited.
====================================
=
-----Original Message-----
From: Stephen Hemminger [mailto:shemminger@osdl.org]
Sent: 15 November 2005 19:00
To: Mark Lidstone
Cc: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic
design advice
On Fri, 11 Nov 2005 09:50:03 -0000
"Mark Lidstone" <mark.lidstone@bmtseatech.co.uk> wrote:
> Hi all,
>
> I've done a search through the archives but I can't find a
> cause/solution to this.
>
> I'm running a FC4 box with the stock 2.6.12 kernel and a FC2 box with
> a stock 2.6.9 kernel. I'm obviously using
> iproute2 and the patched tc.
>
> When I clear down the qdiscs with "tc qdisc del dev <DEV> root" I get
> the following in response to "tc qdisc":
>
> qdisc pfifo_fast 0: dev eth0 [Unknown qdisc, optlen ]
> qdisc pfifo_fast 0: dev eth1 [Unknown qdisc, optlen ]
>
Current versions of iproute2 know about pfifo_fast.
> Unfortunately I cannot add pfifo_fast as a queue type (I was hoping to
> use one - see below). Have I missed something?
pfifo_fast is only suitable as a baseline with no other qdisc's
involved. It can only sit directly on the device (at the bottom).
It shouldn't be that much faster than doing it with prio and fifo for
most things. The additional overhead of prio and fifo are mostly because
they are in separate modules and that adds some memory locality penalty.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design
2005-11-11 9:50 [LARTC] Pfifo_fast "Unknown qdisc" and asking for basic design Mark Lidstone
` (5 preceding siblings ...)
2005-11-16 13:12 ` Mark Lidstone
@ 2005-11-16 14:55 ` Andy Furniss
6 siblings, 0 replies; 8+ messages in thread
From: Andy Furniss @ 2005-11-16 14:55 UTC (permalink / raw)
To: lartc
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
^ permalink raw reply [flat|nested] 8+ messages in thread