XP Slow with 3D On (which is default).

[JamesBriant]

I just upgraded to 3.0.2 from 2.0.6 and my XP VMs ran like ass, specifically graphics. I could see the windows scroll, like running XP with no drivers. I have no need for 3D, so I turned that off in settings, and now it runs just as good as 2.0.6. This has allowed me to be productive, since I mostly use Visual Studio. I thought this info might help someone.

I have a 2009 13" MBP 2.5Ghz, 8GB RAM, 750Gb HD, 1920x1080 24" monitor, nVidia 9400. Is this just not going to cut it for 3D mode then?

Thanks,

Jamie

[ColoradoMarmot · Accepted solution]

The 13" MBP has limited graphics capability, but you still shouldn't have seen a dramatic performance slowdown. Make sure you only have 1 CPU configured, and 2GB of RAM for the VM.

[JamesBriant]

Hmm. I do have 2GB Ram for VM. But I have 2 CPUs configured. That bad?

[ColoradoMarmot]

Yep, you're likely starving the host for CPU cycles. General rule is 1 virtual CPU maximum per physical CPU (not core) on the host.

[JamesBriant]

Er, really? So in my dual quad-core server, I should run a single VM with just 2 CPUs??? I don't think thats the story from vmware.

And besides, the issue is solved by turning off 3D graphics. My guess would be that there's some dodgy frame buffer copying going on or something. Like maybe they just didn't bother making it work for XP since the driver model for Vista+ is completely different. (Which I wouldn't hold against them, since its like 10 years old, but it would be nice to know or have 3D default to off for XP).

Jamie

[ColoradoMarmot]

Sorry - I should have been more specific, my reference above was for single, dual core, CPU client machines, not servers (which are a whole different ball game).

For client machines, you can have multiple VM"s running, so long as each is configured with only a single virtual CPU. The issue is that by creating two, the VM locks both cores at the same time and starves the host. Multiple VM's each with 1 CPU work just fine (assuming you have enough memory).

[JamesBriant]

What about dual quad-core client machines? Like a Mac Pro?

[ColoradoMarmot]

I would think that 2-4 virtual CPU's per VM would be fine on that machine since there's at least one left free for the host OS. Given enough RAM you should easily be able to run multiple VM's without significant performance issues.

Nice toy by the way

[JamesBriant]

Not a toy.

I don't think that the number of VCPUs should make a difference except when the host is pegged 100%, which when I run into sluggishness, it isnt. This seems to be data bound. And since the two cores share the same L2 cache, if the problem is one of being data bound, limiting it to 1VCPU wont help. There also seems to be more delay loading in big files, which againt wont be solved by limiting it to one VCPU. If the osx host is too starved to process the file system structure, then the win32 guest is going to be blocked on an IOP. Sure, if the guest was running, e.g. raytracing on both core at 100%, then it could starve the OS, but again, this is not happening. My problems are occuring running Visual Studio and Edit Pad Pro. Not during debugging either, just editing blooming text.

I am going to try (finally) W7, and see if driver support is better, as that is my likely suspect right now.

Jamie

[three-cushion]

Re # of CPUs configured.

Where is the option set? At Guest compile time? or at Guest run time?

My iMac is a Intel Core 2 Duo. Has 2 cores ...1 Processor.

(Doesn't processor & CPU mean the same?)

What defines " 2 CPUs"?

Cheers, Jim B

[ColoradoMarmot]

No, you have 1 CPU and 2 cores. The option is set in the VM preferences (click settings, then CPU, then in your case, pick 1).

[ColoradoMarmot]

In your case, it definitely sounds like there is something else going on in your situation. If you're running Unity, turn that off, and try running in full screen mode - that usually increases response as well.

[JamesBriant]

Jim,

Its pretty much moot. You have 2 cores, each of which has an amount of L1 cache, and share an L2 cache. These two cores are in one physical chip. So in physical terms you have one "CPU", but in software and execution terms you have two CPUs. If you had two physical CPUs, each with one core, then they would each have their own L2 cache, however (before Nehalem) they would share the same memory controller, so there would still be contention between them.

Things get more complicated with Nehalem. Core i7s have 4 cores, but each core has two hardware threads. The OS treats them as 8 CPUs. With Pentium IV hyperthreading, we didn't see a doubling of speed, but with Nehalems, doing intense CPU work (real-time raytracing) we saw a 2x speed increase using 8 threads vs 4 threads. Core i5's don't have the hyperthreading, so a quad core i5 can only execute 4 threads. Nehalems also have the memory controller on chip. So if you have two physical Nehalems (mwahaha), then each chip has its own bank of memory. Super fast if the memory it needs is right attached to it - not so fast if it has to go through the other chip.

Jamie

[JamesBriant]

Well, in the interest of science, I tried your advice, not expecting it to make a difference, and behold, with 1 VCPU, the machine behaves over 3 times faster in a simple test. Humble pie for my lunch today.

I'm still not sure I completely accept your explanation, but there is no denying the results.

My test was simple. Load a huge file in a text editor and start scrolling (I do this a lot). See how far down it gets in 10 seconds. With 1 VCPU it got over 3 times as far down than with 2 VCPUs.

Thanks.

[admin]

Synchronization between virtual processors is more expensive than with physical processors because the host OS may not schedule the virtual processors at the same time. Even if you're not running intensive tasks, the guest OS is still doing some synchronization behind the scenes. In general, you should not use multiple vCPUs unless you know you need them. See also

[JamesBriant]

Ok, read that. That sounds awful.

"While the guest is trying to synchronize, even if Fusion has time on one

core, it may not be able to make progress and "spins" doing nothing,

since it needs both cores at the same time."

So it spin locks in particular situations. Why? Is this just something you have to do to make windows think its on a real processor or is this just some limitation of VT in general. You seem to be saying that if one core is running VM tasks then both cores have to be? Or maybe, if one core is in the host, then both cores have to be, so the one core in the Host keeps the other from running?

Sounds horrible, but I guess thats the kind of wizardry you have to do to make it work at all? And maybe why (sorry) Parallels is faster?

[ColoradoMarmot]

no worries, it's a black art, and I'm not sure anyone really understands why. XP in particular doesn't know how to use multiple CPU's so I'm sure that's part of the issue.

[admin]

You seem to be saying that if one core is running VM tasks then both cores have to be?

No, only in certain situations. Most of the time each vCPU can go off and do whatever it wants, but a few CPU instructions force synchronization between vCPUs. This problem applies to physical hardware, and so necessarily applies to all virtualization products (since we have to match what physical hardware does). On physical hardware, your CPUs can all be running all the time (so the overhead is negligible), but this is not true in a virtual environment.

[JamesBriant]

Well I appreciate your attempt to educate me. I am happily running vmware with 1 vCPU for now. Does this also apply to my VMWare Server box? I have a dual quad-core, and most of my VMs on it have 2 vCPUs. Will 1 vCPU help those too?

Jamie