We've received complaints from some (but not many) users that their machines are slowed down significantly -- internet connections have gone down, Windows Media Player starts up slowly -- with the apps from 5.10 to 5.12. We think its some debugging code that was introduced into 5.10; we have removed this code. Please post here if you continue to see slowdowns -- or if your slowdown problem has been cured with ralph 5.13!

---

So far, it's looking good. Actually, I had to do some fanagling to force WU downloads, as my resource share is 25, and had a lot of debt to other projects, but managed to grab some...

Anyhow, I did some initial testing with what was running into severe performance probs, and not seeing it right now. I've got some more things to do, so I'll let some other projects run while I'm away (which should help balance the debt anyhow); and resume testing when I'm back to push the computer some so as to get more testing with it under load.

---

I just discovered that I had a slowdown problem with 5.12. I got one of the new 5.13 workunits and it appears that things are back to normal.

5.13 has only been running 30 minutes here, but so far so good!
I need to run things overnight with my normal project mix to be sure.

Any short technical description on the debugging code removed? Or a pointer to it if it's public? I may beg for details to troubleshoot another app which handled this particularly badly; I don't think telling the vendor to run ralph/rosetta 5.12 is going to fly...

---

Yes!!! Thanks much to sTrey, LabRat, and Son Goku for posting. I am going to go ahead and post the app to rosetta@home.

To answer sTrey's question, we're going to put the debugging code back in for the next ralph version (probably in two days) but make it optional -- I'll ask Rom (one of the Boinc developers) to post instructions for how to activate the messages.

So far, it's looking good. Actually, I had to do some fanagling to force WU downloads, as my resource share is 25, and had a lot of debt to other projects, but managed to grab some...

Anyhow, I did some initial testing with what was running into severe performance probs, and not seeing it right now. I've got some more things to do, so I'll let some other projects run while I'm away (which should help balance the debt anyhow); and resume testing when I'm back to push the computer some so as to get more testing with it under load.

---

Thank you Rhiju, for responding so fast when only a few people were complaining about this, and also to Rom for responding quickly and accurately on a fix/workaround. All is still going well on my pc.

Hello, I had effectively slowings down and cuts of internet connection with the version 5.12.
Now, it is always slow (40' for 1,04 %).
A big part of the graphic screen ( RMSD) is missing as the image shows (it).

Ralph 5.13 TEST_HOMOLOG_ABRELAX_hom002_t283_507_7
the same thing for hom003.
I hope that it can help you.

---

I have seen problems with the screensaver just a seconde ago, can't post the screenshot here, will try to post it as soon as possible. For now, just the description: the Searching... and Accepted graphics seem to be broken from time to time, just showing a minimal part of the protein chain (maybe 4 or 5 segments only). This happened just a few times, for 2 or 3 seconds, as far as i know, will keep an eye on it...


JUMP_CLOSE_CHAINBREAK_ALLBARCODE_1q7sA_SAVE_ALL_OUT_506_41_0 using rosetta_beta version 513 (seen with model 2, windowed /windowed-maximized mode, didn't test it as real screensaver, but i guess it will be the same, for resizing doesn't affect it)

---

Happened again with JUMP_CLOSE_CHAINBREAK_ALLBARCODE_1q7sA_SAVE_ALL_OUT_506_77_0 using rosetta_beta version 513

Not sure if it is a bug, or just zoom on the active chain part...

got 2 more screenshots now, images point to my dynamic IP, will keep them available as long as possible!

---

Those three pics are taken within a few seconds and belong to the same model and same WU! And I noticed another problem: The pictures do not really show it, but the graphic sometimes displays a huge gap where the protein chain should obviously be connected!!! Don't know if this is a display bug only, or if it affects the correct setup of the chain!

---

I'm seeing the same thing in the graphics, the display alternates between normal appearance and partial chains as shown by wizzszz's pics.

However I much prefer this to the problems 5.12 was causing...

Me again :)!

Watched the last WU (as in the pics below) displaying about 41%, Model 3
calculating far more than 1,000,000 steps, then it finished and uploaded w/o starting another Model (credits granted, so i think no error was reported)

And in the last minute of calculating, the display seemed to be stuck over and over again (each time for a second or so) where "Searching..." should change more fluently, while steps counter increased normally!

Any other RALPH model had about 400,000 steps, so I wonder if this is wanted behaviour...

---

To answer sTrey's question, we're going to put the debugging code back in for the next ralph version (probably in two days) but make it optional -- I'll ask Rom (one of the Boinc developers) to post instructions for how to activate the messages.

You may also want to make this optional in the future for Rosetta, too, so that those people who do encounter problems can activate the debugger. This may help to reduce their frustration because they are helping the developers to solve the problem. For the rest of Rosetta users with no problems, they can run the app without the debugger. Just my 2 cents!

---

