Dear reader, I'm not updating these pages anymore. If you have tc or ip related questions, you can post them on the LARTC mailing list.

Used kernel, iproute2+tc and hardware

I switched to iproute2-2.4.7-now-ss010824.tar.gz and kernel 2.4.9 on 4/9/01. And I have some new hardware : AMD 1.4 Ghz with 256 MB Ram.

I switched to iproute2-2.4.7-now-ss010803.tar.gz and kernel 2.4.7 on 8/8/01.


My kernel 2.2.18 config : .config

My kernel 2.4.4 config : .config

My kernel 2.4.8 config : .config

My kernel 2.4.20 config : .config


I'm using 2 10mbit hubs to connect all the hardware. I have a 1.4 Ghz AMD, a 300 Mhz AMD (server), a 120 Mhz Pentium (firewall), 2 486's (traffic generators) and a laptop (Compaq Armada 400 Mhz Pentium). And of course a bunch of NIC's and hard disks.

Real-time bandwidth monitor

I wanted to monitor the outgoing traffic on a NIC. For that I needed a real-time monitoring of the bandwidth and an average. I also wanted to know the bandwidth of the different classes.

I couldn't find a tool to do that for me. So I wrote a small Perl script and I called it When I setup my tests, I use the ipchains/iptables tool to mark all the packets that I want to put in a class. I use this mark to filter the packets and to put them in the right class. At the same time, I created a chain for the traffic so each packet that will be putted in a class will also pass his own chain. So I have a chain that contains exatly all the traffic of only one class.

All the chains have a built-in byte counter. When you have the value of these byte counter and divide that by the elapsed time, you have the bandwidth. I used this idea in the script The script reads the byte counters from the different chains, gets the time in microseconds and calculates the bandwidth.

So in my setup, I use one computer to generate traffic and to setup the QOS. Another computer on the network is the receiver. The scripts runs on the computer that generates the traffic and not on the bottleneck.


I allways use the fw filter based on the marks of the packets. For testing it's easier to use the destination port as filter, so you need only a second PC as the destination. In real life, you are probably using a combination of port/ip-address, but you will have the same result as if you where using the destination port.

An overview of filters can be found on this page.

Traffic generators

Overview on this page.