[Top][All Lists]

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

Re: [Qemu-devel] [Bug 899140] Re: Problem with Linux Kernel Traffic Cont

From: Vincent Autefage
Subject: Re: [Qemu-devel] [Bug 899140] Re: Problem with Linux Kernel Traffic Control
Date: Fri, 02 Dec 2011 14:42:14 -0000


So, the host command lines are :
*$ qemu -name A -sdl -m 512 -enable-kvm -localtime -k fr -hda 
debian1.img -net nic,macaddr=a0:00:00:00:00:01 -net 

The second is
*$ qemu -name B -sdl -m 512 -enable-kvm -localtime -k fr -hda 
debian2.img -net nic,macaddr=a0:00:00:00:00:02 -net 

On virual machines :

address@hidden ifconfig eth0*
address@hidden tc qdisc add dev eth0 root tbf rate 20mbit burst 20480 latency 

address@hidden **ifconfig eth0*

Then if we check with /Iperf/, the real rate will be about 100kbit/s :

address@hidden iperf -s*

address@hidden iperf -c*


Le 02/12/2011 14:34, Stefan Hajnoczi a écrit :
> Hi Vincent,
> Please give steps to reproduce the problem including the QEMU
> command-lines you used and what commands need to be run inside the
> guest and on the host.
> Stefan

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:

Bug description:

  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 
the 0.14.0...
  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:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]