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

[Vincent Autefage <899140@bugs.launchpad.net>]

Hi,

So we have another problem...
The thing is that the 0.14.0 (and all 0.14.0 rc) built from GIT has the 
same problem.
However, the package 0.14.0 from Ubuntu does not has this bug...


Le 05/12/2011 09:26, Stefan Hajnoczi a écrit :
> On Sun, Dec 04, 2011 at 03:54:12PM -0000, Vincent Autefage wrote:
>> 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...
> Thanks for checking if tc is involved in this bug.
>
> Git bisect can identify which commit introduced the bug between QEMU
> 0.14.0 and 0.14.1.  The following steps show how to do this:
>
> Clone the QEMU git repository:
> $ git clone git://git.qemu.org/qemu.git
> $ cd qemu
>
> Double-check that 0.14.1 has the bug:
> $ git checkout v0.14.1
> $ make distclean
> $ ./configure --target-list=x86_64-softmmu
> $ make
> $ # test x86_64-softmmu/qemu-system-x86_64 binary
>
> Double-check that 0.14.0 does *not* have the bug:
> $ git checkout v0.14.0
> $ make distclean
> $ ./configure --target-list=x86_64-softmmu
> $ make
> $ # test x86_64-softmmu/qemu-system-x86_64 binary
>
> Now you can be confident that 0.14.0 and 0.14.1 do indeed behave
> differently when built from source.  It's time to perform the bisect,
> you can read more about what this does in the git-bisect(1) man page.
>
> Find the commit that introduced the bug:
> $ git bisect start v0.14.1 0.14.0
> $ make distclean
> $ ./configure --target-list=x86_64-softmmu
> $ make
> $ # test x86_64-softmmu/qemu-system-x86_64 binary
>
> If tc achieves ~20 Mbit/s:
> $ git bisect good
>
> Otherwise:
> $ git bisect bad
>
> Git bisect will keep splitting the commit history in half until it
> reaches the point where QEMU's behavior changes from good to bad.  So
> you typically need to build and test a couple of times until the guilty
> commit has been identified.
>
> Stefan
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/899140

Title:
  Problem with Linux Kernel Traffic Control

Status in QEMU:
  New

Bug description:
  Hi,

  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.

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/899140/+subscriptions