From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXWEt-0000TL-7V for qemu-devel@nongnu.org; Mon, 05 Dec 2011 05:57:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXWEr-0007jv-NI for qemu-devel@nongnu.org; Mon, 05 Dec 2011 05:57:39 -0500 Received: from indium.canonical.com ([91.189.90.7]:34302) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXWEr-0007jp-Dk for qemu-devel@nongnu.org; Mon, 05 Dec 2011 05:57:37 -0500 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.71 #1 (Debian)) id 1RXWEp-0003ZG-Um for ; Mon, 05 Dec 2011 10:57:36 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 9811C2E8104 for ; Mon, 5 Dec 2011 10:50:52 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Mon, 05 Dec 2011 10:45:26 -0000 From: Vincent Autefage <899140@bugs.launchpad.net> Sender: bounces@canonical.com References: <20111202125742.13621.362.malonedeb@soybean.canonical.com> <20111202131025.12679.91449.launchpad@wampee.canonical.com> <4ED8E449.1010409@labri.fr> <4EDB98B2.6070408@labri.fr> <20111205082617.GA20569@stefanha-thinkpad.localdomain> Message-Id: <4EDCA13E.3080508@labri.fr> Errors-To: bounces@canonical.com Subject: Re: [Qemu-devel] [Bug 899140] Re: Problem with Linux Kernel Traffic Control Reply-To: Bug 899140 <899140@bugs.launchpad.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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 =C3=A9crit : > 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=3Dx86_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=3Dx86_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=3Dx86_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 p= roblem 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 par= ticular 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 wi= th 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