From: Jason Bath <jbath@ckua.org>
To: lartc@vger.kernel.org
Subject: [LARTC] Random Early Detection
Date: Thu, 26 May 2005 15:46:35 +0000 [thread overview]
Message-ID: <4295EF5B.6030703@ckua.org> (raw)
I'm streaming audio over a WAN that is 1.5Mbit/s. The audio has to go
both ways and can be over tcp or udp. The manufacturers recommend udp
as it has less overhead but has a higher chance of dropping out. The
audio requires 130-200kbit/s in each direction for a combined
260-400kbit/s. I have two transparent bridges on either side of the WAN
to do traffic control. I split it so that each bridge is capped at half
of the total bandwidth allowed with some leeway for performance since
most network traffic is one-sided in the exchange. ie: client at co-lo
makes http request which is small but then receives a huge amount of
data respectively to that http request.
My problem at this point is that this WAN handles all traffic from our
co-location - web, mail, ftp, smb and the audio. I find I get packet
loss on the audio when I'm doing smb file transfers (usually in the
handshake portion of the transaction) and almost everytime the co-lo
uses the web. I'd make a separate rule for the web but it doesn't fix
the general problem.
I'm wondering if my problem is global synchronization and if RED would
help quell my problem. Or else I'm handling the bursty traffic
improperly and need to tweak my current config. I tested a line or two
with red but I found the man page a bit misleading in regards to the
burst. My original line was:
tc qdisc add dev $DEV0 parent 1:20 handle 11: red limit 400kbit min 3000
max 6000 avpkt 1000 burst 40000
Yes, the 40000 is really high and the computer warned me about it - then
the network dropped to nothing until I reverted to the old pfifo line.
The man page recommended burst = (min + min + max) / (3 * avpkt). I
understand that should be in bytes, but the command calls for number of
packets.
Any tips or hints?
This is my script at the moment. I've applied all the rules on both
interfaces in the case that someone fiddles with ethernet cables at the
co-lo and can't remember which interface to put them into (Yes, my bad
for not labeling but if something goes wrong with the co-lo, I'm 300km away)
#!/bin/bash
DEV0=eth0
DEV1=eth1
tc qdisc del root dev $DEV0 2> /dev/null
tc qdisc del root dev $DEV1 2> /dev/null
sleep 2
tc qdisc add dev $DEV0 root handle 1: htb default 20
tc qdisc add dev $DEV1 root handle 2: htb default 20
tc class add dev $DEV0 parent 1: classid 1:1 htb rate 900kbit ceil 900kbit
tc class add dev $DEV1 parent 2: classid 2:1 htb rate 900kbit ceil 900kbit
# audio
tc class add dev $DEV0 parent 1:1 classid 1:10 htb prio 0 rate 200kbit
tc class add dev $DEV1 parent 2:1 classid 2:10 htb prio 0 rate 200kbit
# everything else
tc class add dev $DEV0 parent 1:1 classid 1:20 htb prio 2 rate 400kbit
ceil 400kbit
tc class add dev $DEV1 parent 2:1 classid 2:20 htb prio 2 rate 400kbit
ceil 400kbit
# audio ports tcp
tc filter add dev $DEV0 protocol ip parent 1:0 u32 match ip dport 2001
0xffff flowid 1:10
tc filter add dev $DEV1 protocol ip parent 2:0 u32 match ip dport 2001
0xffff flowid 2:10
tc filter add dev $DEV0 protocol ip parent 1:0 u32 match ip sport 2001
0xffff flowid 1:10
tc filter add dev $DEV1 protocol ip parent 2:0 u32 match ip sport 2001
0xffff flowid 2:10
# audio ports udp
tc filter add dev $DEV0 protocol ip parent 1:0 u32 match ip dport 2002
0xffff flowid 1:10
tc filter add dev $DEV1 protocol ip parent 2:0 u32 match ip dport 2002
0xffff flowid 2:10
tc filter add dev $DEV0 protocol ip parent 1:0 u32 match ip sport 2002
0xffff flowid 1:10
tc filter add dev $DEV1 protocol ip parent 2:0 u32 match ip sport 2002
0xffff flowid 2:10
tc qdisc add dev $DEV0 parent 1:10 handle 10: pfifo
tc qdisc add dev $DEV0 parent 1:20 handle 11: sfq perturb 10
tc qdisc add dev $DEV1 parent 2:10 handle 10: pfifo
tc qdisc add dev $DEV1 parent 2:20 handle 11: sfq perturb 10
--
Jason Bath
Network Administrator
CKUA Radio Network
780.428.2017
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next reply other threads:[~2005-05-26 15:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-26 15:46 Jason Bath [this message]
2005-05-26 16:15 ` [LARTC] Random Early Detection Jason Bath
2005-05-30 15:46 ` Andy Furniss
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=4295EF5B.6030703@ckua.org \
--to=jbath@ckua.org \
--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.