Dear all,
I'd like to ask for help with HTB configuration (after
having read some manual pages, FAQs and forum posts).
Short version: is there a way to specify infinite burst for HTB?
(Infinite amount of data to use the "ceil" rate.)
Long version:
I have the following small topology:
cable modem (uplink to ISB)
|
<ethernet>
|
WLAN router
/ \
<WiFi> <ethernet>
/ \
laptop desktop
- ethernet: 100mbit/s (I suppose)
- WiFI: 56mbit/s nominal, in reality very bad, many and
grave stalls, cca. 500kbyte/s achievable on average. I
consider this an "unkown" link capacity.
- upstream bandwidth my ISP provides: 256kbit/s
The desktop (GNU/Linux, debian sarge) is where the traffic
shaping occurs. (Laptop-to-inet traffic is negligible, and
neither the WLAN router nor the XP laptop has traffic
shaping capabilities, AFAIK.)
This is what I'd like to do:
(1) desktop-to-inet traffic should be favored over
desktop-to-laptop traffic (since the former has much lower
throughput (256kbit/s vs. cca. 500kbyte/s) and higher
latency)
(2) on the desktop, a special restricted technical user
(call it "p2p") runs p2p software. The desktop-to-inet
traffic should be split into two parallel flows, "p2p" and
"!p2p". The entire desktop-to-inet traffic should be
constrained to 240kbit/s. If the two flows don't compete for
this 240kbit/s (their combined upload stays below
240kbit/s), then each can use whatever it feels like (for
example, "p2p" uses 220kbit/s, "!p2p" uses 10kbit/s). If
they do compete, then "p2p" should be constrained to
140kbit/s, and "!p2p" should be constrained to 100kbit/s.
For (1), I chose PRIO, for (2), I chose HTB.
legend: [qdisc], (class)
[1:0 PRIO, 2 bands]
/ \
/ \
band 0, favored band 1, back seat
/ \
/ \
(1:1 desktop-to-inet) (1:2 desktop-to-laptop)
| |
[10:0 HTB] [pfifo_fast]
/ \
/ \
100kbit/s 140kbit/s
/ \
/ \
(10:1 !p2p) (10:2 p2p)
| |
[pfifo_fast] [pfifo_fast]
----
DEV=eth0
P2P=140
NP2P=100
P2P_UID=...
LAPTOP=192.168.x.x
tc qdisc del dev $DEV root
iptables --table mangle --flush
iptables --table mangle --delete-chain
# Create [1:0 PRIO]
# Default: packets go to (1:1 desktop-to-inet)
tc qdisc add dev $DEV root handle 1:0 prio \
bands 2 priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
# Class (1:1 desktop-to-inet) and class (1:2 desktop-to-laptop)
# get automatically defined by qdisc [1:0 PRIO].
# Direct desktop-to-laptop packets to (1:2 desktop-to-laptop)
tc filter add dev $DEV parent 1:0 protocol ip \
u32 match ip dst $LAPTOP classid 1:2
# Create [10:0 HTB]
# Default: packets go to (10:1 !p2p)
tc qdisc add dev $DEV parent 1:1 handle 10:0 htb \
default 1
# Add HTB classes.
tc class add dev $DEV parent 10:0 classid 10:1 \
htb rate ${NP2P}kbit ceil $((NP2P + P2P))kbit
tc class add dev $DEV parent 10:0 classid 10:2 \
htb rate ${P2P}kbit ceil $((NP2P + P2P))kbit
# Direct packets marked as p2p to (10:2 p2p)
tc filter add dev $DEV parent 10:0 protocol ip \
handle 1 fw classid 10:2
# Mark p2p packets
iptables --table mangle --policy OUTPUT ACCEPT
iptables --table mangle --append OUTPUT --protocol ip \
--match owner --uid-owner $P2P_UID --jump MARK \
--set-mark 1
----
(I write the above from memory, so there can be typos.)
First, I'm not sure if the script above corresponds to the
graph at all. (Perhaps ICMP is missing, too...)
Second, I started a single TCP upload with the p2p user
to check if borrowing works. It does not, as in the output
of
tc -s -d class show dev $DEV
the "tokens" for class (10:2 p2p) becomes negative and so
the actual rate stays 140kbit/s (instead of 240kbit/s).
After reading the manual page again, I added the "burst 1mb"
parameter to this class, and it worked until 1 megabyte was
uploaded. However, I couldn't specify "burst 2047mb": the
TCP upload went virtually dead, and I saw very ugly values
in the output of
tc -s -d class show dev $DEV
(integer overflows, maybe?).
I got the impression from
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
that I wouldn't need "burst" at all. However, without "burst",
borrowing didn't work. With "burst", borrowing works, but only
for a while.
So, can anybody please tell me how to specify an infinite
burst at ceil rate?
Or do I have to look at something else, e.g. CBQ? (The WiFi
link's capacity is practically indeterminate; isn't that a
problem when configuring CBQ?) Since "burst" means the
highest number of tokens available simultaneously in the
bucket, it may not make much sense to wish for infinity.
Thank you,
lacos
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
