billsc26 wrote:I hope you found this information useful and can track down the issue. I'm guessing I'm not the only person running CPU intensive apps on an XP guest. Thanks for your help. Don't hesitate to ask if there is anything else I can do to help.
I still don't see any real difference between a XP VM that uses the different HALs. The one that uses I/O APIC might be marginally slower but it's not noticeable. The only issue I see is Windows Update often hogging the guest CPU for insanely long periods of time. This affects all XP VMs I have and I don't think it's what you're complaining about.
To sum up, I don't really see any problem. Could you please provide your VM for testing? At this point I suspect it's something about your VM, because your host hardware shouldn't be all that different. And I don't think you tried a clean, freshly installed XP SP3 VM?
billsc26 wrote:I hope you found this information useful and can track down the issue. I'm guessing I'm not the only person running CPU intensive apps on an XP guest. Thanks for your help. Don't hesitate to ask if there is anything else I can do to help.
I still don't see any real difference between a XP VM that uses the different HALs. The one that uses I/O APIC might be marginally slower but it's not noticeable. The only issue I see is Windows Update often hogging the guest CPU for insanely long periods of time. This affects all XP VMs I have and I don't think it's what you're complaining about.
To sum up, I don't really see any problem. Could you please provide your VM for testing? At this point I suspect it's something about your VM, because your host hardware shouldn't be all that different. And I don't think you tried a clean, freshly installed XP SP3 VM?
So I have a "clean" XP SP3. Nothing but the OS. No GAs. Nothing. I loaded up 4.3.2, booted the VM, rebooted the VM and I don't need to run any benchmarks to see that it is significantly slower after the reboot. Same thing, it's an ACPI multiprocessor HAL. 2 VCPU. So, yes, I just did try a clean XP SP3 and had exactly the same problem. I can send the VM if you like - the VDI is ~5 GB, however.
billsc26 wrote:So I have a "clean" XP SP3. Nothing but the OS. No GAs. Nothing. I loaded up 4.3.2, booted the VM, rebooted the VM and I don't need to run any benchmarks to see that it is significantly slower after the reboot. Same thing, it's an ACPI multiprocessor HAL. 2 VCPU. So, yes, I just did try a clean XP SP3 and had exactly the same problem. I can send the VM if you like - the VDI is ~5 GB, however.
It shouldn't be necessary... I can finally see the problem here. The performance differential actually isn't big enough on my system that it would immediately hit me, but I have a rough idea what's going wrong.
billsc26 wrote:So I have a "clean" XP SP3. Nothing but the OS. No GAs. Nothing. I loaded up 4.3.2, booted the VM, rebooted the VM and I don't need to run any benchmarks to see that it is significantly slower after the reboot. Same thing, it's an ACPI multiprocessor HAL. 2 VCPU. So, yes, I just did try a clean XP SP3 and had exactly the same problem. I can send the VM if you like - the VDI is ~5 GB, however.
It shouldn't be necessary... I can finally see the problem here. The performance differential actually isn't big enough on my system that it would immediately hit me, but I have a rough idea what's going wrong.
Ok, that's good news! Maybe it is hitting my specific machine more than yours. Core-i7 mobile. My problem has been that CPU-bound benchmarks don't look all that bad, but the look-and-feel takes a huge hit for some applications.
If there is anything more I can do to help, please let me know.
billsc26 wrote:Ok, that's good news! Maybe it is hitting my specific machine more than yours. Core-i7 mobile. My problem has been that CPU-bound benchmarks don't look all that bad, but the look-and-feel takes a huge hit for some applications.
We did find one problem that would hit XP performance (if using the multi-processing HAL) after the guest was rebooted (not before!). It is very likely that the problem would not affect CPU intensive benchmarks like SuperPI too much but would affect interactive behavior and anything I/O intensive. This bug would affect other 32-bit SMP guest as well, though perhaps to a lesser degree.
Based on what others are saying, there is some other problem which affects only Windows XP (no other OS) and also shows up with VMware. I can't say we've seen that.
Interestingly, this bug affected all guests (that uses the APIC directly) after the reboot, but I didn't notice any performance drops in my Core i5 box for the guests. It seems 32-bit XP for is affected adversely since it probably bangs on the TPR, although I would think Solaris 32-bit would be affected in a similar way, (didn't check it yet).
squall leonhart wrote:i actually found a pretty consistent way to demonstrate the issue
reboot into safe mode - the virtual machine is just about unuseable.
I haven't experimented as much as other people may have, but it also looks like taking the number of VCPUs down to one (1) kills my performance after a reboot. Pretty much unusable on my test VM (I think I called it a slideshow in an earlier post - and that's pretty accurate).
billsc26 wrote:I haven't experimented as much as other people may have, but it also looks like taking the number of VCPUs down to one (1) kills my performance after a reboot. Pretty much unusable on my test VM (I think I called it a slideshow in an earlier post - and that's pretty accurate).
We did not see anything close to that. I wonder if you're also hit by the Windows Update issue (svchost.exe hogging the guest CPU literally for hours)?
billsc26 wrote:I haven't experimented as much as other people may have, but it also looks like taking the number of VCPUs down to one (1) kills my performance after a reboot. Pretty much unusable on my test VM (I think I called it a slideshow in an earlier post - and that's pretty accurate).
We did not see anything close to that. I wonder if you're also hit by the Windows Update issue (svchost.exe hogging the guest CPU literally for hours)?
You guys really seem to have it in for Windows Update!
No, unless it's taking CPU cycles and doesn't show up on Task Manager, I am NOT having a problem with Windows Update. I've been asked several times about that, and after the first mention, I check CPU usage. At times I have seen svchost.exe take CPU for maybe 3-5 minutes (or more depending on VM slowdown) but I wait it out before doing any benchmarking. Many times I see nothing using CPU cycles once the guest boots up.
Also, when rebooting the VM or doing something that causes performance issues, Task Manager in the guest shows low CPU usage even when the VM is crawling along.
Just to add to this, I did notice a drop in performance in both my XP and Ubuntu 13.10 VM. Everything seems sluggish. Didn't do any investigation yet as I didn't have much time to do it. But something for sure : on 4.2.18 I didn't have any issue. Moreso, I was always amazed at how snappy the performance was for a VM, which impressed me a lot and was one of the reason I sticked with VirtualBox.
We know that with 4.3.x the VT-x / AMD-V code has been entirely rewritten. It's hard for me to find any evidence for this being the cause, but if Oracle wants to resolve the performance issue some are facing, maybe they should look there. We all know that new code base is rarely perfect at first release.
michaln wrote:You guys really seem to have it in for Windows Update!
Compared to Windows Update, a slideshow is like Speedy Gonzales - Arriba!! Arriba!! ándale!! ándale!
Maybe I'm just lucky, but while I've seen svchost (WU) consuming CPU cycles in the background on some VMs - even for some length of time (10-20 min), it hasn't bitten me as the CPU usage is low and it doesn't seem to impact the guest. Knock on wood! But, yes, even when it's running "normally" it does seem pretty slow. Updating a dozen or so VMs on Patch Tuesday can be a very painful experience. Unless there is something in the VM or the GAs that is causing the problem, we can't really blame that one on VBox.
