Rickjb are you running multiple CEP2 workunits on this computer when you have the issue?

Thanks,
armstrdj

Can you run it in AHCI mode? I think it will be a lot happier with the writes, even if it means that you have to put everything on a single drive. Perhaps even more importantly, the write cache on a 8.4 GB drive can't be very large. I would use a later-generation drive for the OS and page file anyway.

Are you running with the BM always loaded? Yes, large caches are known to cause substantial delay in the CC/BM exchange, particular if the BM is up. For that reason the button in the task view was created to only show active tasks. Even when the BM is not loaded and hundreds of tasks are in cache the CC has to work harder.

--//--

Propose you exit the BM **, this removing one more vector on holding anything up if it would. In the status bar it still fetches the CC state every other second. Some have observed a memory leaking and the BM/CC bloating ever bigger. Just looked on the Linux box, it takes 328.5Mb VM, 10MB RAM. Even when minimized it takes 1/100 of a second every few second. So, I look in, then exit it routinely.

** If BOINC is installed as user, the core client might exit too. The GPU crunchers would know since they have to install on Windows without PAE.

Just lose thoughts to steel more microseconds.

--//--

"No heartbeat from core client for 30 sec - exiting" + "exited with zero status but no 'finished' file" : Problem solved!
Cause: Poor performance of hard disk containing the BOINC data. Solution: Replace drive with one of a "better" model.

I have solved my problem of WUs exiting with zero status and restarting from their last checkpoint, that I described in my long post earlier in this thread.
The drive containing the BOINC DATA was a Western Digital "Caviar Green" Model WD5000AADS-00S9B0 500GB SATA drive which has 32MB cache, and I replaced it with an older Samsung SP2014N 200GB IDE unit having 8MB of onboard cache.
The WD drive passes the WD diagnostics with a clean bill of health, so the problem is with the drive model rather than my particular unit.
As stated above, another of my machines runs happily with a similar WD drive with the same firmware version number, but with 750GB capacity and only 16MB of cache.
With its IDE interface, the raw I/O speed of the Samsung drive is probably slower than the WD's SATA interface, especially when the WD is in AHCI Mode. The latency of the 5400rpm WD may however be greater than for the 7200rpm Samsung, due to its slower rotation and perhaps slower track-to-track seek times, which are compromises made by WD to reduce power consumption. The way that the WD's firmware handles its large onboard cache may also cause delays. Or, the WD may be holding a system bus for long periods while it is performing DMA activity, freezing out the CPU.

With the Samsung drive, there are still times when the HDD LED comes on and CPU usage falls to zero, but these are for much shorter periods than before, and no WUs have timed out, even when running 4 CEP2 WUs simultaneously. Also, the running of other tasks that are not requesting large amounts of disk I/O seems to be hardly affected, whereas before the computer would almost freeze.

Note that it is the drive that contains the BOINC data that causes the problem, not the drive containing the system, pagefile or BOINC program files. My Samsung with the BOINC data is currently the 2nd drive, and all of the intense HDD activity is on this, not the system drive.

I repeat my suggestion above that if you are experiencing the problems that I have described, please post details of the drive that contains your BOINC DATA.

Also, if you have a "green" or "eco" low-power drive that contains your BOINC data and runs CEP2 without problems, you might post the details of that too.