

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
3 messages in com.xensource.lists.xen-usersRE: [Xen-users] Slow network performa...| From | Sent On | Attachments |
|---|---|---|
| Martin Goldstone | May 23, 2007 8:04 am | |
| Petersson, Mats | May 23, 2007 8:16 am | |
| Martin Goldstone | May 23, 2007 9:16 am |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | RE: [Xen-users] Slow network performance between HVM guests | Actions... |
|---|---|---|
| From: | Petersson, Mats (Mats...@amd.com) | |
| Date: | May 23, 2007 8:16:39 am | |
| List: | com.xensource.lists.xen-users | |
-----Original Message----- From: xen-...@lists.xensource.com [mailto:xen-...@lists.xensource.com] On Behalf Of Martin Goldstone Sent: 23 May 2007 16:05 To: xen-...@lists.xensource.com Subject: [Xen-users] Slow network performance between HVM guests
Hi all,
We're running Xen 3.1 on Centos 5 here (x86_64, kernel 2.6.18), and we're seeing some odd networking issues with our Windows HVM guests. Perhaps someone here has some ideas they can offer.
Briefly, the specs of the host are: Dual Xeon 3 GHz (Dual Core + HT), 4GB RAM, 73 GB HDD. Network is e1000.
The Windows HVM guests are Windows Server 2003 R2 Standard x86-64, with 2 VCPUs, 1GB RAM, 16GB HDD (in a file), rtl8139 network.
Basically, file transfer speeds between guests (both on the same bridge) on the same host are approximately 10% (if not less) of the speed of file transfers from a HVM guest to another system (virtualised or not) away from that host. Any ideas, or is this normal behaviour?
Most likely it's because the network access is going through QEMU-DM, which means that Dom0 has to "emulate" the network device. With BOTH devices being emulated on the same Dom0, you get latency added in both ends, and there's less likely to be any "overlap" between them.
Do you by any chance also restrict the Dom0 to a single core?
Also, are the two guest domains running on the same or different cores? If both domains use the same core, they would obviously "stop each other" from running.
This is affecting us with Xen 3.03 and 3.0.4.1 as well, so it's not just a 3.1 thing. I've disabled iptables on dom0 to see if that makes a difference (it doesn't). We've tried the 32 bit version of Windows, and we've reduced the number of VCPUs to 1, and increased to 4, all without success. We originally thought it might have something to do with another issue we were experiencing (ping times reported in Windows were very strange, show latency of several thousand ms, and showing negative latency times as well) but that issue disappeared after setting the number of VCPUs to 1 (apparently there is a bug in the Windows Multiprocessor ACPI HAL (incidentally, does anyone know if this bug affects anything other than the displayed latency times?)).
The negative latency is probably the one reported in the internal Intel bug-tracker here: http://losvmm-bridge.sh.intel.com/bugzilla/show_bug.cgi?id=991 But it's not easy to know, since it's not accessible from outside Intel (or at least not from the AMD network, but I doubt that it's really a "hide this from AMD" attempt, but rather that the link is an internal Intel site).
My guess would be that the time is measured using timestamp counting, and it fails because it's taking the TSC from two different processor cores at different times, which leads to varying results. But that's speculation, and not based on any real understanding of why this is.
-- Mats
We haven't had any success tracking this down so far. Any ideas?
Thanks in advance for any help,
Martin
_______________________________________________ Xen-users mailing list Xen-...@lists.xensource.com http://lists.xensource.com/xen-users







