Re: Classes do not receive any traffic ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

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

[Bugtraq]     [Fedora Legacy]     [GCC Help]     [Yosemite News]     [Yosemite Photos]     [IP Tables]     [Netfilter Devel]     [Fedora Users]

Powered by Linux