There's also when the apps are released to other scientific projects... If the app is worked out by then, they might not want to take the time to run debugging (which is more important during the apps development process)... But who knows, and that will be between the respective scientists to discuss/decide among themselves...

If it's optimal enough, that it isn't like it's seizing the computer on one however, it won't matter so much for the user. It's when it becomes difficult to do anything else that issues start to arrise.

Anyhow, I went on, with both downloading/uploading some torrents, and catching up on some episodes of Lost I hadn't seen previously. I let RALPH run while doing all that, and all still seemed well...

---

Hello again,
This Wu's are blocked to 1.04 % during 42 or 50 minutes then pass in 100 %. I do not believe that it is normal !
TEST_HOMOLOG_ABRELAX_hom002_t283__507_30_0_0
TEST_HOMOLOG_ABRELAX_hom003_t283__507_30_0_0
TEST_HOMOLOG_ABRELAX_hom003_t283__507_27_0
TEST_HOMOLOG_ABRELAX_hom005_t283__507_43_0_0

---

When I managed to get Ralph 5.13 to be the only project in memory, my problem with slow response on right clicking on an .avi file and having the menu pop up in 6-15 seconds disappeared. It only took the 2 seconds (first time) and under 1 second the second time.

Which is good news.. however..

I ran Rosetta at 100% (1 project); and have the "leave the app in memory when pre-empted" setting checked. To get Ralph 5.13 to be the only app in memory, I had to suspend everything, reboot, and then unsuspend Ralph 5.13. With both apps unsuspended, they were both in memory. and the slow response problem returned.

When I switched Boinc to not "leave the app in memory when pre-empted" and ran the update I noticed the apps running for a few minutes, then switching, and when I looked back at them, they'd lost whatever cpu time they'd gained.. and moved on to a new WU.

"leave app in memory when pre-empted" is checked again.. the project is updated, and the cpu time continued to increase for whichever app was currently being run. The slow response problem is still here (at least for right clicking on .avi files), in spite of the fact that updating was supposed to allow us an update of the Boinc API - if I read the announcements on Rosetta properly last night. Before I could report my findings last night, I gave up, and opened up Cineplayer to play a dvd. (Cineplayer doesn't seem affected.. :) )

---

Benny: thanks for posting. I think the remaining issues on your app are probably going to happen any time you run both ralph and r@h; some clients don't seem to be juggling the memory well. I'm running ralph, r@h, and seti@home, and leaving in memory -- but I've got a Mac, which may handle virtual memory differently than a PC.

The good news is that we're continuing to cut down the memory use of Rosetta; at this point we're approaching the memory requirements of seti!

One thing you may want to try is to leave graphics off for ralph, rosetta, or both. We've noticed that once you turn on graphics, a large amount of virtual memory is allocated to the program -- and it doesn't get deallocated if you close the graphics window. The same things happen with SETI@home. We're in touch with the BOINC team in an effort to figure out what's going on.

When I managed to get Ralph 5.13 to be the only project in memory, my problem with slow response on right clicking on an .avi file and having the menu pop up in 6-15 seconds disappeared. It only took the 2 seconds (first time) and under 1 second the second time.

Which is good news.. however..

I ran Rosetta at 100% (1 project); and have the "leave the app in memory when pre-empted" setting checked. To get Ralph 5.13 to be the only app in memory, I had to suspend everything, reboot, and then unsuspend Ralph 5.13. With both apps unsuspended, they were both in memory. and the slow response problem returned.

When I switched Boinc to not "leave the app in memory when pre-empted" and ran the update I noticed the apps running for a few minutes, then switching, and when I looked back at them, they'd lost whatever cpu time they'd gained.. and moved on to a new WU.

"leave app in memory when pre-empted" is checked again.. the project is updated, and the cpu time continued to increase for whichever app was currently being run. The slow response problem is still here (at least for right clicking on .avi files), in spite of the fact that updating was supposed to allow us an update of the Boinc API - if I read the announcements on Rosetta properly last night. Before I could report my findings last night, I gave up, and opened up Cineplayer to play a dvd. (Cineplayer doesn't seem affected.. :) )

---

This 5.13 failed while screensaver running and I was away. WU 97133 TEST_HOMOLOG_ABRELAX_hom002_t287__508_87

<core_client_version>5.4.9</core_client_version>
<message>
- exit code -1073741811 (0xc000000d)
</message>
<stderr_txt>
# random seed: 3071457
# cpu_run_time_pref: 14400

This is NOT a double post
This 5.13 failed while screensaver was running and I was away. WU 93568 JUMP_NATIVEBARCODE_ANTIPARALLEL_1tul__SAVE_ALL_OUT_486_26

<core_client_version>5.4.9</core_client_version>
<message>
- exit code -1073741811 (0xc000000d)
</message>
<stderr_txt>
# random seed: 3075433
# cpu_run_time_pref: 14400

</stderr_txt>