bartekR wrote:
Andy Furniss wrote:
DSl rates are hard to get right without patching tc/kernel as it uses
ATM and the overheads on a packet are high and vary with size in
53byte chunks. Without patching you need to back off from the rates.
I didn't knew that. Would You give me larger information about this ??
There may be a way to allow for them in kernel one day, but for now you
need to patch htb and tc to do it.
http://ace-host.stuart.id.au/russell/files/tc/tc-atm/
There is also a patch to make htb more accurate on that page.
Even if you patch you still have to back of for ingress traffic or it
will buffer up at your ISP/Teleco and mess up latency. The more you care
about latency the more you need to sacrifice bandwidth.
On 256kbit egress you are going to get latency up to 50ms because that's
how long a 1500 byte packet will take to transmit. If you don't tweak
htb it will be up to 100 because htb dequeues in pairs by default.
If you want less you could consider lowering mtu or mss clamping.
Andy Furniss wrote:
To make things worse ingress shaping needs you to back off even more
as you are at the wrong end of the bottleneck, so don't have total
control like on egress. The slower the link the harder it is, you
should use short child qdiscs on the htb bulk classes (limit
parameter) and try to arrange the htb rules so that interactive
classes (and don't have too many) get a rate much higher than they
ever need with a higher prio than bulk.
I will try things as You mentioned.
I have 3 interactive classes because of Skype and p2p. I had tried to
match Skype file transfers to user classes. Unfortunately Skype
connections are encrypted. Mine first idea was to mark this packet by
matching tos (similar to matching tos of ssh and scp) but it failed
because Skype always send packet with tos=0. Is there any other way to
do that ??
Sometimes p2p puts lots of ack packets. I don't want them to interfere
with low latencies needed for games.
Sometimes it's easier to match what you know is interactive and treat
the rest as bulk, you can still give acks/small packets a higher prio
than the rest, but put known game traffic highest prio.
I noticed you used 0 burst - IIRC 0 ended up bigger than using 10 for me
- I guess you get a default if you specify 0. You should only do this
for bulk traffic, for interactive it's better to let it burst through.
You don't really want to delay it at all.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
