Please post any problems with rosetta 5.89 here. Thanks!

---

I only joined Rosetta today. I have been running seti since '99. When BOINC started on the Rosetta program I got the following error message "Windows Runtime C++ error, can't run program ...rosetta_beta_5.89_windows_intelx86.exe". I'm running Windows XP with BOINC 5.10.28. No problems running seti.

Welcome David. Your computers are hidden. Any chance you are running an ancient version of BOINC?

---

Rosetta Moderator: Mod.Sense

Please post any problems with rosetta 5.89 here. Thanks!

Why is Rosetta running 5.89 if it is still under test at Ralph?

Ralph is used to test new releases, and new work units. The changes between 5.88 and 5.89 were minor and have both been tested on Ralph prior to the release of 5.89 on Rosetta. When new work units are created, they will be run on Ralph with the appropriate Rosetta version. So you may see work on Ralph 3 weeks from now using v5.89. It doesn't mean that 5.89 has not completed it's testing there.

---

Rosetta Moderator: Mod.Sense

Ralph is used to test new releases, and new work units. The changes between 5.88 and 5.89 were minor and have both been tested on Ralph prior to the release of 5.89 on Rosetta. When new work units are created, they will be run on Ralph with the appropriate Rosetta version. So you may see work on Ralph 3 weeks from now using v5.89. It doesn't mean that 5.89 has not completed it's testing there.

So this was one of those one day tests again, I see. Released on ralph on the 12th, and released here on the 13th.

Ludicrous to call that "testing".

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

Please post any problems with rosetta 5.89 here. Thanks!

So how does this version address the fact that the project doesn't function on machines with 256mb of memory, which is what your "System Requirements" page suggests?

So this was one of those one day tests again, I see. Released on ralph on the 12th, and released here on the 13th.

Ludicrous to call that "testing".

I have one system participating in Ralph and it received the first 5.89 workunit late on the 14th. This machine had gotten 'no work from project' from Ralph since the 12th.

That very same server also participates in Rosetta and received the first 5.89 workunit already on the 13th!

I think I agree with the 'ludicrous' sentiment. I find it unacceptable to experience problems in Rosetta that proper testing in Ralph could have avoided.

---

Team Helix

Please post any problems with rosetta 5.89 here. Thanks!

So how does this version address the fact that the project doesn't function on machines with 256mb of memory, which is what your "System Requirements" page suggests?

Your statement is incorrect. The project runs on machines with 256MB of memory and the base system requirements have not changed. There are still tasks available for such systems.

Having said that, there are some people seeing large virtual memory requirements (which not specifically defined on the requirements page). Which BOINC should have detected and handled, but apparently did not. Which is why we have a thread such as this, to explain such observations that cannot be seen from the returning results.

The difference in memory requirements is due to the task being performed... not the specific version of Rosetta.

---

Rosetta Moderator: Mod.Sense

Ver. 5.89 seems to be better than the disastrous 5.85 but I'm still seeing very large memory requirements: right now the 2 Rosetta tasks I can run are taking up 220MB of memory between them, and the virtual machine sizes are respectively 426MB and 398MB. This makes me just a tad nervous although Win Task Manager shows memory use more moderate than it has been: peak memory is about 130MB.

What I'm concerned about is that my machine over the last few weeks has taken to suddenly slowing to a standstill, and when I check the task manager, I see huge memory figures for the Rosetta tasks. I'm considering reducing the memory allocation from 50% during machine use to 40% - would this impact my ability to run the tasks on a 1 GB machine??

---

--hedera

Never be afraid to try something new. Remember that amateurs built the ark. Professionals built the Titanic.

Welcome David. Your computers are hidden. Any chance you are running an ancient version of BOINC?

No I don't think so. 5.10.28 is pretty recent.

Please post any problems with rosetta 5.89 here. Thanks!

So how does this version address the fact that the project doesn't function on machines with 256mb of memory, which is what your "System Requirements" page suggests?

Your statement is incorrect. The project runs on machines with 256MB of memory and the base system requirements have not changed. There are still tasks available for such systems.

Having said that, there are some people seeing large virtual memory requirements (which not specifically defined on the requirements page). Which BOINC should have detected and handled, but apparently did not. Which is why we have a thread such as this, to explain such observations that cannot be seen from the returning results.

The difference in memory requirements is due to the task being performed... not the specific version of Rosetta.

You say the requirements haven't changed, but after the crash of a few weeks back, both of my 512mb machines stopped getting work because it said I didn't have enough memory. Once it got a work unit, it stopped after a while with a "waiting for memory" status. I look at the team stats for Primary Schools and see that RAC for everyone has dropped to the point that there is almost no activity. My guess is there IS no activity because of the memory requirements.

So this was one of those one day tests again, I see. Released on ralph on the 12th, and released here on the 13th.

Ludicrous to call that "testing".

I have one system participating in Ralph and it received the first 5.89 workunit late on the 14th. This machine had gotten 'no work from project' from Ralph since the 12th.

That very same server also participates in Rosetta and received the first 5.89 workunit already on the 13th!

I think I agree with the 'ludicrous' sentiment. I find it unacceptable to experience problems in Rosetta that proper testing in Ralph could have avoided.

It appears that "testing" here is defined as: "The application compiles, and someone was able to struggle through at least one WU. Let's throw it over on Rosetta and see what breaks."

---

Proudly Banned from Predictator@Home and now Cosmology@home as well. Added SETI to the list today. Temporary ban only - so need to work harder :)



"You can't fix stupid" (Ron White)

So this was one of those one day tests again, I see. Released on ralph on the 12th, and released here on the 13th.

Ludicrous to call that "testing".

I have one system participating in Ralph and it received the first 5.89 workunit late on the 14th. This machine had gotten 'no work from project' from Ralph since the 12th.

