Re: PRIO qdisc traffic does not work as expected

[Andy Furniss <adf.lists@gmail.com>]

GGounot wrote:
> Hello,
>
> This is a simple case I started from lartc howto but I can't make it
> work.
>
> The idea is : * 3 priorities * ftp.free.fr on prio 1 * 0.0.0.0/0 prio
> 2 * ftp.lip6.fr prio 3
>
> Or, when Internet line is saturated and I download from ftp.free.fr,
> my download should supersede all other downloads (my download should
> take all bandwidth). On the other hand a download from ftp.lip6.fr
> should occur only when there is some available bandwidth.
>
> But actually, when I download from ftp.free.fr and from ftp.lip6.fr
> at the same time, both downloads have the same speed.
>
> This is the script : _________________ #!/bin/bash
>
> tc=/sbin/tc ETH=eth1 #connected to the LAN
>
> $tc qdisc del dev $ETH root 2>/dev/null $tc qdisc del dev $ETH
> ingress 2>/dev/null
>
> ### PRIO ### # qdisc "prio", 3 levels $tc qdisc add dev $ETH root
> handle 1: prio $tc qdisc add dev $ETH parent 1:1 handle 10: pfifo $tc
> qdisc add dev $ETH parent 1:2 handle 20: pfifo $tc qdisc add dev $ETH
> parent 1:3 handle 30: pfifo
>
> PRIO1="212.27.60.27" #ftp.free.fr PRIO2="0.0.0.0/0"
> PRIO3="195.83.118.1" #ftp.lip6.fr # echo Prio 1 : $PRIO1 echo Prio 2
> : $PRIO2 echo Prio 3 : $PRIO3
>
> $tc filter add dev $ETH parent 1:0 prio 1 protocol ip u32 match ip
> src $PRIO1 flowid :1 $tc filter add dev $ETH parent 1:0 prio 3
> protocol ip u32 match ip src $PRIO2 flowid :2 $tc filter add dev $ETH
> parent 1:0 prio 2 protocol ip u32 match ip src $PRIO3 flowid :3
> _________________
>
>
> When I run : tc -s qdisc ls dev eth1 I see the 2 FIFOs showing
> traffic going through. I don't understand what I am doing wrong, any
> help will be appreciated.

I don't understand your setup so 2 options.

1.

You are only shaping the outgoing traffic, which isn't going to help
with downloads incoming traffic. There isn't a perfect solution for
shaping from the wrong end of a bottleneck, but you can sort of do it by
using ifb and limiting the the rate to say 10-20% below the incoming
bandwidth with htb/hfsc/etc.

2.

Your shaping is actually seeing the download traffic leaving eth but not
working because there is further buffering downstream after the prio so
you would need to again use something where you can set the
rates/overheads to make sure you are the bottleneck - this time you
shouldn't need to sacrifice bandwidth.