They are freezing not crashing. The wu's are doing ~15 min of work and then going to the next unit instead of finishing it.

---

I got 9 mini 6 hour wu's today. I have had 5 of them 'freeze' around 12-18 min and then go on to the next wu. I have not had this with Rosetta before today, but I have had some do this on MilkyWay. Is there any info I can leave to help? I am using Boinc 5.10.13.

You can help by joining the Ralph@home project for alpha testing if you haven't already.

http://ralph.bakerlab.org

Give us a few thousand WUs over there to work on.

I attached to Ralph.

There is no work to use for testing.

Nice try.

I got 9 mini 6 hour wu's today. I have had 5 of them 'freeze' around 12-18 min and then go on to the next wu. I have not had this with Rosetta before today, but I have had some do this on MilkyWay. Is there any info I can leave to help? I am using Boinc 5.10.13.

You can help by joining the Ralph@home project for alpha testing if you haven't already.

http://ralph.bakerlab.org

---

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)

I want to wait a little bit to give users who want to help out a chance to download the symbols file. We'll send out more test jobs later tonight or tomorrow.

so far on my system at a 4 hr setting, 1 ran 3hrs 50 or so and quit
another i ran only went to 3hrs 15 min or so and quit.
first one came in 5 credits under claimed, the second one came in at 8 under claimed. kinda hurting my average with these.

---

so far on my system at a 4 hr setting, 1 ran 3hrs 50 or so and quit
another i ran only went to 3hrs 15 min or so and quit.
first one came in 5 credits under claimed, the second one came in at 8 under claimed. kinda hurting my average with these.

I don't know why it would be much different compared to the standard rosetta app with our credit averaging system. It does use more memory but we are working on reducing it.

Yes, it's taking more RAM. I'm running one of each right now. Peak for 5.93 is 114,764K and for mini is 185,424. Current usage is 103M for 5.93 and 174M for mini.

Same here, 167MB (172 max) for Mini vs 154MB (155 max) for standard.

But Mini only takes 166MB of virtual memory, while the standard Rosetta takes 230MB. I don't know if you can just add up those two numbers to get the total memory usage of 334MB vs 484MB.

But this probably means anyway that Mini actually takes less RAM.

first one came in 5 credits under claimed, the second one came in at 8 under claimed. kinda hurting my average with these.

I almost always get a little less credit than claimed. 8 credits out of 350 is only about 2% anway, so it shouldn't matter much.

Just a quick note on the NOD32 issue.
I had the same false-positive on my system and after having a quick look and a scan it appears that it is only IMON that detects Mini as a virus. IMON is NOD32's internet scanner, it actually scans files as they are downloading by watching HTTP and POP3 traffic to stop viruses making it onto a system in the first place. NOD32's realtime scanner does not detect Mini as a virus and neither does the on demand scanner.

I checked the result summary and the minirosetta jobs have a 90% success rate on R@h which is lower than the old rosetta app but it's not bad.

From a Rosetta user's perspective, I would consider 90% to be the minimum acceptable success rate on RALPH. Anything less than 97-98% here on Rosetta is unacceptable. It sucks to realize that you got a work-unit from a non-alpha project that causes BOINC to lock up and crash.

Please be more diligent with your alpha testing. What's the rush to get it here? If we want to run beta/unstable workunits, we will run them on RALPH (which I recently had to suspend on all 3 of my workstations due to mini-rosetta consistently crashing BOINC completely).

I checked the result summary and the minirosetta jobs have a 90% success rate on R@h which is lower than the old rosetta app but it's not bad.

From a Rosetta user's perspective, I would consider 90% to be the minimum acceptable success rate on RALPH. Anything less than 97-98% here on Rosetta is unacceptable. It sucks to realize that you got a work-unit from a non-alpha project that causes BOINC to lock up and crash.

Please be more diligent with your alpha testing. What's the rush to get it here? If we want to run beta/unstable workunits, we will run them on RALPH (which I recently had to suspend on all 3 of my workstations due to mini-rosetta consistently crashing BOINC completely).

I am not aware of a work unit on R@h from mini that causes BOINC to lock up and crash. There is no real rush except for the interest of science and getting results, that is why we are slowly adding mini work units to R@h. We do however need to get mini running for CASP which is coming up this summer. Ralph does not have the same diversity of computers and active users as R@h so we have to eventually start running jobs, particularly since ralph jobs are having a similar success rate as R@h. I realize some people will have computers that don't like some mini work units as there are some computers that do not like rosetta tasks.

