Situatie: wij delen hier een Casema Broadband Premium (Cable) verbinding (800kbit/128kbit) via Debian Linux 2.4.21 met iptables.
Nu maak ik sinds kort gebruik van QoS/tc om het traffic enigzins te shapen.
Ik heb als uitgangspunt het "wondershaper" script gebruikt (http://lartc.org/wondershaper/).
Dit script geeft voorrang aan o.a. ssh pakketten en ack pakketten. ssh verkeer zou dus sneller moeten gaan.
Nu is het probleem dat dit niet echt het geval is. ssh reageert wel beter als je bijvoorbeeld een upload doet of een mail verzend, maar op moment dat er weinig verkeer is, of enkel kazaa/emule sharing, reageert ssh trager dan in een niet-geshaped-te situatie.
Dit is het relevate deel van mijn script:
Ik had ergens gelezen dat de SFQ queue methode standaard een te grote queue lengte (128p) hanteert. Maar als er weinig verkeer is zou zich geen queue moeten opbouwen, toch?
Wat zit hier niet goed? Alvast bedankt.
Nu maak ik sinds kort gebruik van QoS/tc om het traffic enigzins te shapen.
Ik heb als uitgangspunt het "wondershaper" script gebruikt (http://lartc.org/wondershaper/).
Dit script geeft voorrang aan o.a. ssh pakketten en ack pakketten. ssh verkeer zou dus sneller moeten gaan.
Nu is het probleem dat dit niet echt het geval is. ssh reageert wel beter als je bijvoorbeeld een upload doet of een mail verzend, maar op moment dat er weinig verkeer is, of enkel kazaa/emule sharing, reageert ssh trager dan in een niet-geshaped-te situatie.
Dit is het relevate deel van mijn script:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
| #!/bin/bash
DOWNLINK=800
UPLINK=123
DEV=ppp0
[...]
###### uplink
# install root HTB, point default traffic to 1:20:
tc qdisc add dev $DEV root handle 1: htb default 20
# shape everything at $UPLINK speed - this prevents huge queues in your
# DSL modem which destroy latency:
tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k
# high prio class 1:10:
tc class add dev $DEV parent 1:1 classid 1:10 htb rate $[6*$UPLINK/10]kbit \
ceil ${UPLINK}kbit burst 6k prio 1
# bulk & default class 1:20 - gets slightly less traffic,
# and a lower priority:
tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[3*$UPLINK/10]kbit \
ceil ${UPLINK}kbit burst 6k prio 2
tc class add dev $DEV parent 1:1 classid 1:30 htb rate $[1*$UPLINK/10]kbit \
ceil $[$UPLINK-20]kbit burst 6k prio 3
# all get Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev $DEV parent 1:30 handle 30: sfq perturb 10
# TOS Minimum Delay (ssh, NOT scp) in 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip tos 0x10 0xff flowid 1:10
# ICMP (ip protocol 1) in the interactive class 1:10 so we
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
match ip protocol 1 0xff flowid 1:10
# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:
tc filter add dev $DEV parent 1: protocol ip prio 10 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:10
# MSN Messenger - standaard poort - chats prio geven
tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
match ip dport 1863 0xffff flowid 1:10
# Email - POP3 - ophalen voorrang geven
tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
match ip dport 110 0xffff flowid 1:10
# rest is 'non-interactive' ie 'bulk' and ends up in 1:20
[...] |
Ik had ergens gelezen dat de SFQ queue methode standaard een te grote queue lengte (128p) hanteert. Maar als er weinig verkeer is zou zich geen queue moeten opbouwen, toch?
Wat zit hier niet goed? Alvast bedankt.
:strip_icc():strip_exif()/u/63667/117.jpg?f=community)
/u/16987/junpei.png?f=community)