CPU usage and eventual lockup issue(s)
Moderators: Cat_7, Ronald P. Regensburg, ClockWise
CPU usage and eventual lockup issue(s)
Hello
I have been using Ronald’s newest builds from here since 22 July, with great success EXCEPT (see below.) I have mostly used the “H” build, but also the “S” from time to time.
I fiirst succeeded with SS with the “basic” 2.3 under OS X 10.4 several months ago. It was stable and did what I wanted it to do. This is on a 2001 Quicksilver 867 PPC Mac, at the time, and same machine later upgraded to a 1.6 accelerator.
I use the ROM from Apple Update 1.
OK, from the beginning, SS would exhibit what looks sort of similar to a memory leak, except in regard to CPU useage, not memory. It would run the CPU at anywhere from 10 to 30 percent, while in fact it (SS) was idle. These numbers would increase with time to where eventually the CPU would be running at nearly 100% constantly, devoting all or most of that to SS, even though SS wasn’t doing anything. SS would, however, continue to function if I could tolerate the CPU situation.
On upgrading to 10.5, I was unhappy with several other aspects of the SS operation and that is when I started trying builds from here. The newest one (21 July) is superb, except the problem mentioned above is, in one way, worse. It still behaves as stated with the CPU, but on looking further, it is making continued Mach System and Unix System calls, especially the former. They begin slowly, accelerate, and when they reach a billion or so (yes, billion, in the case of the Mach) SS simply locks up. A SS reboot, of course, fixes things for a while but it is inconvenient, and also the monopolizing of the CPU as SS ramps up to the lockup point is not good.
I should add my emulator is using OS 9.0 and has since the beginning, although I also tested it successfullly under 8.6 and one of the System 7 releases, 7.5.5 I believe.
Any help/suggestions would be appreciated, and my thanks.
P.S Just FYI, re. questions in another thread, Apple's ROM Update 1 IS, I am quite sure, the System 8.6 ROM.
I have been using Ronald’s newest builds from here since 22 July, with great success EXCEPT (see below.) I have mostly used the “H” build, but also the “S” from time to time.
I fiirst succeeded with SS with the “basic” 2.3 under OS X 10.4 several months ago. It was stable and did what I wanted it to do. This is on a 2001 Quicksilver 867 PPC Mac, at the time, and same machine later upgraded to a 1.6 accelerator.
I use the ROM from Apple Update 1.
OK, from the beginning, SS would exhibit what looks sort of similar to a memory leak, except in regard to CPU useage, not memory. It would run the CPU at anywhere from 10 to 30 percent, while in fact it (SS) was idle. These numbers would increase with time to where eventually the CPU would be running at nearly 100% constantly, devoting all or most of that to SS, even though SS wasn’t doing anything. SS would, however, continue to function if I could tolerate the CPU situation.
On upgrading to 10.5, I was unhappy with several other aspects of the SS operation and that is when I started trying builds from here. The newest one (21 July) is superb, except the problem mentioned above is, in one way, worse. It still behaves as stated with the CPU, but on looking further, it is making continued Mach System and Unix System calls, especially the former. They begin slowly, accelerate, and when they reach a billion or so (yes, billion, in the case of the Mach) SS simply locks up. A SS reboot, of course, fixes things for a while but it is inconvenient, and also the monopolizing of the CPU as SS ramps up to the lockup point is not good.
I should add my emulator is using OS 9.0 and has since the beginning, although I also tested it successfullly under 8.6 and one of the System 7 releases, 7.5.5 I believe.
Any help/suggestions would be appreciated, and my thanks.
P.S Just FYI, re. questions in another thread, Apple's ROM Update 1 IS, I am quite sure, the System 8.6 ROM.
-
- Student Driver
- Posts: 16
- Joined: Tue Apr 15, 2008 10:42 pm
- Location: Chicago
CPU usage
FWIW, for me SS uses close to 150% CPU during its startup (this is using either of the 21 July builds), then settles down to 90% to almost 100% CPU during routine usage. I am running OS 10.4.11 on a year-old Santa Rosa MBP 2.4GHz, 4G RAM. What is interesting is that both SS and the rest of the machine seem to work normally despite these alarming numbers seen in Activity Monitor. I have even been able to run WinXP in Parallels at the same time. I have been very happy using SS to run WordPerfect 3.5ep and ClarisWorks 4.0v6, and occasionally iCab and miscellaneous other programs in OS 8.6. Recently I have kept SS running for several days at a time (putting the machine to sleep rather than shutting down when not in use), with frequent switching between SS and OSX, including frequent copying and pasting, and have not had a problem. I am very grateful for this to Ronald and Cat_7 as well as Gwenolé, and John Rethorst and many others on the WordPerfect Yahoo list.
Thomas
Many thanks for your reply. I too am very grateful to have SS at all, and to have it working now as well as it is. I certainly hope I didn't sound like I was complaining. I"d just like to get this last problem out of the way.
Yes, I think the high CPU numbers in Monitor probably aren't that significant, although at least on my machine I think they are real (fans run more, thermal monitor shows increases, etc.) What is a problem is that SS locks up every few hours (it varies) requiring it to be restarted and crashing anything running at the time.)
It is a funny hang, in that the clock in the emulator will continue to run and there are certain other signs of responsiveness but none of the apps. will function.
I always sleep my machines at night, rather than shutting them down, but my personal workaround at the moment is to quit SS before sleeping the Mac, so at least we start "fresh" in the morning.
Two earlier threads here certainly sound like the same sort of situation, sort of. I'd still like to get a handle on it.
First:
http://www.emaculation.com/forum/viewto ... f08a6c2785 (Yes, this was involving a build compiled under Windows)
Second:
http://www.emaculation.com/forum/viewto ... ck+lock%2A
(BTW, I'm not real familiar with the multi-core processors. I take it from your post that on a dual-core, the Activity Monitor simply lumps the two to allow a 200% max showing?)
Many thanks for your reply. I too am very grateful to have SS at all, and to have it working now as well as it is. I certainly hope I didn't sound like I was complaining. I"d just like to get this last problem out of the way.
Yes, I think the high CPU numbers in Monitor probably aren't that significant, although at least on my machine I think they are real (fans run more, thermal monitor shows increases, etc.) What is a problem is that SS locks up every few hours (it varies) requiring it to be restarted and crashing anything running at the time.)
It is a funny hang, in that the clock in the emulator will continue to run and there are certain other signs of responsiveness but none of the apps. will function.
I always sleep my machines at night, rather than shutting them down, but my personal workaround at the moment is to quit SS before sleeping the Mac, so at least we start "fresh" in the morning.
Two earlier threads here certainly sound like the same sort of situation, sort of. I'd still like to get a handle on it.
First:
http://www.emaculation.com/forum/viewto ... f08a6c2785 (Yes, this was involving a build compiled under Windows)
Second:
http://www.emaculation.com/forum/viewto ... ck+lock%2A
(BTW, I'm not real familiar with the multi-core processors. I take it from your post that on a dual-core, the Activity Monitor simply lumps the two to allow a 200% max showing?)
- Ronald P. Regensburg
- Expert User
- Posts: 7834
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
The CPU usage of SheepShaver is indeed something that needs to be investigated, although it does not seem to do any harm. On my Intel Core 2 Duo iMac other processes do not seem to be hindered. I see peaks of 140%, but when only the Finder is running in SheepShaver, usage returns to around 70%.
Earlier reports of SheepShaver becoming unresponsive frequently, were related to a cursor problem. That problem is solved in the current builds.
I rarely have SheepShaver crashing. But I always quit SheepShaver when not in use. Remember how on actual hardware Macs with MacOS, it was not unusual to have at least once a day a system crash, or in later MacOS versions a unintentional application quit that left the system unstable. SheepShaver cannot be more stable than the real thing, on the contrary.
BTW: On my iMac, both cores are used by SheepShaver.
Earlier reports of SheepShaver becoming unresponsive frequently, were related to a cursor problem. That problem is solved in the current builds.
I rarely have SheepShaver crashing. But I always quit SheepShaver when not in use. Remember how on actual hardware Macs with MacOS, it was not unusual to have at least once a day a system crash, or in later MacOS versions a unintentional application quit that left the system unstable. SheepShaver cannot be more stable than the real thing, on the contrary.
BTW: On my iMac, both cores are used by SheepShaver.
-
- Space Cadet
- Posts: 3
- Joined: Tue Aug 12, 2008 12:06 pm
- Location: Bordeaux
CPU usage
i check this morning CPU usage OS9 idle (desktop without any interaction)
version 2.3 from G.Beauchene CPU usage is 5%
2008 releases are from 50 to 70%
i think there is a little problem ... probably a loop or something like.
version 2.3 from G.Beauchene CPU usage is 5%
2008 releases are from 50 to 70%
i think there is a little problem ... probably a loop or something like.
- Ronald P. Regensburg
- Expert User
- Posts: 7834
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
kelvin31415 did most of the programming lately. Maybe he can shed some light on this problem that apparently was introduced after the 2.3 snapshot (May 2006) by Gwenole. Since then, more people have made changes to the source though, including Gwenole himself.
Last edited by Ronald P. Regensburg on Tue Aug 12, 2008 8:41 pm, edited 1 time in total.
-
- Tinkerer
- Posts: 83
- Joined: Sat Apr 12, 2008 8:22 pm
I'll do some profiling and see if it sheds any light on where the CPU time is going. It might help if we could narrow down the history of when the phenomenon first appeared, as we could then look in the source code change log for clues.Ronald P. Regensburg wrote:kelvin31415 did most of the programming lately. Maybe he can shed some light on this problem that apparently was introduced after the 2.3 snapshot ( November 2005) by Gwenole. Since then, more people have made changes to the source though, including Gwenole himself.
It might have something to do with the version of SDL we're building with, or the inclusion of a GUI, but that's only speculation. I'll do some profiling sometime in the next week or two, as time permits.
- Ronald P. Regensburg
- Expert User
- Posts: 7834
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
I tried several older (Intel or UB) builds on my Intel iMac. All builds I could trace, going back to a build by Cat_7 from March 11 2007, have the same heigh CPU usage. This March 11 2007 build is a build with no preferences editor included yet. It was probably built with the SDL installed by Fink.
The May 14 2006 snapshot by Gwenole does not have this heigh CPU usage.
There is a huge difference on my Intel iMac in perceived speed, probably mostly or only the speed in drawing on the screen, between the May 14 2006 snapshot by Gwenole (slow) and the March 11 2007 and later builds (snappy). Could that be related to the CPU usage?
The May 14 2006 snapshot by Gwenole does not have this heigh CPU usage.
There is a huge difference on my Intel iMac in perceived speed, probably mostly or only the speed in drawing on the screen, between the May 14 2006 snapshot by Gwenole (slow) and the March 11 2007 and later builds (snappy). Could that be related to the CPU usage?
-
- Tinkerer
- Posts: 83
- Joined: Sat Apr 12, 2008 8:22 pm
Indeed. Gwenole revised the video refresh code during that period to improve performance, and the approach used would consume more CPU time. A quick profiling run suggests that 85% of SheepShaver's CPU time is consumed in that code. I think this is a tradeoff we're all probably happy to make.Ronald P. Regensburg wrote:There is a huge difference on my Intel iMac in perceived speed, probably mostly or only the speed in drawing on the screen, between the May 14 2006 snapshot by Gwenole (slow) and the March 11 2007 and later builds (snappy). Could that be related to the CPU usage?
-
- Tinkerer
- Posts: 83
- Joined: Sat Apr 12, 2008 8:22 pm
As an experiment to confirm the cause of high CPU consumption, I tried building with the VOSF configuration option enabled. (VOSF is video on segfault, a different approach to video refresh.) This caused CPU consumption to go down dramatically, but video performance with frameskip 0 was poor (those who favor the software cursor would be unhappy). I then switched to frameskip 4 and video performance was OK (using the hardware cursor), while CPU consumption remained low.
The performance interactions are unfortunate and suggest that standard builds for OS X should continue to use --disable-vosf. However, Gwenole appears to believe that VOSF works better on non-OS X platforms than it does on OS X. Those doing builds for such platforms should consider trying it.
The performance interactions are unfortunate and suggest that standard builds for OS X should continue to use --disable-vosf. However, Gwenole appears to believe that VOSF works better on non-OS X platforms than it does on OS X. Those doing builds for such platforms should consider trying it.
- Ronald P. Regensburg
- Expert User
- Posts: 7834
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
The application I use most in SheepShaver uses a dozen different color cursors, so the hardware cursor is not an option for me. I do not mind the CPU consumption, it does not seem to cause any problems with other processes that run while I use SheepShaver and the current SheepShaver build itself runs beautifully.
Maybe the hardware cursor version could be built with VOSF enabled. You wrote that video performance was "OK" when used with frameskip 4. How does that "OK" compare to the performance with VOSF disabled?
On the other hand, the aim should be to eventually be able to build one single version of SheepShaver, possibly with the choice of cursor as a setting in prefs.
Maybe the hardware cursor version could be built with VOSF enabled. You wrote that video performance was "OK" when used with frameskip 4. How does that "OK" compare to the performance with VOSF disabled?
On the other hand, the aim should be to eventually be able to build one single version of SheepShaver, possibly with the choice of cursor as a setting in prefs.
-
- Tinkerer
- Posts: 83
- Joined: Sat Apr 12, 2008 8:22 pm
I feel the same way, even though I use the hardware cursor version.Ronald P. Regensburg wrote:I do not mind the CPU consumption, it does not seem to cause any problems with other processes that run while I use SheepShaver and the current SheepShaver build itself runs beautifully.
I saw no obvious difference, although my experiment was cursory. Individuals who are building their own binaries may want to give it a try, but for the semi-official Emaculation OS X builds I would suggest not using it. (I would like to see somebody try a Windows build with VOSF, though.)Ronald P. Regensburg wrote:Maybe the hardware cursor version could be built with VOSF enabled. You wrote that video performance was "OK" when used with frameskip 4. How does that "OK" compare to the performance with VOSF disabled?
Yes, that would be nice. I have not yet been able to devise a workaround for the SDL problems that prevent it. Perhaps when SDL 2 is ready?Ronald P. Regensburg wrote:On the other hand, the aim should be to eventually be able to build one single version of SheepShaver, possibly with the choice of cursor as a setting in prefs.
Hi,
How would I go about building a windows version with vosf? I never give the --disable-vosf parameter to configure when building.
What puzzles me more is the fact that the latest Windows builds, including the cursor fix, crash SheepShaver with OS 9 and less then 512 Mb memory, while they run OS 8.6 without those problems.
In conjunction with that, the OSX builds will not accept more then 512 Mb memory setting.
Cat_7
How would I go about building a windows version with vosf? I never give the --disable-vosf parameter to configure when building.
What puzzles me more is the fact that the latest Windows builds, including the cursor fix, crash SheepShaver with OS 9 and less then 512 Mb memory, while they run OS 8.6 without those problems.
In conjunction with that, the OSX builds will not accept more then 512 Mb memory setting.
Cat_7
-
- Tinkerer
- Posts: 83
- Joined: Sat Apr 12, 2008 8:22 pm
I believe that VOSF is the default, so if you are not configuring with --disable-vosf then your Windows version is probably using it.Cat_7 wrote:How would I go about building a windows version with vosf? I never give the --disable-vosf parameter to configure when building.
Did earlier versions not exhibit that problem, and if so, do you have any idea when the problem first showed up?What puzzles me more is the fact that the latest Windows builds, including the cursor fix, crash SheepShaver with OS 9 and less then 512 Mb memory, while they run OS 8.6 without those problems.
I will have a look at that when I have some free time, unless somebody beats me to it.In conjunction with that, the OSX builds will not accept more then 512 Mb memory setting.
- Ronald P. Regensburg
- Expert User
- Posts: 7834
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
The May 2006 snapshot by Gwenole Beauchesne does not have the high CPU usage.
You can find it here: http://gwenole.beauchesne.info/en/projects/sheepshaver
Note that this version has several bugs that are resolved in the latest builds. Notably the shared folder cannot be used for files that have Mac-specific properties (like resource-fork and type/creator metadata) and the cursor is displayed a few pixels off in many applications.
Edit: If you need Classic applications, why did you install Leopard on your PowerBook? In Tiger on G4 you can run Classic, Tiger is a better match with your PowerBook, and it is still supported by Apple with updates.
You can find it here: http://gwenole.beauchesne.info/en/projects/sheepshaver
Note that this version has several bugs that are resolved in the latest builds. Notably the shared folder cannot be used for files that have Mac-specific properties (like resource-fork and type/creator metadata) and the cursor is displayed a few pixels off in many applications.
Edit: If you need Classic applications, why did you install Leopard on your PowerBook? In Tiger on G4 you can run Classic, Tiger is a better match with your PowerBook, and it is still supported by Apple with updates.
Re: CPU usage and eventual lockup issue(s)
I am only familiar with Classic Macs, and I need to run non-game applications like ClarisCAD, WriteNow, GraphicConverter (PPC version) and a few others. I have some very limited experience with BasiliskII for Windows, but I would like to use SheepShaver on Mac OS X. I have installed the Chubby Bunny COIV4.0.1 version, and eventually got it to work, minus some issues, the most urgent of which is this post. The high CPU usage of SheepShaver all but precludes running it on a portable machine. In my case (OS X Yosemite, 2.6 Ghz, 10.10.5), the Activity Monitor reads ~108 whether SS is doing anything or just running the finder or minimized: the battery life is estimated at under 1 hour (!). This seems to me (a total programming ignoramus) to be caused by something basically wrong like a program loop of some sorts. Could you recommend a solution if one has been found, or alternatively, the latest version of SheepShaver which does not show this behavior ? For the latter solution, I would also need to learn how to install SheepShaver. Would I be able to utilize some of the steps that the COI package has saved me, so as not to start from scratch ?
Thanks a lot for your kind attention
Vincenzo Daneu
Thanks a lot for your kind attention
Vincenzo Daneu
- Ronald P. Regensburg
- Expert User
- Posts: 7834
- Joined: Thu Feb 09, 2006 10:24 pm
- Location: Amsterdam, Netherlands
Re: CPU usage and eventual lockup issue(s)
Chubby Bunny COI uses an old build of SheepShaver. I do not know if it uses much more CPU than the more recent builds, could be. But unlike most other applications, SheepShaver does indeed use CPU time continuously. It is usually best to not let SheepShaver run when not used.
A regular SheepShaver setup is much more flexible than COI that does not allow any changes to its preconfigured settings.
Configuring SheepShaver is not very complicated, just follow the setup guide step by step. Use the new world rom that can be downloaded from the Redundant Robot site. If you have no MacOS install disk, you can use the OS9 system disk image that is present inside COI. Here is how to get it:
- Right-click (or control-click) on the 'COI (Classic-On-Intel) V4.0.1 "Chubby Bunny"' icon in the Finder.
- Choose "Show Package Contents" from the contextual menu.
..... You will now see a Finder window containing a file "COI" (which is really a package) and a folder "Contents".
- Launch Terminal (in /Applications/Utilities/).
- At the prompt in Terminal type and a space (do not forget the space and do not yet hit return!).
- Drag the COI icon from the Finder into the Terminal window.
..... The path to the COI package will appear after cd.
- With the Terminal window in front, hit return.
- Then, at the new prompt, type in Terminal: followed by a return.
..... A copy of the COI startup disk image will appear on your desktop with the name "MacOS9.dsk".
Note that, unlike an install CD image, that image should not be locked in the OSX Finder (see setup guide).
Before you launch SheepShaver the first time to start configuration, use the scripts that are included in the SheepShaver download to delete the prefs and nvram files. After you deleted those files, never launch COI again, because that will overwrite all your settings.
A regular SheepShaver setup is much more flexible than COI that does not allow any changes to its preconfigured settings.
Configuring SheepShaver is not very complicated, just follow the setup guide step by step. Use the new world rom that can be downloaded from the Redundant Robot site. If you have no MacOS install disk, you can use the OS9 system disk image that is present inside COI. Here is how to get it:
- Right-click (or control-click) on the 'COI (Classic-On-Intel) V4.0.1 "Chubby Bunny"' icon in the Finder.
- Choose "Show Package Contents" from the contextual menu.
..... You will now see a Finder window containing a file "COI" (which is really a package) and a folder "Contents".
- Launch Terminal (in /Applications/Utilities/).
- At the prompt in Terminal type
Code: Select all
cd
- Drag the COI icon from the Finder into the Terminal window.
..... The path to the COI package will appear after cd.
- With the Terminal window in front, hit return.
- Then, at the new prompt, type in Terminal:
Code: Select all
cp .Classic.dmg ~/Desktop/MacOS9.dsk
..... A copy of the COI startup disk image will appear on your desktop with the name "MacOS9.dsk".
Note that, unlike an install CD image, that image should not be locked in the OSX Finder (see setup guide).
Before you launch SheepShaver the first time to start configuration, use the scripts that are included in the SheepShaver download to delete the prefs and nvram files. After you deleted those files, never launch COI again, because that will overwrite all your settings.
Re: CPU usage and eventual lockup issue(s)
I don't find running SheepShaver continuously a problem, though I haven't checked the actual CPU figures. However, 'Shutting Down' SS with OS 8.6 is extremely fast, and relaunch is no slower than an average OS X application.