QoS-related question (non-shaping)

Hi NG!

Got mldonkey running here and I simply want P2P packets being sent after
any other packets in queue.

My intention should be quite clear: Decreasing latency. My calcutations
are as follows:

My upstream is 16 KB/sec. Since MTU is about 1500 bytes, sending such a
packet should take about 100 ms. So if my ping to a certain server
normally is about 70 ms, it never should get above 170 ms if packets in
queue are arranged correctyl (assuming no delay by downstream which is
128 KB/sec).

Packet marking and distributing into different qdiscs is no problem, but
the PRIO qdisc does not seem to work as I estimated. (Ping increases
above 2000 ms)

If everything work's fine, even with mldonkey at unlimited upload, ping
should never increase by more than 100 ms.

Anybody having an idea how to achieve this?

I never espected this to be so difficult ...



Thanks!

Claudio Lanzi wrote:
> Hi NG!
>
> Got mldonkey running here and I simply want P2P packets being sent after
> any other packets in queue.
>
> My intention should be quite clear: Decreasing latency. My calcutations
> are as follows:
>
> My upstream is 16 KB/sec. Since MTU is about 1500 bytes, sending such a
> packet should take about 100 ms. So if my ping to a certain server
> normally is about 70 ms, it never should get above 170 ms if packets in
> queue are arranged correctyl (assuming no delay by downstream which is
> 128 KB/sec).
>
> Packet marking and distributing into different qdiscs is no problem, but
> the PRIO qdisc does not seem to work as I estimated. (Ping increases
> above 2000 ms)
>
> If everything work's fine, even with mldonkey at unlimited upload, ping
> should never increase by more than 100 ms.
>
> Anybody having an idea how to achieve this?
>
> I never espected this to be so difficult ...

You can't just rely on prio because there is a big buffer in your
network device beyond the kernel queue.

You need to use prio within htb/cbq/hfsc so you can set a rate below
your link speed and "own the queue".

If you use dsl the rate will need to be about 20% less to account for
overheads, which are variable with packet size so there is no one right
answer to exactly how much to back off - if you tweak it as high as you
can then you may go over with different type of traffic.

If you can find out your type of dsl/work out your overheads (from cell
count on modem) then it's possible to patch kernel/tc to allow for it.

If you use htb then there is a tweak that makes it work one packet at a
time, by default it dequeues in pairs it also uses drr so rarely it may
still dequeue almost a pair - I use tweaked htb and don't really see
that in pracise though.

If you really care about latency it is worth tweaking (needs
kernel/module recompile) or use hfsc (but don't actually attach prio -
do it with the classes) or try cbq - I don't know how that behaves WRT
packet perfect shaping. You could also reduce mtu/modify mss with iptables.

Andy.

Could somebody please show up the way packets go from application to the
internet? Should look like...

Application --> .?. --> Qdisc --> .?. --> modem buffer --> internet



Andy Furniss wrote:
> Claudio Lanzi wrote:
>
>> Hi NG!
>>
>> Got mldonkey running here and I simply want P2P packets being sent
>> after any other packets in queue.
>>
>> My intention should be quite clear: Decreasing latency. My
>> calcutations are as follows:
>>
>> My upstream is 16 KB/sec. Since MTU is about 1500 bytes, sending such
>> a packet should take about 100 ms. So if my ping to a certain server
>> normally is about 70 ms, it never should get above 170 ms if packets
>> in queue are arranged correctyl (assuming no delay by downstream which
>> is 128 KB/sec).
>>
>> Packet marking and distributing into different qdiscs is no problem,
>> but the PRIO qdisc does not seem to work as I estimated. (Ping
>> increases above 2000 ms)
>>
>> If everything work's fine, even with mldonkey at unlimited upload,
>> ping should never increase by more than 100 ms.
>>
>> Anybody having an idea how to achieve this?
>>
>> I never espected this to be so difficult ...
>
>
> You can't just rely on prio because there is a big buffer in your
> network device beyond the kernel queue.
>
> You need to use prio within htb/cbq/hfsc so you can set a rate below
> your link speed and "own the queue".
>
> If you use dsl the rate will need to be about 20% less to account for
> overheads, which are variable with packet size so there is no one right
> answer to exactly how much to back off - if you tweak it as high as you
> can then you may go over with different type of traffic.
>
> If you can find out your type of dsl/work out your overheads (from cell
> count on modem) then it's possible to patch kernel/tc to allow for it.
>
> If you use htb then there is a tweak that makes it work one packet at a
> time, by default it dequeues in pairs it also uses drr so rarely it may
> still dequeue almost a pair - I use tweaked htb and don't really see
> that in pracise though.
>
> If you really care about latency it is worth tweaking (needs
> kernel/module recompile) or use hfsc (but don't actually attach prio -
> do it with the classes) or try cbq - I don't know how that behaves WRT
> packet perfect shaping. You could also reduce mtu/modify mss with iptables.
>
> Andy.

Claudio Lanzi wrote:
> Could somebody please show up the way packets go from application to the
> internet? Should look like...
>
> Application --> .?. --> Qdisc --> .?. --> modem buffer --> internet

look at the kptd on www.docum.org (some things have changed a bit but
it's an indication) - I assume you only have one machine or are you
acting as a geteway?

FWIW I didn't make clear in my last post that if you want near packet
perfect with htb then have just one class for bulk traffic.

HFSC is better and from a few recent tests I've done ls classes will not
baulk rt latency by more than one packet irrespective of the number of
ls classes. Also when I said don't use PRIO/SFQ I meant on rt classes -
on ls should be OK.

Andy.