Hey there Joachim!
: Friend runs emule. It filles the shared (A-DSL) line so everything else
: gets slow, that annoys me quite.
It occurs to me that there are two ways to solve this problem.
- Put the download shaping on your internal interface (eth0?), while
leaving the upload shaping on your ppp0 interface.
- Drop all of your friend's traffic! ;)
Seriously, though, the problem is your choice of interface for shaping.
: However, after a few minutes the line is full of emule again ...
A line full of emule? Maybe you should call animal control! Next thing
you know you'll have zebras, monkeys, and giraffes on your ADSL line.
Won't Deutsche Telekom have something to say about that!
: Another question: does anyone know how I can specify the ACK packets
: more precicely than just by their small size ?
- Use tcng. [1] (I can't seem to post without plugging tcng. It's the
best way to write traffic control configs!)
- Use the ACK hint from the LARTC cookbook. [2] It's also in the
wondershaper. [3]
: I don't really understand the r2q value, although I read as most as I
: can. r2q = 1 is the only value which does not give me stupid syslog
: messages.
r2q is simply a divisor to help HTB calculate the optimal quantum. If you
are working with larger rates, the default r2q of 10 should suffice, but
if you are working with smaller rates, you may need to drop r2q so that
HTB calculates a reasonable quantum for you. (Alternatively, you can
specify quantum directly...) I assume that the packets in this example
are about 1500 bytes in size; they are conventional IP packets on
an Ethernet.
rate kbit (bps) r2q quantum (bytes)
----------------- ----- ---------------- ^
T1 1544 (193000) 10 19300 (12 packets) | r2q could
1024 (128000) 10 12800 (8 packets) | be larger***
512 (64000) 10 6400 (4 packets) |
256 (32000) 10 3200 (2 packets) r2q OK
ISDN 128 (16000) 10 1600* (1 packet) r2q OK
64 (8000) 10 800** |
32 (4000) 10 400** | r2q should
slow 16 (2000) 10 200** | be smaller
V
* Devik mentions this calculation in the HTB userguide as the example
for calculating quantum. [4] So, if you are shaping at rates below
128kbit, you should consider dropping your r2q or specifying quantum.
** These quantum parameters as calculated by HTB are smaller than the
MTU, therefore HTB will gripe to logging about this.
*** r2q could be larger, but does not need to be larger.
Again, r2q is a hint to HTB for calculation of quantum, therefore it is
unnecessary to alter r2q (or quantum) unless quantum will be below the
MTU.
For maximum granularity of sharing (borrowing from parents), a smaller
quantum would be needed. If shaping at higher rates, ease the
computational requirements by selecting a higher r2q, allowing classes to
borrow larger (quantum) numbers of tokens/ctokens per attempt.
See also Stef's definition of r2q and quantum and an example of these in a
practical situation. [5]
[ script snipped ]
Good luck, Joachim!
-Martin
[1] http://linux-ip.net/gl/tcng/node39.html
see tcc/fields4.tc, use "tcp_ACK"
[2] http://lartc.org/howto/lartc.cookbook.ultimate-tc.html
[3] http://lartc.org/wondershaper/
[4] http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#sharing
(see the chapter on quantum and r2q)
[5] http://www.docum.org/stef.coene/qos/faq/cache/31.html
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
