Re: [LARTC] Low latency on large uploads - almost done but not quite.

[Stef Coene <stef.coene@docum.org>]

> Here's still my script, if you are interested to look at it.
I'm interested and I have some remarks.

> #!/bin/bash
>
> DEV=ppp0
>
> # delete any qdiscs or rule sets created so far.
> tc qdisc del dev $DEV root 2> /dev/null > /dev/null
> # tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
>
> # create the root qdisc
> tc qdisc add dev $DEV root handle 1: htb default 13
>
> # install a root class, so that other clients can borrow from each other.
> tc class add dev $DEV parent 1: classid 1:1 htb rate 15kbps ceil 15kbps
>
> # now install 4 sub classes for different priorities
> # highest priority for low latency games like quake3 and ssh / ftp control.
> tc class add dev $DEV parent 1:1 classid 1:10 htb rate 7kbps ceil 15kbps \
> prio 0 burst 20000b cburst 22000b
> # not as high but still high priority for ACK's - useful for keeping large
> # d/l's alive :)
> tc class add dev $DEV parent 1:1 classid 1:11 htb rate 7kbps ceil 15kbps
> prio 1 burst 200b cburst 200b
> # very few data allowed for HTTP requests, but still higher priority than
> bulk uploads.
> tc class add dev $DEV parent 1:1 classid 1:12 htb rate 2kbps ceil 15kbps
> prio 10 burst 1b cburst 1b
> # bulk uploads have no prio :D
> tc class add dev $DEV parent 1:1 classid 1:13 htb rate 1bps ceil 15kbps
> prio 20 burst 1b cburst 1b
Your burst is too low.  I understand you want a minimum burst, but you have to 
follow some rules.  The best you can do is to remove the burst/cburst option 
so htb can calculate the minimum burst/cburst for you.
And don't you get quantum errors in your kernel log?  That's because your 
quantum is too low for the classes.  There is a long explanation for this, 
see www.docum.org on the faq page.  
You also use different prio's.  This can be ok in most cases, except if you 
have a low prio class that's sending more data then the configured rate.  If 
you do so, the latency can go up for that class.  I (still) didn't test it 
myself, but you can find prove of it on the htb homepage.  The solution for 
this is to make sure you never put too much traffic in a low prio class.

> # now make all qdiscs simple pfifo
> # small queues for minimum latency
> tc qdisc add dev $DEV parent 1:10 handle 20: pfifo limit 0
> tc qdisc add dev $DEV parent 1:11 handle 30: pfifo limit 0
Are you sure limit 0 is possible ????

> # larger queues for more latency.
> tc qdisc add dev $DEV parent 1:12 handle 40: pfifo limit 5
> tc qdisc add dev $DEV parent 1:13 handle 50: pfifo limit 20
>
> #quake3-style udp games have been marked in iptables
> tc filter add dev $DEV protocol ip parent 1: prio 0 handle 1 fw flowid 1:10
> # icmp to get the response times.
> tc filter add dev $DEV protocol ip parent 1: prio 1 u32 match ip protocol 1
> 0xff flowid 1:10
> # ssh - not scp! scp is seperated by the TOS bits from ssh
> tc filter add dev $DEV protocol ip parent 1: prio 2 u32 match ip dport 22
> 0xffff match ip tos 0x10 0xff flowid 1:10
> # ftp
> tc filter add dev $DEV protocol ip parent 1: prio 3 u32 match ip dport 21
> 0xffff match ip tos 0x10 0xff flowid 1:10
> # ACK packets ..
> tc filter add dev $DEV protocol ip parent 1: prio 4 u32 match ip protocol 6
> 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10
> 0xff at 33 flowid 1:11
> # HTTP requests
> tc filter add dev $DEV protocol ip parent 1: prio 10 u32 match ip dport 80
> 0xffff flowid 1:12

Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/