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