I checked the result summary and the minirosetta jobs have a 90% success rate on R@h which is lower than the old rosetta app but it's not bad.

From a Rosetta user's perspective, I would consider 90% to be the minimum acceptable success rate on RALPH. Anything less than 97-98% here on Rosetta is unacceptable. It sucks to realize that you got a work-unit from a non-alpha project that causes BOINC to lock up and crash.

Please be more diligent with your alpha testing. What's the rush to get it here? If we want to run beta/unstable workunits, we will run them on RALPH (which I recently had to suspend on all 3 of my workstations due to mini-rosetta consistently crashing BOINC completely).

I am not aware of a work unit on R@h from mini that causes BOINC to lock up and crash. There is no real rush except for the interest of science and getting results, that is why we are slowly adding mini work units to R@h. We do however need to get mini running for CASP which is coming up this summer. Ralph does not have the same diversity of computers and active users as R@h so we have to eventually start running jobs, particularly since ralph jobs are having a similar success rate as R@h. I realize some people will have computers that don't like some mini work units as there are some computers that do not like rosetta tasks.

The list of CPUs on Ralph looks very much like the list of CPUs on Rosetta, just fewer of them.........of course it doesn't matter there are fewer CPUs on Ralph, because you don't give us enough WUs to keep those CPUs busy anyway.

What does the diversity of active users have to do with anything?

If you aren't going to use Ralph as a "real" test site, why don't you shut it down, conserve those resources and continue to test on Rosetta like you do now.

I checked the result summary and the minirosetta jobs have a 90% success rate on R@h which is lower than the old rosetta app but it's not bad.

From a Rosetta user's perspective, I would consider 90% to be the minimum acceptable success rate on RALPH. Anything less than 97-98% here on Rosetta is unacceptable. It sucks to realize that you got a work-unit from a non-alpha project that causes BOINC to lock up and crash.

Please be more diligent with your alpha testing. What's the rush to get it here? If we want to run beta/unstable workunits, we will run them on RALPH (which I recently had to suspend on all 3 of my workstations due to mini-rosetta consistently crashing BOINC completely).

I am not aware of a work unit on R@h from mini that causes BOINC to lock up and crash. There is no real rush except for the interest of science and getting results, that is why we are slowly adding mini work units to R@h. We do however need to get mini running for CASP which is coming up this summer. Ralph does not have the same diversity of computers and active users as R@h so we have to eventually start running jobs, particularly since ralph jobs are having a similar success rate as R@h. I realize some people will have computers that don't like some mini work units as there are some computers that do not like rosetta tasks.

The list of CPUs on Ralph looks very much like the list of CPUs on Rosetta, just fewer of them.........of course it doesn't matter there are fewer CPUs on Ralph, because you don't give us enough WUs to keep those CPUs busy anyway.

What does the diversity of active users have to do with anything?

If you aren't going to use Ralph as a "real" test site, why don't you shut it down, conserve those resources and continue to test on Rosetta like you do now.

Agreed.

90% is a horrible success rate. 1 of every 10 WUs fail? How are you going to get 97-98% on Rosetta if you can only get 90% on Ralph?

I would think until you can get 99.x% on Ralph, it should never see Rosetta.

The whole point of Ralph was to get the bugs out and provide a clean debugged application and WU mix to Rosetta.

---

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)

Ralph does not have the same diversity of computers and active users as R@h so we have to eventually start running jobs

This is something that should be published on the front page of the project, as it is a significantly different approach than almost all other BOINC projects and conflicts with what you are telling us we are doing. To quote a user from a few weeks ago:

"I joined because I want to cure people, not because I want to test software. I understand that with better software, the results might improve - however I would like to stick to the real rosetta for the time being."

It seems like there is no "real rosetta" per your comment above. If you need more diversity on RALPH, perhaps you should be asking for it from your contributors (us). The fact that we are here, attached, and reading the forum means that if you need specific help over at RALPH - i.e. specific OS or hardware tested - just ask. We might be able to help. Lots of people connected to Rosetta don't check the message board. If WU's start failing or acting up, they disconnect from the project and find another one.

According to David E K, there was a memory issue that got through the alpha testing without being identified.

There is a SAV false positive that got through alpha without being identified.

There are several other quirky issues in this thread.

How long was 1.07 tested on Ralph? Doesn't it seem apparent it should have seen more time? I'm not trying to be a jerk about this, I just think that you would help us immensely by being more thorough in alpha.

