multi-tasking interference?
26 Apr 2007 4:53:15 UTC
Topic 192627
(moderation:
Currently running the 32-bit boinc client 5.9.4 in the 64-bit Ubuntu 7.04 operating system on a 64-bit AMD multi-core computer. Prior to the latest Einstein WUs, I have had no problems with work for the BOINC environment.
The last five WUs downloaded from Einstein have all terminated abnormally. I can't prove it, but as long as there was only a single Einstein WU executing, it seemed to have no problems. But when I clicked on 'Update' (for Einstein) in boincmgr, that running Einstein WU crashed. And when the system later on dispatched three Einstein WUs simultaneously (using three CPUs), my display became slow-to-respond to cursor movements, page thrashing started, and the whole system froze shortly thereafter (reboot needed).
I have *never* previously had this system freeze on me. My suspicion is that having multiple Einstein processes executing concurrently caused them somehow to interfere with each other.
--------
Seeing that Einstein work does not currently finish correctly on my system, I'm going to wait until a new application version is available before trying Einstein work again.
.
multi-tasking interference?
)
Your problem seems to have started with S5R2c, the S5R2a WUs worked.
You're not alone ;-)
You might find that if you
)
You might find that if you slowed the CPU frequency down, it would resolve your problem.
RE: You might find that if
)
Sorry - this system is not overclocked. If there are applications that have trouble running at my system's designed speed, it is easier for me to not run those applications, than to "slow down" all the other work this system is doing. [When I've run torture tests of various kinds, none of them have had problems.]
.
Disabling Cool'n'Quiet has
)
Disabling Cool'n'Quiet has helped for many X2 users with many kinds of weird problems. C'n'Q will not save you any power on a cruncher rig anyway.
Team Philippines
RE: Disabling Cool'n'Quiet
)
The problem of crashed when the science client is suspended (e.g. for an Update, manually or automatically) seems to be widespread , see http://einsteinathome.org/node/192613
I doubt it has anything to do with overclocking or power-saving modes. It indeed seems to be rather a software bug in the science client.
CU
BRM
RE: RE: Disabling
)
My Slackware 11 box running on an old Athlon 1200 has had 2 different workunits crash right after I did a manual update to report a completed result. This has something to do with the BOINC update function, or something that the currently running science app does when BOINC issues an update. 83548425 and 83633194 died immediately after I issued a manual update. I did this fairly soon after the new workunit started. I'm wondering if the science app is assuming that a checkpoint exists, but doesn't have one this soon into the processing. None of the rest of my systems, which are all Windows machines, have had any issues yet.