[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Bug 899140] Re: Problem with Linux Kernel Traffic Cont
Re: [Qemu-devel] [Bug 899140] Re: Problem with Linux Kernel Traffic Control
Sun, 04 Dec 2011 15:54:12 -0000
The result without TC is about 120 Mbit/s.
I check the bandwidth with lot of programs (not only with Iperf) and the
result is also the same....
However, if I use the same raw image and the same TC configuration with
the version 0.14.0 of QEMU or with some real physical hosts, the result
with TC is about 19.2 Mbit/s what is the desired result...
Le 03/12/2011 19:48, Stefan Hajnoczi a écrit :
> On Fri, Dec 2, 2011 at 2:42 PM, Vincent Autefage
> <address@hidden> wrote:
>> address@hidden tc qdisc add dev eth0 root tbf rate 20mbit burst 20480 latency
>> address@hidden **ifconfig eth0 192.168.0.2*
>> Then if we check with /Iperf/, the real rate will be about 100kbit/s :
> What is the iperf result without tc? It's worth checking what rate
> the unlimited interface saturates at before applying tc. Perhaps this
> setup is just performing very poorly and it has nothing to do with tc.
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Problem with Linux Kernel Traffic Control
Status in QEMU:
The last main versions of QEMU (0.14.1, 0.15 and 1.0) have an important
problem when running on a Linux distribution which running itself a Traffic
Control (TC) instance.
Indeed, when TC is configured with a Token Bucket Filter (TBF) with a
particular rate, the effective rate is very slower than the desired one.
For instance, lets consider the following configuration :
# tc qdisc add dev eth0 root tbf rate 20mbit burst 20k latency 50ms
The effective rate will be about 100kbit/s ! (verified with iperf)
I've encountered this problem on versions 0.14.1, 0.15 and 1.0 but not with
In the 0.14.0, we have a rate of 19.2 mbit/s which is quiet normal.
I've done the experimentation on several hosts :
- Debian 32bit core i7, 4GB RAM
- Debian 64bit core i7, 8GB RAM
- 3 different high performance servers : Ubuntu 64 bits, 48 AMD Opteron,
128GB of RAM
The problem is always the same... The problem is also seen with a
Class Based Queuing (CBQ) in TC.
To manage notifications about this bug go to:
|[Prev in Thread]
||[Next in Thread]|