From: Jason Bath <jbath@ckua.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Random Early Detection
Date: Thu, 26 May 2005 16:15:08 +0000 [thread overview]
Message-ID: <4295F60C.1050305@ckua.org> (raw)
In-Reply-To: <4295EF5B.6030703@ckua.org>
Oops. I was referring to changing the sfq to red or gred, not pfifo.
Jason Bath
Network Administrator
CKUA Radio Network
780.428.2017
Jason Bath wrote:
> 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
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next prev parent reply other threads:[~2005-05-26 16:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-26 15:46 [LARTC] Random Early Detection Jason Bath
2005-05-26 16:15 ` Jason Bath [this message]
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=4295F60C.1050305@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.