Hi Alberto,
Being a QOS newbie, your example was invaluable! I'm testing your
example, and so far so good.
Once I have something I'm happy with, I'll post it on my Asterisk
website:
http://www.wwworks-inc.com/asterisk
Nice work Alberto, and thanks.
-wade
> On Tue, Jun 10, 2003 at 09:58:14PM +0200, Emanuele Pucciarelli wrote:
> > Il mar, 2003-06-10 alle 20:07, Stephen Davies ha scritto:
> >
> > > > When the "tos" option is set correctly (to "nodelay"), the default
> > > > queueing in recent kernels already does that, because the pfifo_fast
> > > > queue is used (if I recall correctly).
> > >
> > > But there is never any queue on my Linux box. It all storms out of
> > > the ethernet interface and gets queued up in my cable modem which
> > > doesn't know anything about tos settings.
> >
> > That is not entirely correct. There is an output queue, and pfifo_fast
> > is the default (see the LARTC Howto, 9.2.1.1). But you are right when
> > you say you need something to slow down the data;the simplest choice
> > should be addingthe Token Bucket Filter (9.2.2.2).
> >
> > But if the wondershaper already does it all, then it's probably better
> > to go with it... :)
>
> You should read further into lartc.org, the linux traffic shaping
> capabilities are really wide and you can find lots of ways of doing what
> you want.
>
> In your case, I guess the logical choice would be to use HTB, with two
> classes, let's say if your cablemodem is 512kbps, you can save 112kbps for
> voice and signalling (yes it's extreme but it's an example), and 400kbps
> for the data. Also, you can put the former with top priority to minimize
> latency.
>
> Under those you can use sfq to make everything more fair, that helps a lot
> when saturating.
>
> This is a very short script, I'm sure there is something like this on
> lartc or htb's website.
>
> Something like this (completely untested, from memory so don't trust me):
>
> # delete the existing qdisc
> tc qdisc del dev eth1 root 2>&1 > /dev/null
>
> # init the htb qdisc
> tc qdisc add dev eth1 root handle 1: htb
>
> tc class add dev eth1 parent 1: classid 1:5 htb rate 512kbit
> tc class add dev eth1 parent 1:5 classid 1:10 htb rate 112kbit prio 0
> tc class add dev eth1 parent 1:5 classid 1:20 htb rate 400kbit prio 2
>
> # sfq for all of them
> tc qdisc add dev eth1 parent 1:5 handle 500: sfq perturb 10
> tc qdisc add dev eth1 parent 1:10 handle 100: sfq perturb 10
> tc qdisc add dev eth1 parent 1:20 handle 200: sfq perturb 10
>
>
> And now you need to set the filters up, which can be based on tc or using
> iptables' MARK target.
>
> For instance:
>
> # everything marked 10 in iptables go to 1:10 (the 112kbit)
> tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 10 fw \
> flowid 1:10
>
> # everything marked 20 in iptables go to 1:20 (the 400kbit)
> tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 20 fw \
> flowid 1:20
>
>
> And then mark in iptables (i don't remember sip's port very well, and you
> should also add RTP stuff too):
>
> # sip, mark 10
> iptables -t mangle -A PREROUTING -i eth2 -p tcp --destination-port 5060 \
> -j MARK --set-mark 10
> iptables -t mangle -A PREROUTING -i eth2 -p udp --destination-port 5060 \
> -j MARK --set-mark 10
>
> # default, mark 20
> iptables -t mangle -A PREROUTING -i eth2 -d 0.0.0.0/0 \
> -j MARK --set-mark 20
>
> In this case you could have used tc's native filters which are much faster
> than iptables, but also harder to setup, so if this is your first approach
> to this stuff I wouldn't recommend them (and don't worry, the speed
> difference is _not_ noticeable for that bandwidth).
>
>
> I hope this helps, however this is all untested, (ie. just wrote it) so
> please look into the docs to find out more.
>
>
> Thanks,
> Alberto
>
>
> _______________________________________________
> Asterisk-Users mailing list
> [EMAIL PROTECTED]
> http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
