I've tried to use this method to move my data folder in both Snow Leopard and Lion, for some reason I am unable to get it to work.

I just now tested this under both Snow Leopard and Lion, and it worked perfectly for me. Make sure you quit BOINC before doing the procedure.

Please describe the problem in detail. When you say it doesn't work, what exactly happens? Do you get an error message? Do you see the folder icon with the small arrow and the name BOINC Data in the /Library/Application Data/ folder (this is the symbolic link you should have created)? Also, please copy the full transcript from the Terminal window into your reply message so we can see exactly what you are doing.

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

On a MBP with integrated and discrete graphics, BOINC always causes a switch to discrete graphics. I don't have CUDA installed (any more) so it can't be using the GPU for tasks.

Using gfxCardStatus (http://codykrieger.com/gfxCardStatus) one can tell that boinc is the only dependency causing the GPU switch. Even with boinc set not to run on battery power, it still causes the discrete battery-sucking GPU to be on.

I would like for boinc to be happy running on the integrated GPU. (I'm using boinc 7.0.28)

On a MBP with integrated and discrete graphics, BOINC always causes a switch to discrete graphics. I don't have CUDA installed (any more) so it can't be using the GPU for tasks.

CUDA does not need to be installed to use the GPU via OpenCL. OpenCL is built into the Mac OS. When BOINC is launched, it uses OpenCL to detect the presence of usable GPUs, and I suspect that is probably triggering the switch. Once BOINC has started up, you might be able to switch it back (using gfxCardStatus) if no tasks use openCL.

I don't have access to a dual-GPU MacBook, so please let me know if this works for you.

If you don't want BOINC to run tasks which use the GPU, you can use the 1 tag as described here.

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

Ah, great, the no_gpus option did the trick.

Not ideal I suppose - when plugged into power, I'd be happy for boinc to use the GPUs. But this is better - at least my batteries are being drained all the time, even while I'm working on something and boinc is idle!

For anyone else wanting to do this, I had to create /Library/Application Support/BOINC Data/cc_config.xml:

<cc_config>
    <options>
        <no_gpus>1</no_gpus>
    </options>
</cc_config>

Thanks for the help.

Ah, great, the no_gpus option did the trick.

Not ideal I suppose - when plugged into power, I'd be happy for boinc to use the GPUs. But this is better - at least my batteries are being drained all the time, even while I'm working on something and boinc is idle!

This makes me think the problem was not with BOINC testing for the presence of the GPU when BOINC is first launched, but rather with a project application doing GPU computation. Perhaps when you switch to battery power, the project application suspends but is still in memory? Do you have your computing preferences set to "leave applications in memory while suspended"? If so, try turning that off.

Please let me know if that takes care of your problem and allows you to eliminate the flag.

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

When running four MacBook Air CPUs at 25% time (to keep them all cool and the fan off), they tend to run simultaneously, such that, e.g., every four seconds they all take one second from other processes, then are quiet for three seconds.

Can you make them run round robin instead, spreading out the load over the four seconds?

I'm in the process of upgrading our Mac labs to OS 10.8. I'm running BOINC 7.0.31 (GUI) to go with the upgrade.

While the log says BOINC is running as a daemon, no work is being done. Apple is notorious for tinkering under the OS hood without telling folks, so I'm wondering if there's a need for a new daemon script.

Seems to me the same kind of thing happened when things switched to launchd.

My suggestion is to be allowed to choose a different data folder installation path when installing BOINC. With SSDs becoming more common, I think many people (like me) would like the option of installing the BOINC data folder on a different drive to reduce wear on the limited lifespan of the SSD boot drive.

See http://boinc.berkeley.edu/wiki/Tools_for_Mac_OS_X#Moving_BOINC_Manager_or_BOINC_Data_Folder_to_a_Different_Drive, although this method is for advanced users.

I'm in the process of upgrading our Mac labs to OS 10.8. I'm running BOINC 7.0.31 (GUI) to go with the upgrade.
While the log says BOINC is running as a daemon, no work is being done. Apple is notorious for tinkering under the OS hood without telling folks, so I'm wondering if there's a need for a new daemon script

I just now tested it pretty thoroughly with BOINC 7.0.31 on OS 10.8, and the same old script works perfectly for me. You might want to check your BOINC Computing Preferences.

Cheers,
--Charlie

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

Hmmmmm.... I'm using the same settings I used with 10.6.8--and 10.7.x for that matter--where things worked swimmingly for lo these many years.

That was BOINC 6.10.58. An added wrinkle is that because we Deep Freeze our lab Macs I moved the data folder to another partition so that work could be done between classes without thawing them.

Another wrinkle is that I had to do a "dirty" install of 10.8 over 10.6. Maybe that's the problem.

I appreciate your efforts in all this.

Another wrinkle is that I had to do a "dirty" install of 10.8 over 10.6. Maybe that's the problem.

Remember that, since you are relocating the BOINC Data directory, you must create the symbolic link again each time you run the BOINC installer, as explained at the end of this section. This may also apply when upgrading the OS.

When all else fails, I recommend running the Uninstall BOINC application that comes bundled with BOINC 7.0.31 for the Mac and then reinstalling.

---

Charlie Fenton
BOINC / SETI@home Macintosh & Windows Programmer

Another wrinkle is that I had to do a "dirty" install of 10.8 over 10.6. Maybe that's the problem.

Remember that, since you are relocating the BOINC Data directory, you must create the symbolic link again each time you run the BOINC installer, as explained at the end of this section. This may also apply when upgrading the OS.

When all else fails, I recommend running the Uninstall BOINC application that comes bundled with BOINC 7.0.31 for the Mac and then reinstalling.

I moved the data folder as the very last step. I deployed 20 machines. 19 of them are, in theory, exact clones of one machine (target disk mode is wonderful when one has an unreliable network that doesn't support netbooting). I used to expect that clones would behave the same, but they don't.

Two of the 20 are behaving properly regarding BOINC. The other 18? Only FSM knows for sure why things don't work. I've never had good luck uninstalling and re-installing. I end up cloning from another machine, so that's pretty much where I start these days. When we used Radmind, we didn't have these problems. But my Radmind expert left...

Turns out I've got to redo the machines with a clean install of 10.8, so I'll let you know.

Hi all - I am parachuting in here - apols if I am in any way off topic. MacOS 10.6.8. BOINC 7.0.31. Set@home.

I have had a thread going over at "Number crunching : Waiting for more tasks ..." for several weeks trying to solve my screensaver issues.

However I am posting here to say how appalled I am at the whole design/development of the Mac App. The interface is something you might expect in a college engineering course project.

The interface is completely submerged in unintelligible tech terms and unintelligible preferences and options that compete between those set in the app and those set on the web.

It would appear as if the BOINC and Seti teams are doing their utmost to frighten off the global public, in order to leave the whole Seti etc projects to the nerds and techies.

I do know that there is limited money available and it is a volunteer project. I do know that guys. But what is the goal here ? Surely the goal is to involve as many people as possible ?

I am so so exasperated listening to people I discuss this project with telling me they have abandoned it after a few days of trying to wrestle with the app. I myself am totally tired of it. I abandoned it several years ago for the same reason and thought that in nearly TEN YEARS someone would have made an effort to make this easy to use ?

Please !!!

Turns out I've got to redo the machines with a clean install of 10.8, so I'll let you know.

It was a user permissions issue. Resetting user permissions on the admin account (which is *supposed* to be the only BOINC user) set the BOINC daemon free.

Ok, you kids will think I'm nuts, but here's what's on my wishlist for Mac:

I'd like to see versions for legacy systems. Back in the day I was running SETI@Home on a Powerbook G3 Wallstreet running 8.6. I'd love to have a way to get that baby running Boinc. I also have a Mac Classic II running 7.0.1 on my network too. How cool would THAT be? I can run BOINC on a Windows 95 system, (ahem, and I have) why not on an old Mac?

I'm sure it's a waste of valuable resources to develop it, but it would be a neat way to use old computing resources. The small amount of computing power afforded by these old beasts would be more than compensated by the romance of it all, don'tcha think?

:)

I'd like to see Retina support and also a more Mac-like interface for the GUI manager.

also a more Mac-like interface for the GUI manager.

BOINC is a platform neutral package, meaning that from one source code you'll be able to compile the Windows, Linux and Macintosh version and they'll all look and feel the same. You can easily switch between platforms and know where the thing is that you're looking for.

If it has to have Windows looks for Windows, special Linux looks per distro of Linux and a special Mac look for the Mac, it's impossible to use one source code for all.

It would then also need a production team not unlike Google has walking around.
However, BOINC is really just 3 people who work at it full-time, while the rest is volunteers.

Something I just noticed, like 20 minutes ago, I installed a program called gfxCardStatus which displays which GPU is in use & programs dependent on it. I then started playing with the power connector to see what happens when going onto battery.

The GPU did not switch to the internal HD3000 chip an boinc was listed as the blocking program, on shutting boinc down the GPU switch after a few seconds.

My normal configuration allows computing while on AC power only in the expectation that when on batteries the program will not draw down battery life; clearly by locking the high performance graphics card this is not the case. I'm only getting about 3-4hrs best case on battery.

It would be nice if on detecting an "on batteries" condition if boinc (client/manager as appropriate) could fire up a lightweight daemon that simply monitors the power source and then cleanly exits. This would allow the system (MBP Early 2011 ML 10.8.2) to switch the graphics card for better battery life. The daemon would on detecting AC Power would relaunch the (client/manager as appropriate) to resume normal processing and thus keep this user reasonably happy.

Thanks

Ray

Another Thought,

It would be nice to have more control over the scheduling of work; my personal MAC tends to sit awake (for boinc) during the day while I'm at work, in the evening my usage varies from light web surfing to heavy Java development.

I'd like to be a say something like between 0900 and 1800 run on 100% of cpus at max of 100% cpu time and then between 1800 and 0100 run on 50% of cpus at a max of 50% cpu time and then between 0100 and 0700 run on 75% of cpus for a max of 50% of cpu time (this is when virus scans and disk main runs) and don't run in unspecified periods. Ability to control the GPU usage during the scheduled times would be critical to optimizing boinc computational cycles.

The schedule for my work Mac would, to a degree be a partial mirror image of the above.

I simply don't have the time (or inclination) to constantly retune boinc to my current workload, the above extension of the scheduling mechanism would serve to maximize (albeit course grained) the cycles I donate to boinc with minimal effort on my part.

I suggest either a fixed 24 1 hour, or an unbounded number of slots for this; for each slot the ability to control run/not, gnu/not, cpu/not, run on battery/not, after idle for, cpu%<, %cpus %cpu time, each schedule should have a block of 7 day of week checkboxes.