That very same server also participates in Rosetta and received the first 5.89 workunit already on the 13th!

I think I agree with the 'ludicrous' sentiment. I find it unacceptable to experience problems in Rosetta that proper testing in Ralph could have avoided.

It appears that "testing" here is defined as: "The application compiles, and someone was able to struggle through at least one WU. Let's throw it over on Rosetta and see what breaks."

thought that was ralph's job not rosie's, or else someone slipped him a mickey
i'm still days away from any 5.89 stuff and now i wonder if it will work or not on my minimal memory system.

---

You say the requirements haven't changed, but after the crash of a few weeks back, both of my 512mb machines stopped getting work because it said I didn't have enough memory. Once it got a work unit, it stopped after a while with a "waiting for memory" status. I look at the team stats for Primary Schools and see that RAC for everyone has dropped to the point that there is almost no activity. My guess is there IS no activity because of the memory requirements.

After an outage, it is normal for project servers to be overloaded trying to deliver work to everyone at once. BOINC's project code doesn't handle the different types of WUs very well and it becomes possible for the "short list" of available work to become depleted of "regular memory" work units. Possible, especially when under the stress of getting back up and running. This is why there was a period of time when you did not receive work. It was a very short-lived problem.

If your work was waiting for memory then BOINC is working trying to enforce your memory preferences as it runs. Others are saying it ignores these preferences. It has always been the case that some types of work use more memory then others, and some take longer to run then others. It has little to do with one Rosetta version over another.

I know the large WUs and large virtual memory requirements are causing some problems for some machines. But, rest assured, overall the results are looking good. I typically review the credit granted last 24hrs on the homepage. It has been near 60Tflops for some time now. Here is a chart. You can see the blimp when the server recovered from the outage and this throws off the scale, but the memory problems seem to be fairly limited in scope. Not that they are unimportant, but they are not as widespread as you fear.

---

Rosetta Moderator: Mod.Sense

It appears that "testing" here is defined as: "The application compiles, and someone was able to struggle through at least one WU. Let's throw it over on Rosetta and see what breaks."

Gee is this normal here in Rosetta? Things are much more polite in Seti.

Dealing with a memory hog on the WU I am running.

---

Gee is this normal here in Rosetta? Things are much more polite in Seti.

I'm not sure what it is that you are considering impolite:
- Developers pushing insufficiently tested applications into the main project Rosetta without giving it enough exposure in the test project Ralph ?
- Project participants complaining about the insufficient testing ?

Mind you, I haven't seen anything yet that indicates that there are problems with 5.89. It is just that those quick releases without proper testing have caused problems before.

---

Team Helix

You say the requirements haven't changed, but after the crash of a few weeks back, both of my 512mb machines stopped getting work because it said I didn't have enough memory. Once it got a work unit, it stopped after a while with a "waiting for memory" status. I look at the team stats for Primary Schools and see that RAC for everyone has dropped to the point that there is almost no activity. My guess is there IS no activity because of the memory requirements.

After an outage, it is normal for project servers to be overloaded trying to deliver work to everyone at once. BOINC's project code doesn't handle the different types of WUs very well and it becomes possible for the "short list" of available work to become depleted of "regular memory" work units. Possible, especially when under the stress of getting back up and running. This is why there was a period of time when you did not receive work. It was a very short-lived problem.

If your work was waiting for memory then BOINC is working trying to enforce your memory preferences as it runs. Others are saying it ignores these preferences. It has always been the case that some types of work use more memory then others, and some take longer to run then others. It has little to do with one Rosetta version over another.

I know the large WUs and large virtual memory requirements are causing some problems for some machines. But, rest assured, overall the results are looking good. I typically review the credit granted last 24hrs on the homepage. It has been near 60Tflops for some time now. Here is a chart. You can see the blimp when the server recovered from the outage and this throws off the scale, but the memory problems seem to be fairly limited in scope. Not that they are unimportant, but they are not as widespread as you fear.

I've been doing @home projects since 1999, so I'm used to crashes,and outages, and I get upset when something I do to my computers causes my crunching @home projects to stop. Since the two computers involved have had no changes since the last BOINC update to 5.10.28, my two other computers that are running that version have no problems with their projects (SETI, Einstein) and another computer doing ABC@home is also fine, I will assume that BOINC is not the problem. All four of these units were at one time doing four projects, and having no troubles. When the Einstein work units started taking close to a hundred hours per unit on the two slowest 512mb machines, one 1.2g AMD, one 2.4g Intel, I started dedicating each computer to a project and telling each which project not to get new work from.
The two slower machines finally finished their Rosetta units and each had several "Ready to report" units just sitting there.... for days. Finally I guess somebody realized something was broken, and the units were reported. Then, no new work because the "project is down". Then no work for several days because of lack of memory. Then finally a work unit that just stops with "waiting for memory". Now I really don't care what version of the program you're up to and unless it is automatically sent to me, the only thing I keep updated is BOINC, and I don't twiddle around with BOINC settings. Mine have been the same since I started.
If you guys want everyone to upgrade to supercomputers just so they can handle your project in their spare time, forget it.
Seti, Einstein and ABC are all running fine here, and Rosetta is now a project I used to crunch.

Outcome Validate error

https://boinc.bakerlab.org/rosetta/result.php?resultid=127005250

Client state Done
Exit status 0 (0x0)

CPU time 6608.081955
stderr out

<core_client_version>5.10.28</core_client_version>
<![CDATA[
<stderr_txt>
# cpu_run_time_pref: 7200
# random seed: 2330183
==
</stderr_txt>
]]>

Validate state Invalid
Claimed credit 8.83546666063523
Granted credit 0
application version 5.89