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
>