[LARTC] !bounded bandwidth borrowing only works from traffic shaping host

Linux Advanced Routing and Traffic Control

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

 



I'm experiencing an odd problem.  I have a testbed network configured as:

        .sink.qos.                                     .source.qos.
     ______
    |      |172.16.0.1
    | QoS1 |-----+
    |______|     |
                 |   ______             ______                         ______ 
     ______      |  |      | 172.16.0.3|      | 172.16.1.3  172.16.1.1|      |
    |      |     +--|Switch|-----------| QoS3 |-----------------------| QoS1 |
    | QoS2 |     +--|      |           |______|                       |______|
    |______|     |  |______|               |
        |________|                         |
            172.16.0.2                     | 192.168.1.47
                                           | (routeable to rest of office)
                                           V

The traffic shaping host is QoS3 (in the center of the diagram).  QoS3's
interfaces are:

eth0: 192.168.1.47
eth1: 172.16.1.3
eth2: 172.16.0.3

I am using a RedHat 7.1 (2.4.2) kernel with the latest iproute2 tools (001007).
eth0 and eth1 have no traffic shaping rules applied, eth2 is configured as:

----
#!/bin/sh

MBURST=16
TC=/usr/local/qos/compile/iproute2/tc/tc
IP=/usr/local/qos/compile/iproute2/ip/ip

# Start with a queuing discipline on interface ETH
$TC qdisc add dev eth2 root handle 1: cbq bandwidth 90Mbit avpkt 1000 mpu 64

# Root class (all of the bandwidth)
$TC class add dev eth2 parent 1:0 classid 1:1 cbq bandwidth 90Mbit        \
        rate 90Mbit allot 1514 weight 80Kbit maxburst $MBURST             \
        avpkt 1000 cell 8 prio 5 bounded isolated


# Traffic to qos2.sink (20Mbit)
$TC class add dev eth2 parent 1: classid 1:200 cbq bandwidth 90Mbit       \
        rate 20Mbit allot 1514 weight 20Kbit maxburst $MBURST              \
        avpkt 1000 cell 8 prio 5 

# Traffic to qos1.sink (70Mbit)
$TC class add dev eth2 parent 1: classid 1:300 cbq bandwidth 90Mbit       \
        rate 70Mbit allot 1514 weight 70Kbit maxburst $MBURST              \
        avpkt 1000 cell 8 prio 5 

$TC qdisc add dev eth2 parent 1:200 handle 2:201 pfifo
$TC qdisc add dev eth2 parent 1:300 handle 3:301 pfifo

# Direct packets through appropriate classes
$TC filter add dev eth2 parent 1:0 protocol ip prio 100 u32 match ip dst   \
        172.16.0.2 flowid 1:200
$TC filter add dev eth2 parent 1:0 protocol ip prio 100 u32 match ip dst   \
        172.16.0.1 flowid 1:300
---


I use 'ttcp' to generate tcp flows originating at qos1.source.qos (172.16.1.1)
destined for qos1.sink.qos and qos2.sink.qos (172.16.0.{1,2}).  If I add the
"bounded" keyword to the inner CBQs (1:200 and 1:300), the traffic is
appropriately shaped, giving approximately 20Mbit and 70Mbit to the sinks.

However, if I remove the bounded keyword (as is shown in the above
configuration), the two flows from qos1.source.qos each consume half of the
available bandwidth.  During the transfer, the avgidle statistic for 1:1
is ~68, and the more restricted class (1:200) borrows bandwidth
continuously.

The *strange* part is that if instead of generating the flows on qos1.source,
I generate the traffic from the traffic shaping host itself (that is, run
ttcp on QoS3), the classes show "correct" borrowing behavior.  That is,
the flow to qos1.sink completes first (consuming 70Mbits) followed by the
flow to qos2.sink completing.  The flow to qos2.sink uses only 20Mbits
during the time the flow to qos1.sink is active and the entire 90Mbits after
the flow to qos1.sink completes.

This occurs no matter how I vary this configuration, including leaving 
out the attaching of separate pfifo's to 1:200 and 1:300 (or any of the
parent classes), adjusting the bandwidth (these are 100Mbit nics), avpkt
size, maxburst, etc.

In all cases, the statistics (tc -s) show that the packets are being directed
to the correct inner CBQs.

Any clues, or further statistics required?

-- 
Bill Squier (groo@xxxxxxxxxxxx)                          http://www.netbsd.org

        I know I don't deserve another chance, but this _is_ America,
        and as an American, aren't I entitled to one?  --Sideshow Bob.



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux