Tag Archives: rosettaathome

MalariaControl and Rosetta@Home

The first one is working OK, except for there is no graphics. But the WU are being submitted, validated and accepted.

Now, Rosetta@Home seems to have a bug o some sort, which makes the client detach every time Rosetta gets a work unit. Maybe you need to suspend all other work units first. I’ll try it.


BOINC projects using 100% of CPU on FreeBSD

uFluids doesn’t send to my platform. Quantum Monte Carlo does. And I’ve decided to give Rosetta@Home one more shot.

Reason? Oh, the reason is great news.

As I’ve written before, some projects somehow take up 100% of processor time, even though the settings unambiguously specify 50%. The reason for this, as I have accidentally found out by fooling around with Wine-emulated BOINC, is idprio.

Idle-time priority is being set to 31 in the /usr/local/etc/rc.d/boinc script. To a logical mind, this would mean that BOINC would only run its 50% share in the idlest of time, when no other process wants it. In reality, BOINC projects get 100% of idle time.

I guess this might be related to the fact that BOINC projects are run as separate threads. On the other hand, this might just be an idprio issue.

Right now, QMC@Home is running with priority nice 19, which it set by itself. The “Show graphics” button doesn’t do anything, probably graphics aren’t installed properly in my system.

It will take 150 hours to finish this workunit. I’d rather test result compatibility on a faster project.


Well, Rosetta@Home seems to keep exceeding the disk limit. I’ve noticed it dumps a 200 Mb .core file on exit, wonder if it’s related.

Besides, it uses 100% of available processor power, while my setting is 60%. (It does run under i31 priority, though.)

So I’ve dumped the idea of running it on FreeBSD, and have switched to WCG.

Update on Rosetta@Home workunits

So far, the Rosetta@Home workunits I’ve mentioned before have all failed due to exceeding their allowed disk limit. According to the BOINC error message reference, this might be “caused by the error log growing out of control”. I’ll look into it as soon as I get back on FreeBSD.