I have just downloaded Rosetta due to my frustration with ClimatePrediction, which restarted over 20 times since the first of the year.

Are there any things I need to look out for, such as restarting, or other problems?

LastPlace

Intel 3.0
ASUS P4P800 Deluxe
1Gb RAM
XP Home

---

The problems with your machine may or may not affect Rosetta too.

If you also see -107... errors here, then you really will need to sort out your graphics drivers as I already suggested. If you're lucky, the recent decoupling of the graphics from the science thread may prevent the -107... errors escalating (v5.16?).

However, the shorter work units will help. If one work unit fails every 300 hours, that's not a big deal here, but if you have a failure once per 300 hours at CPDN that's a disaster unless you take a few minutes to make backups.

---

3ghz! You're NOT "last place" here! Welcome!

The main thing you will want to consider is how long you would like to crunch each work unit. You've presently downloaded quite a number of them, so you won't want to make extreme changes. But you can adjust your preferred WU runtime in your Rosetta preferences.

Once you alter it, and update to the project, your existing cache of WUs will be altered. So, be careful not to jump to extremes. But the current recommendation from the project is to run an 8 hour runtime (I know, I know... then why don't they make THAT the default? Sorry, I can't answer for that one). I much prefer the 24hr runtime. Why do more downloads than necessary. The project gets the science results from the TIME we all spend crunching (actually the number of "models" crunched), not the number of WUs. So, why download more? ...but don't jump straight to 8 or 24, because it will adjust all your existing WUs to that runtime, and yet BOINC won't figure that out until you crunch a few at the longer time and update to the project. So, BOINC will basically download too much work. If you have 8 WUs already and then jump to a 24 hr setting, it will take you longer than the 7 day deadline that exists on most WUs presently to crunch them all. OK OK you've got a duel core, but you get the idea.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

Actually, as I understand it, if the actual crunch time is longer then what BOINC expects, it immediately places the higher value in place, but if it's less, it chops 10% off the expected crunch time or something till it "gets it right". For instance I was doing a bunch of LHC WUs there while they had work, and some were really short WUs where the beam was off or something and caused an early WU completion (yeah, the other crunchers got the same thing, and they did validate, just with smaller credit). Each of those resulted in a nudging down of the expected crunch time. However, one standard sized unit that went the whole 1 million turns, and the expected time was instantly set to crunch time on that WU...

This said, increasing it too much could easily result in the computer entering into panic EDF mode, as it thinks it's over-committed. So yes, caution is needed.

There is one thing to add here however. The flip side to a larger target CPU time meaning you download fewer WUs, is that if you are having problems (as you stated you were having with CPDN), the longer a WU runs, the higher the liklihood it will crop up. In that sense, you might want to lower the target CPU time if you need to get some WUs to successful completion. If it's 300 hours you were failing at CPDN this might not matter. If you were failing within 24 hours each time, then setting a 24 hour target CPU time might be risky.

For starts, you might want to try setting this below whatever point you were getting failures on other projects to try to make sure you get some successful runs. You can try uping this gradually then, to see if the same problems replicate or not. If you're set to an 8 hour run time, and find WUs failing at 7.5 hours (rather consistently) on your machine, then you might want to bump this back down to 6 hours so they'll get some models. We still haven't established (unless there's something I'm missing from the CPDN board in your case), why your machine was having all these errors.

---

Are there any things I need to look out for, such as restarting, or other problems?

Bad hardware or overclocked hardware.

I found I had a disk problem becsuse CPDN started restarting - fixed it, has worked fine since. Having read literally dozens of other threads like this around, an overclocked system frequently throws these errors. It may seem stable to a casual test, but in the longer run, is a waste of time.

---

Wave upon wave of demented avengers march cheerfully out of obscurity into the dream.

Prime95's torture test (www.mersenne.org) is a good test for overclocked machines, if it runs for 24 hours withut error then CPDN will probably also run OK. Note that you'd need to run two copies (one per each core).

Rosetta will be more forgiving than CPDN about 'borderline' overclocked machines, but still it's always better to get your machine fully stable.

If you're overclocking via AIBooster, this doesn't give particularly good or stable results since it overclocks everything without regard to testing. I personally prefer overclocking manually - the end result is both much faster and more stable.

---