[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: |
Thu, 15 Dec 2011 16:48:13 -0000 |
Here is the problem !
The Ubuntu version works only because it not uses an *Intel e1000* but a
*rtl8139*.
Therefore, the problem about the e1000 is present in *all* version
(original or ubuntu ones).
Thus, the file *e1000.c* must contain some instructions which imply the
bad TC behavior.
Vincent
Le 15/12/2011 17:09, Stefan Hajnoczi a écrit :
> On Thu, Dec 15, 2011 at 3:03 PM, Vincent Autefage
> <address@hidden> wrote:
>> Ok,
>>
>> So the e1000.c and the e1000_hw.h have absolutely no difference between
>> the original and the ubuntu version...
>> The only differences witch refers to the *Intel e1000* in the wall
>> sources is this one :
>>
>>
>> diff -ru qemu//hw/pc_piix.c qemu-kvm-0.14.0+noroms//hw/pc_piix.c
>> --- qemu//hw/pc_piix.c 2011-12-15 15:37:28.539290000 +0100
>> +++ qemu-kvm-0.14.0+noroms//hw/pc_piix.c 2011-02-22
>> 14:34:38.000000000 +0100
>>
>> @@ -123,7 +141,7 @@
>> if (!pci_enabled || (nd->model&& strcmp(nd->model,
>> "ne2k_isa") == 0))
>> pc_init_ne2k_isa(nd);
>> else
>> - pci_nic_init_nofail(nd, "e1000", NULL);
>> + pci_nic_init_nofail(nd, "rtl8139", NULL);
>> }
>>
>> if (drive_get_max_bus(IF_IDE)>= MAX_IDE_BUS) {
> That looks like it is only changing the default NIC from e1000 to
> rtl8139.
>
> 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
- [Qemu-devel] [PATCH v2 0/9] various ARM fixes, Mark Langsdorf, 2011/12/22
- [Qemu-devel] [PATCH v2 4/9] arm: add dummy gic security registers, Mark Langsdorf, 2011/12/22
- [Qemu-devel] [PATCH v2 2/9] arm: Set frequencies for arm_timer, Mark Langsdorf, 2011/12/22
- [Qemu-devel] [PATCH 5/9] ahci: convert ahci_reset to use AHCIState, Mark Langsdorf, 2011/12/22
- [Qemu-devel] [PATCH v2 1/9] arm: add missing scu registers, Mark Langsdorf, 2011/12/22
- [Qemu-devel] [PATCH 9/9] arm: increase a9mp interrupts to 160, Mark Langsdorf, 2011/12/22
- [Qemu-devel] [PATCH v2 3/9] arm: add dummy v7 cp15 config_base_register, Mark Langsdorf, 2011/12/22
- [Qemu-devel] [PATCH v2 8/9] Add xgmac ethernet model, Mark Langsdorf, 2011/12/22
- [Qemu-devel] [PATCH 6/9] ahci: add support for non-PCI based controllers, Mark Langsdorf, 2011/12/22
- [Qemu-devel] [PATCH v2 7/9] add L2x0/PL310 cache controller device, Mark Langsdorf, 2011/12/22