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) {
Vincent
Le 15/12/2011 09:07, Stefan Hajnoczi a écrit :
> On Wed, Dec 14, 2011 at 02:42:12PM -0000, Vincent Autefage wrote:
>> Ok so the *Intel e1000* seems the only card which is impacted by the
>> bug.
> Let me recap with a summary of your debugging:
>
> QEMU 0.14.0, 0.15.0, and 1.0 built from source all have poor network
> performance below a 20 Mbit/s limit set with tc inside the guest.
>
> Ubuntu's 0.14.0 QEMU package does not have poor network performance.
>
> This problem only occurs with the emulated e1000 device. All other
> emulated NICs operate correctly.
>
> Now you could diff the e1000 emulation code to get the code changes
> between vanilla and Ubuntu:
>
> $ diff -u qemu-0.14.0-vanilla/hw/e1000.c qemu-0.14.0-ubuntu/hw/e1000.c
>
> (It's possible that there are no significant changes and this bug is
> caused by something outside e1000.c but this is place to check first.)
>
> Or you could even try copying Ubuntu's e1000.c into the vanilla QEMU
> source tree and retesting to see if the behavior changes.
>
> 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
