All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] Random Early Detection
@ 2005-05-26 15:46 Jason Bath
  2005-05-26 16:15 ` Jason Bath
  2005-05-30 15:46 ` Andy Furniss
  0 siblings, 2 replies; 3+ messages in thread
From: Jason Bath @ 2005-05-26 15:46 UTC (permalink / raw)
  To: lartc

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [LARTC] Random Early Detection
  2005-05-26 15:46 [LARTC] Random Early Detection Jason Bath
@ 2005-05-26 16:15 ` Jason Bath
  2005-05-30 15:46 ` Andy Furniss
  1 sibling, 0 replies; 3+ messages in thread
From: Jason Bath @ 2005-05-26 16:15 UTC (permalink / raw)
  To: lartc

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [LARTC] Random Early Detection
  2005-05-26 15:46 [LARTC] Random Early Detection Jason Bath
  2005-05-26 16:15 ` Jason Bath
@ 2005-05-30 15:46 ` Andy Furniss
  1 sibling, 0 replies; 3+ messages in thread
From: Andy Furniss @ 2005-05-30 15:46 UTC (permalink / raw)
  To: lartc

Jason Bath wrote:

> Any tips or hints?

Check your classification is working with tc -s class or qdisc ls dev 
ethx then if that's OK try setting the rates/ceils like I suggested last 
time you asked :-)

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-05-30 15:46 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-26 15:46 [LARTC] Random Early Detection Jason Bath
2005-05-26 16:15 ` Jason Bath
2005-05-30 15:46 ` Andy Furniss

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.