Being careful about development BOINC versions is a healthy attitude, I understand your reluctance. I have used two of the 7.0.xx versions due to POEM OpenCL requirements so am a bit more comfortable now about using development versions to overcome specific problems. The very unstable versions with severe problems are usually quickly removed from the list of downloadable versions.

MB Atlanos is using 6.10.43 on a number of different projects on a Core2 Duo with Darwin 10.8.0. Also Cap is using 6.12.41 on a 24 core Xeon X5650 with Darwin 10.8.0.

Just because it doesn't become the recommended version doesn't necessarily mean a development version has problems. It can be that the improvements/changes are only minor or only needed by a relatively small number of users, so the recommended version is not changed. If the recommended version is changed to suit a very small number of users then the number of problems caused by a large number of people updating to the new recommended BOINC version outweighs the benefit of the fixes for the few. This is possibly why the recommended version is not changed very often.

The last few 6.12.xx development versions had more limited testing than usual as resources were moved to developing 6.13.xx versions. Many of the changes in 6.12.xx versions after 6.12.36 related to virtual machine issues related to Test for Theory.

I think 6.12.43 was the last of the older kind similar to the current release version. As far as I know the new 7.0.xx type with the new scheduling code started at 6.13.0.

....And, finally, for the time being I'll just clear MWAH/BOINC with a daily restart to keep the issue at bay until I'm ready to devote some time to chasing BOINC v.7 glitches!....

Not going to try 6.12.41 or 6.12.43 from my second link? Perhaps the best option if you don't mind restarting every day. Who knows if those versions have something else that could cause a problem.

I would never have found the reference to the fix if you hadn't found the first ticket reference from scasady..

"fixed in 6.12.41"

http://boinc.berkeley.edu/trac/ticket/1144#comment:1

http://boinc.berkeley.edu/dl/?C=M;O=D

Ticket #1144 (closed Defect: fixed)

Opened 5 months ago

Last modified 5 months ago
6.12.35 on OS X 10.6.8 is leaking file descriptors
Reported by: scasady Owned by:
Priority: Undetermined Milestone: Undetermined
Component: Undetermined Version: 6.12.35
Keywords: Cc:
Description

The file descriptor acquired to open a slot directory is not always closed. They slowly accumulate until the boinc client exits or in some cases hangs.
Change History
comment:1 Changed 5 months ago by scasady

Status changed from new to closed
Resolution set to fixed

fixed in 6.12.41

I would not process separation tasks on a CPU myself because I feel CPU resources are more efficiently used to do nbody tasks or other CPU projects. I don't see the point in taking 2 hours on a CPU core for a task that can be done in under a minute on the last three generations of ATI/AMD cards.

Feb 23 21:26:30 imac /Applications/BOINCManager.app/Contents/Resources/boinc[151]: dnssd_clientstub deliver_request: socketpair failed 24 (Too many open files)
Feb 23 21:26:30: --- last message repeated 499 times ---
Feb 23 21:26:30 imac /Applications/BOINCManager.app/Contents/Resources/boinc[151]: *** process 151 exceeded 500 log message per second limit - remaining messages this second discarded ***

BOINC freezing isn't really something milkyway can do. Can you try using the sample process thing in Activity Monitor on the boinc processes when it does happen (it's there on Lion)?

A search in the BOINC forum brought this:

3) Diskussionsforen : Questions and problems : (Waiting on GPU) Returns!...Repeatable on demand! (Message 42273)
Posted 22 days ago by Charlie Fenton Thanks for your offers of help. We don't need any more information regarding the "waiting for gpu memory" issue; we are well aware of that. It means just what it says: there is not enough free memory in your gpu to run the task. If you want to get more information, set the coproc_debug flag in your cc_config.xml file as explained here.

Unfortunately, due to a bug in some drivers, BOINC currently cannot check available gpu RAM periodically, so the check is made only when you launch BOINC. That means that if more gpu RAM becomes available after BOINC starts, BOINC does not know about it. We are working on this problem.

My concerns are the several other issues you have raised, such as the md5 errors, spontaneous restarts, etc.

Waiting to run (waiting for GPU memory)

I haven't experienced this myself but I've read you need to do a system reboot to clear the GPU memory.

FWIW, OSX 10.6.8 Boinc 6.12.35 MWAH 1.00...

Received 7 1.00 WUs, processing normally (4 completed as of now). MWAH will not send any work either automatically or via manual update. Server status indicates everything functioning normally...

Any clues as to why no work issuance?

:)

And, now all WUs complete, task queue empty & computer idle, log says, "Project has no tasks available", server status as of 2:18:32 UTC, "Tasks ready to send 1,980" and "MilkyWay@Home unsent 1,759 MilkyWay@Home N-Body Simulation unsent 221"

???

FWIW, OSX 10.6.8 Boinc 6.12.35 MWAH 1.00...

Received 7 1.00 WUs, processing normally (4 completed as of now). MWAH will not send any work either automatically or via manual update. Server status indicates everything functioning normally...

Any clues as to why no work issuance?

:)