CPU usage and eventual lockup issue(s)

About SheepShaver, a PPC Mac emulator for Windows, MacOS X, and Linux that can run System 7.5.3 to MacOS 9.0.4.

Moderators: Cat_7, Ronald P. Regensburg, ClockWise

Post Reply
100Day
Student Driver
Posts: 11
Joined: Sat Jul 19, 2008 3:45 am
Location: Florida/Minnesota USA

CPU usage and eventual lockup issue(s)

Post by 100Day »

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.
Thomas J. Rostafinski
Student Driver
Posts: 16
Joined: Tue Apr 15, 2008 10:42 pm
Location: Chicago

CPU usage

Post by Thomas J. Rostafinski »

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.
100Day
Student Driver
Posts: 11
Joined: Sat Jul 19, 2008 3:45 am
Location: Florida/Minnesota USA

Post by 100Day »

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?)
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Post by Ronald P. Regensburg »

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.
deltacharlie
Space Cadet
Posts: 3
Joined: Tue Aug 12, 2008 12:06 pm
Location: Bordeaux

CPU usage

Post by deltacharlie »

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.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Post by Ronald P. Regensburg »

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.
kelvin31415
Tinkerer
Posts: 83
Joined: Sat Apr 12, 2008 8:22 pm

Post by kelvin31415 »

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.
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.

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.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Post by Ronald P. Regensburg »

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?
kelvin31415
Tinkerer
Posts: 83
Joined: Sat Apr 12, 2008 8:22 pm

Post by kelvin31415 »

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?
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.
kelvin31415
Tinkerer
Posts: 83
Joined: Sat Apr 12, 2008 8:22 pm

Post by kelvin31415 »

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.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Post by Ronald P. Regensburg »

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.
kelvin31415
Tinkerer
Posts: 83
Joined: Sat Apr 12, 2008 8:22 pm

Post by kelvin31415 »

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 feel the same way, even though I use the hardware cursor version.
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?
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: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.
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?
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Post by Cat_7 »

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
kelvin31415
Tinkerer
Posts: 83
Joined: Sat Apr 12, 2008 8:22 pm

Post by kelvin31415 »

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.
I believe that VOSF is the default, so if you are not configuring with --disable-vosf then your Windows version is probably using it.
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.
Did earlier versions not exhibit that problem, and if so, do you have any idea when the problem first showed up?
In conjunction with that, the OSX builds will not accept more then 512 Mb memory setting.
I will have a look at that when I have some free time, unless somebody beats me to it.
insanelol
Space Cadet
Posts: 1
Joined: Tue May 06, 2008 11:45 am

Post by insanelol »

I'm runnign the 21 July 2008 SheepShaver over a PowerBook G4 Titanium (1Ghz, 512Mb) running Leopard 10.5.5.

All is ok except the cpu usage. SheepShaver uses over 70% CPU all th time. Machine gets hotter and fun is always working.

Please, help with this. In this way SheepShaver is unusable.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Post by Ronald P. Regensburg »

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.
legacy
Space Cadet
Posts: 1
Joined: Sun Feb 14, 2016 4:14 pm

Re: CPU usage and eventual lockup issue(s)

Post by legacy »

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
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Re: CPU usage and eventual lockup issue(s)

Post by Ronald P. Regensburg »

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

Code: Select all

cd
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:

Code: Select all

cp .Classic.dmg ~/Desktop/MacOS9.dsk
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.
TiddK
Granny Smith
Posts: 106
Joined: Wed Jan 27, 2016 12:25 pm

Re: CPU usage and eventual lockup issue(s)

Post by TiddK »

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.
Post Reply