Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
V4 is "not useable" slow.
- Thread starter BobInIndy
- Start date
V4 is "not useable" slow.
I updated .NET 3.5 on win PC - took a few minutes. On MacBook Pro running Parallels 4, it took 30 minutes.
Is there a way to speed this up?
bob
try increasing VM memory
see http://download.parallels.com/desktop/v4/docs/en/Parallels_Desktop_Users_Guide/22626.htm
also try switching number of CPUs in CPU tab 1<->2
Also check Optimization tab
turn off backups by means of time machine in General tab
Time Machine backups may decrease the performance of your virtual machine when it is running in parallel with the Time Machine backup.
If you have shared folders enabled, turn it off and see if things improve. I have noticed where shared folders makes my windows applications display terrible performance. You may need shared folder to do your work, but at least you might be able to narrow down where the problem is, if windows speeds up after disabling shared folders.
The HAL is chosen when you install windows, as far as I know the HAL will not update/change by switching on or off a CPU after windows has been installed.I wouldn't change the number of CPU's. It's a one way switch(once the HAL changes, it won't go back) and switching took my windows boot times from < 30 seconds to several minutes.
ACPI Uniprocessor to ACPI MultiProcessor
http://support.microsoft.com/kb/309283
"On Windows XP and later versions, the ACPI Uniprocessor HAL and the MPS Uniprocessor HAL recognize the existence of more than one processor and report the MP ID. Plug and Play detects that the computer devnode's hardware ID list has changed and moves the devnode back through the "found new hardware" detection process. Therefore, when you add a second processor, the MP files (HAL and kernels) are automatically installed, and you do not have to manually update the driver in Device Manager."
What it doesn't say is whether it changes back when you remove a CPU. So far in my experience, it doesn't.
Changing from an ACPI to non-ACPI HAL is not possible.
http://support.microsoft.com/kb/309283
"On Windows XP and later versions, the ACPI Uniprocessor HAL and the MPS Uniprocessor HAL recognize the existence of more than one processor and report the MP ID. Plug and Play detects that the computer devnode's hardware ID list has changed and moves the devnode back through the "found new hardware" detection process. Therefore, when you add a second processor, the MP files (HAL and kernels) are automatically installed, and you do not have to manually update the driver in Device Manager."
What it doesn't say is whether it changes back when you remove a CPU. So far in my experience, it doesn't.
Changing from an ACPI to non-ACPI HAL is not possible.
phesopheon
Member
See http://forum.parallels.com/showthread.php?t=32047 starting around post #8:http://support.microsoft.com/kb/309283What it doesn't say is whether it changes back when you remove a CPU. So far in my experience, it doesn't.
"Unfortunately you are right to some extent. When running in PD3 Windows uses "Standard PC" HAL, while switching to PD4 changes HAL to "ACPI" which is only slightly slower. Booting VM with multiple processors upgrades HAL to more slower "ACPI Multiprocessor HAL" (and never downgrades it back!)."
Paul
So two questions still remain then.
The first, is there a difference between a VM set up on a Boot Camp install verses one that occurs as a fresh install within Parallels.
I have successfully fixed both the 6 minute boot times and 200% CPU activity on my Boot Camp VM by simply changing the setup from 2 CPUs to one. There is no issue with going back and forth (boot as a VM vs a Boot Camp boot based on the same partition).
Changing that setting in Parallels (one based on either a physical CPU and not core or one that indicates a bug in the program) with my Boot Camp VM caused no problem. I did make sure to start the Parallels process from a fresh install (V3 to V4 upgrade to keep the known chipset value to "0"). I'm still using the same Boot Camp install that I've had from the start. All I do is make sure everything Parallels installs is manually removed before moving forward.
If there is a problem doing the same thing to a VM installed "drive", causing slow issues, then the question to the poster is how that change was handled. Was Tools uninstalled and reinstalled or was a change made in the settings with an immediate reboot following? Things like that.
The second question is more important and one to Parallels staff.
What is the CPU setting designed for? A core or a physical CPU?
It doesn't work with my Boot Camp install on a:
Model Name: MacBook Pro
Model Identifier: MacBookPro3,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.2 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 4 MB
Memory: 2 GB
Bus Speed: 800 MHz
Boot ROM Version: MBP31.0070.B07
SMC Version: 1.16f8
In fact, it caused just the thing I see in more than a few discussions in this forum. Long boot times, high CPU cycles, unresponsive systems, incomplete installs of Tools (including the Tools not installed error during VM boot). Things like that. All fixed by setting the CPU from 2 to 1.
I suspect the reactivation of Office XP is due to the fact that Boot Camp boots as a system having 2 CPUs while my Boot Camp VM boots having one. Or at least it was set set @ 2 the last time I looked. It's time to boot into Boot Camp and compare to see if Parallels has changed the way Boot Camp loads. Funny how how XP Pro doesn't pick up on that other than an initial reactivation on the first VM boot if the case is that Boot Camp loads with 2 CPUs and the Boot Camp VM loads with one. I'll post back if there's a need to update.
Sorry to troll this thread, but no one seems to want to answer my threads on the same topic (here and in my trouble ticket) and all I'm trying to do is have a good Parallels experience and support the software vendor I chose. I respect the workload placed on the Parallels team due to having a major update designed to run on many platforms and scenarios. But like others, my production time is important too, for Parallels is part of it.
The first, is there a difference between a VM set up on a Boot Camp install verses one that occurs as a fresh install within Parallels.
I have successfully fixed both the 6 minute boot times and 200% CPU activity on my Boot Camp VM by simply changing the setup from 2 CPUs to one. There is no issue with going back and forth (boot as a VM vs a Boot Camp boot based on the same partition).
Changing that setting in Parallels (one based on either a physical CPU and not core or one that indicates a bug in the program) with my Boot Camp VM caused no problem. I did make sure to start the Parallels process from a fresh install (V3 to V4 upgrade to keep the known chipset value to "0"). I'm still using the same Boot Camp install that I've had from the start. All I do is make sure everything Parallels installs is manually removed before moving forward.
If there is a problem doing the same thing to a VM installed "drive", causing slow issues, then the question to the poster is how that change was handled. Was Tools uninstalled and reinstalled or was a change made in the settings with an immediate reboot following? Things like that.
The second question is more important and one to Parallels staff.
What is the CPU setting designed for? A core or a physical CPU?
It doesn't work with my Boot Camp install on a:
Model Name: MacBook Pro
Model Identifier: MacBookPro3,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2.2 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 4 MB
Memory: 2 GB
Bus Speed: 800 MHz
Boot ROM Version: MBP31.0070.B07
SMC Version: 1.16f8
In fact, it caused just the thing I see in more than a few discussions in this forum. Long boot times, high CPU cycles, unresponsive systems, incomplete installs of Tools (including the Tools not installed error during VM boot). Things like that. All fixed by setting the CPU from 2 to 1.
I suspect the reactivation of Office XP is due to the fact that Boot Camp boots as a system having 2 CPUs while my Boot Camp VM boots having one. Or at least it was set set @ 2 the last time I looked. It's time to boot into Boot Camp and compare to see if Parallels has changed the way Boot Camp loads. Funny how how XP Pro doesn't pick up on that other than an initial reactivation on the first VM boot if the case is that Boot Camp loads with 2 CPUs and the Boot Camp VM loads with one. I'll post back if there's a need to update.
Sorry to troll this thread, but no one seems to want to answer my threads on the same topic (here and in my trouble ticket) and all I'm trying to do is have a good Parallels experience and support the software vendor I chose. I respect the workload placed on the Parallels team due to having a major update designed to run on many platforms and scenarios. But like others, my production time is important too, for Parallels is part of it.
While an exhaustive comparison of Uni vs Multi CPU config & hal performance is something that Parallels hopefully will provide(eventually), I can say that on my primary VM, switching the P4 config from 2 cores back to 1 did speed up boot times, even though it is still using the multi cpu hal. I can't say if performance is being compromised elsewhere.
Otoc: All of MS' activating products will force reactivation when they recognize certain number of hardware changes. When you boot to bootcamp, windows will see the actual Apple hardware, while in P4 windows will see virtualized hardware. I would hope that Parallels would have thought of this and made sure that the virtualized profile was close enough to the boot camp profile to avoid activation, but I'm not sure. AFAIK, just changing number of CPU's shouldn't trigger activation. Changing number of CPU's, type of cpus, drive controller, hard drive serial number, NIC MAC address, CD-ROM drive, amount of RAM, and type of video card certainly would trigger activation.
Otoc: All of MS' activating products will force reactivation when they recognize certain number of hardware changes. When you boot to bootcamp, windows will see the actual Apple hardware, while in P4 windows will see virtualized hardware. I would hope that Parallels would have thought of this and made sure that the virtualized profile was close enough to the boot camp profile to avoid activation, but I'm not sure. AFAIK, just changing number of CPU's shouldn't trigger activation. Changing number of CPU's, type of cpus, drive controller, hard drive serial number, NIC MAC address, CD-ROM drive, amount of RAM, and type of video card certainly would trigger activation.
Otoc: All of MS' activating products will force reactivation when they recognize certain number of hardware changes. When you boot to bootcamp, windows will see the actual Apple hardware, while in P4 windows will see virtualized hardware. I would hope that Parallels would have thought of this and made sure that the virtualized profile was close enough to the boot camp profile to avoid activation, but I'm not sure. AFAIK, just changing number of CPU's shouldn't trigger activation. Changing number of CPU's, type of cpus, drive controller, hard drive serial number, NIC MAC address, CD-ROM drive, amount of RAM, and type of video card certainly would trigger activation.
Thanks Ben. Interesting that while XP Pro requires no reactivation on a boot cycle, Office XP does each time there's a change in the boot source.
At least, so far, I don't have to talk to India for permission to use my Office software. I used up my allotment with XP Pro getting V4 to work as fast as V3. I have the script memorized...
modronmarch
Member
Another possible solution for slow startup times. Please check the following KB article: http://kb.parallels.com/en/5778