How long was 1.07 tested on Ralph? Doesn't it seem apparent it should have seen more time?

Your answer was posted previously:

with Mini Rosetta 1.07 there is a new record for "test period": 33 minutes and 14 seconds between the time it was released on Ralph and Rosetta.

---

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)

This is in response to angus, j2satx and jack's comments

The only difference between 1.06, which has been tested thoroughly IMO, and 1.07, is a minor and trivial bug fix. That is why the "test period" was short. There isn't a significant difference in the success rates between minirosetta and old rosetta, see below. I understand people's opinions and frustrations about the testing, acceptable success rates, and errors. That is why we stopped issuing mini tasks for the time being. We will however, slowly issue tasks again for experiments that we are interested in and that are important. We are not running tests on R@h, they are all production jobs. I don't think it is possible for Ralph to be like R@h. It's a lot to ask from users to run a test site and expect the same turnout as a production site and we wouldn't want to crash thousands of computers during a testing phase. Also, I don't like to waste cpu time by flooding ralph with tasks unless we are able to get useful debugging feedback. Issues are likely to surface on R@h that do not on Ralph (and visa versa) due to differences in the computers and users, not just the computers that are listed but the active computers that do work and the active users that provide feedback. The diversity may look similar from the site, but I see differences in practice. Looking at the status of both applications, it's hard to say that more could be done with mini compared to old rosetta. There's room for improvement for both apps.

The remaining issues that we'd like to address with mini are:

1. screen saver. currently under dev using the minirosetta game framework, may even be an optional game where people can compete with computers and each other to design/fold proteins.
2. larger memory footprint. being worked on and will likely be smaller than old rosetta eventually
3. weird NOD32 virus detection with the NOD32's IMON internet scanner. Scanning the application manually does not detect a virus and obviously it is not a virus, but this is a hassle for NOD32 IMON users so we are looking into it.
4. a rare access violation error
5. a rare validation error

Here is a comparison of the status reports (note, we are not planning to support PPC macs with mini):

minirosetta 1.07




rosetta 5.93




I hope this helps. I'm trying to respond to everyones comments and provide useful info. I know it's a big jump for some users to run a new app and I know some users will have issues with it. So if you have any worries or questions, don't hesitate to ask or make comments.

thanks!

Can see that i need to get an 'unknown' PC and never have a failure.

Many thanks for your reply to all the problems.

"If you aren't going to use Ralph as a "real" test site, why don't you shut it down, conserve those resources and continue to test on Rosetta like you do now."

Ralph is invaluable. We catch many bugs and errors with ralph that would otherwise happen on R@h.

j2satx,

Did you download the 1.07 mini app symbols file into your ralph project directory? I see an access violation error from one of your computers but do not see any trace information.

I think the general flavor of things here at R@H is that longer more exhaustive testing should be done at Ralph before the program is released to R@H.
The feeling is that "beta" type work should be done at Ralph and then a fresh named release without "beta" be released on R@H. The feeling as I see it, is that work units and programs are not tested enough before being released here. minirosetta for instance should be deeply tested on Ralph and when it is "complete" and work for that program has been tested deeply and when it is 99% tested with work, then release it here. Don't halfway test it on Ralph and then release it here and then pull it back because there are bugs in it.

"If you aren't going to use Ralph as a "real" test site, why don't you shut it down, conserve those resources and continue to test on Rosetta like you do now."

Ralph is invaluable. We catch many bugs and errors with ralph that would otherwise happen on R@h.

---

I didn't pull back the mini tasks because there are bugs in it. I did it in response to user's complaints and the fact that the minirosetta jobs were filling the queue more than expected. Are you talking about the beta in the rosetta application name? We should take that out of the name since it isn't a beta app and is misleading.

I think the general flavor of things here at R@H is that longer more exhaustive testing should be done at Ralph before the program is released to R@H.
The feeling is that "beta" type work should be done at Ralph and then a fresh named release without "beta" be released on R@H. The feeling as I see it, is that work units and programs are not tested enough before being released here. minirosetta for instance should be deeply tested on Ralph and when it is "complete" and work for that program has been tested deeply and when it is 99% tested with work, then release it here. Don't halfway test it on Ralph and then release it here and then pull it back because there are bugs in it.

"If you aren't going to use Ralph as a "real" test site, why don't you shut it down, conserve those resources and continue to test on Rosetta like you do now."

Ralph is invaluable. We catch many bugs and errors with ralph that would otherwise happen on R@h.