From: Ricardo Soria <ricardo_soria@yahoo.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] SEPARATING VOIP AND SURFING
Date: Tue, 16 Nov 2004 01:06:22 +0000 [thread overview]
Message-ID: <20041116010622.1814.qmail@web41510.mail.yahoo.com> (raw)
In-Reply-To: <20041109175203.11372.qmail@web41524.mail.yahoo.com>
--- Andy Furniss <andy.furniss@dsl.pipex.com>
escribió:
> Ricardo Soria wrote:
> > Dear list:
> >
> > I have a problem I cannot handle yet, and need to
> > solve it as soon as possible. Would be very
> greatful
> > with anybody who can help me.
> >
> > I have a 512/512 link to internet, that I want to
> > share between several computers. I have eth0,
> with a
> > public IP address, conected to Internet, and also,
> > eth1, with a private IP address, for network with
> the
> > surfing computers. I have a main class with the
> whole
> > 512kbit, then 2 child classes in this way (you can
> see
> > the complete script at the end):
> >
> > class 1: rate = ceil = 64kbit, prio 0, for VOIP
> > class 2: rate = ceil = 448kbit, for SURFING
> >
> > Class 2 is subdivided again in about 20 classes,
> for
> > 20 surfing computers, this way:
> >
> > class 3: rate = 18kbit, ceil = 448kbit, prio 1,
> SURF
> >
> > I have a classical problem (I think). As you can
> see,
> > first 64kbit are for VOIP, so, it is necesary the
> best
> > quality, and the minimal delays. 64Kbit is pretty
> > enough for 1 VOIP channel (it is supposed to
> really
> > use no more than 20kbit). And also, the 64kbit
> class
> > has the highest priority. Nevertheless, specially
> > when all 20 users are surfing, or some user are
> > browsing weight pages, or when 2 or more users are
> > downloading at the same time, I cannot get VOIP to
> > work properly, because quality becomes very poor.
> I
> > have made all kind of imaginable test, probes and
> > combinations, trying to test with different burst
> > values for classes, attaching sfq qdiscs to all
> leaf
> > classes, then only to surfing classes, then only
> to
> > VOIP classes, and even, gaming with R2Q/Quantums,
> that
> > would not be necessary, because 64Kbit is very
> more
> > than enough.
> >
> > So please, does anyone have any idea how to
> completely
> > separate VOIP and SURFING, making 2 independent
> > channels, without one service affect to other ??
> >
> > Very thanks in advance.
> >
> > If you are still able to read, after having read
> all
> > this stuff, here goes my script as is now...
> >
> > Best Regards to everybody.
> >
> > Ricardo.
> >
> > ========================
> >
> > #!/bin/bash
> >
> > tc qdisc add dev eth1 root handle 1: htb default
> 121
> > r2q 1
> > tc qdisc add dev eth0 root handle 1: htb default
> 20
> > r2q 5
> >
> > tc class add dev eth1 parent 1: classid 1:1 htb
> rate
> > 512kbit ceil 512kbit
> > tc class add dev eth0 parent 1: classid 1:1 htb
> rate
> > 512kbit ceil 512kbit
> >
> > tc class add dev eth1 parent 1:1 classid 1:10 htb
> rate
> > 64kbit ceil 64kbit prio 0
> > tc class add dev eth0 parent 1:1 classid 1:10 htb
> rate
> > 64kbit ceil 64kbit prio 0
> >
> > tc class add dev eth1 parent 1:1 classid 1:20 htb
> rate
> > 448kbit ceil 448kbit prio 1
> > tc class add dev eth0 parent 1:1 classid 1:20 htb
> rate
> > 448kbit ceil 448kbit prio 1
> >
> > # PER MACHINE OR IP CLASSES
> >
> > tc class add dev eth1 parent 1:20 classid 1:90 htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:91 htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:101
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:102
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:103
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:104
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:105
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:106
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:107
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:108
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:109
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:110
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:111
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:112
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:113
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:114
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:115
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:116
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:117
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:118
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:119
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:120
> htb
> > rate 18kbit ceil 448kbit prio 1
> > tc class add dev eth1 parent 1:20 classid 1:121
> htb
> > rate 18kbit ceil 448kbit prio 1
> >
> > # SFQ QDISCS PER LEAF CLASS
> >
> > # VOIP
> > tc qdisc add dev eth0 parent 1:10 handle 10: sfq
> > perturb 10
> > tc qdisc add dev eth0 parent 1:20 handle 20: sfq
> > perturb 10
> >
> > #SURFING
> > tc qdisc add dev eth1 parent 1:10 handle 10: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:90 handle 90: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:91 handle 91: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:101 handle 101: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:102 handle 102: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:103 handle 103: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:104 handle 104: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:105 handle 105: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:106 handle 106: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:107 handle 107: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:108 handle 108: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:109 handle 109: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:110 handle 110: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:111 handle 111: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:112 handle 112: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:113 handle 113: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:114 handle 114: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:115 handle 115: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:116 handle 116: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:117 handle 117: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:118 handle 118: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:119 handle 119: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:120 handle 120: sfq
> > perturb 10
> > tc qdisc add dev eth1 parent 1:121 handle 121: sfq
> > perturb 10
> >
> > # FILTERS
> >
> > # VOIP
> > tc filter add dev eth0 protocol ip parent 1:0 prio
> 0
> > u32 match ip src 216.118.226.244 flowid 1:10
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 0
> > u32 match ip dst 216.118.226.244 flowid 1:10
> >
> > # SURFING
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.2 flowid 1:90
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.3 flowid 1:91
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.101 flowid 1:101
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.102 flowid 1:102
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.103 flowid 1:103
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.104 flowid 1:104
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.105 flowid 1:105
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.106 flowid 1:106
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.107 flowid 1:107
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.108 flowid 1:108
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.109 flowid 1:109
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.110 flowid 1:110
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.111 flowid 1:111
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.112 flowid 1:112
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.113 flowid 1:113
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.114 flowid 1:114
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.115 flowid 1:115
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.116 flowid 1:116
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.117 flowid 1:117
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.118 flowid 1:118
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.119 flowid 1:119
> > tc filter add dev eth1 protocol ip parent 1:0 prio
> 1
> > u32 match ip dst 192.168.0.120 flowid 1:120
> >
> > # END
>
>
> I haven't read the script properly, but generally
> three points come to mind.
>
> You need to back off more from link speed - total
> ceils to about 80% and
> share that between interactive and bulk.
>
> SFQ default queue length is too long to be used as
> you want - use esfq
> or change the length to 16 in the source code (see
> www.docum.org FAQs).
>
> You should really only send bulk to SFQ - It will
> behave better than a
> fifo if you mix traffic - but at the low rates you
> set it will still
> cause too much delay for interactive (small
> UDP/TCP).
>
> Andy.
>
>
>
Dear Andy:
Very thanks for your answer. However, I need a little
bit more extended explanation.
First, you say that I should "back off more from link
speed - total ceils to about 80% and share that
between interactive and bulk". So, do you mean that
if I have a total 512Kbit link, and 2 child classes, I
should not divide the whole 512kbit between the 2
classes, but, I should only divide 410kbit between
them, and share the remaining 102kbit between them??
Or do you mean I should only consider 410kbit as the
whole link capacity??
Second, you say that I should not use SFQ as a
sub-qdisc, because of the lenght of the queue, being
it ESFQ (new for me) a better choice. But later, you
say I should use SFQ for bulk traffic (I think you
refer surfing as "bulk", and voip as "interactive").
So, should I use SFQ for bulk classes and ESFQ for
interactive classes ?? Or, should I use ESFQ for all
leaf classes?? Or, should I use ESFQ for bulk classes
and default (pfifo, I think) for interactive classes??
Very thanks for your help.
Best Regards.
Ricardo.
_________________________________________________________
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos en http://noticias.espanol.yahoo.com
_______________________________________________
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-11-16 1:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-09 17:52 [LARTC] SEPARATING VOIP AND SURFING Ricardo Soria
2004-11-15 12:42 ` Andy Furniss
2004-11-16 1:06 ` Ricardo Soria [this message]
2004-11-16 1:33 ` Jason Boxman
2004-11-16 14:53 ` Andy Furniss
2004-11-16 17:08 ` Jason Boxman
2004-11-17 1:15 ` Andy Furniss
2004-11-17 22:36 ` Ricardo Soria
2004-11-18 0:44 ` Andy Furniss
2004-11-18 1:08 ` Rick Marshall
2004-11-23 15:57 ` Ricardo Soria
2004-11-24 19:08 ` Ricardo Soria
2004-11-24 22:19 ` Ricardo Soria
2004-11-24 22:42 ` Rick Marshall
2004-11-25 10:48 ` Andy Furniss
2004-11-25 15:55 ` Andy Furniss
2004-11-28 23:50 ` Ricardo Soria
2004-11-29 21:53 ` Andy Furniss
2004-11-30 2:07 ` Ricardo Soria
2004-11-30 2:39 ` Andy Furniss
2004-11-30 12:23 ` Andy Furniss
2004-12-01 15:16 ` Ricardo Soria
2004-12-01 21:57 ` Andy Furniss
2004-12-06 22:54 ` Ricardo Soria
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=20041116010622.1814.qmail@web41510.mail.yahoo.com \
--to=ricardo_soria@yahoo.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.