Screensaver or possibly some other flavor of "completion" problem with a t299__CASP7 work unit.

I noticed lack of completion progress from home this morning. When I got to the office, the screensaver was sitting on "Model 9, Step 0."

Once I got past the screensaver, BOINC Manager was reporting the work unit as "Running" and "100%" for Progress. BOINC Manager would not display the graphics.

Shutdown of BOINC Manager seemed to take a long time, but it finally happened. I rebooted the system. Once BOINC Manager launched it reported the status on this work unit as completed, "Ready to Report" and started the next work unit.

I forced an update so the result would be available prior to my posting this report.

Keeping in mind that I'm a newbie and could easily be misinterpreting, the result seems to be referring to only 8 models, so the screensaver graphic's Model 9 reference doesn't make sense to me.

---

Screensaver or possibly some other flavor of "completion" problem with a t299__CASP7 work unit.

I noticed lack of completion progress from home this morning. When I got to the office, the screensaver was sitting on "Model 9, Step 0."

Once I got past the screensaver, BOINC Manager was reporting the work unit as "Running" and "100%" for Progress. BOINC Manager would not display the graphics.

Shutdown of BOINC Manager seemed to take a long time, but it finally happened. I rebooted the system. Once BOINC Manager launched it reported the status on this work unit as completed, "Ready to Report" and started the next work unit.

I forced an update so the result would be available prior to my posting this report.

Keeping in mind that I'm a newbie and could easily be misinterpreting, the result seems to be referring to only 8 models, so the screensaver graphic's Model 9 reference doesn't make sense to me.

This is related to a bug report on Ralph. The behaviour is exactly the same. It was supposed to be fixed in 5.22 obviously it is not.

---

I am having a problem running Rosetta. I attach to Rosetta using BOINC manager, and receive the notice of a successfull attachment. When I look at BOINC manager it shows Rosetta running, while Einstein and SETI are suspended. But when I come back several hours later Rosseta is not present, either in Projects or Tasks. When I look at the messages they seem to show Rosetta being loaded and started, but then it ends with: Detaching from project, shown below.

-------------
11-Jun-06 12:41:20|rosetta@home|Starting task t314__CASP7_ABRELAX_SAVE_ALL_OUT_hom002__666_13970_1 using rosetta version 522
11-Jun-06 12:49:01||Contacting account manager at http://bam.boincstats.com/
11-Jun-06 12:49:03||Account manager: BAM Host-ID: 2098
11-Jun-06 12:49:03||Account manager contact succeeded
11-Jun-06 12:49:03|rosetta@home|Resetting project
11-Jun-06 12:49:04||Rescheduling CPU: exit_tasks
11-Jun-06 12:49:04|rosetta@home|Detaching from project


When I check with BAM, my resources are shown as Einstein, SETU, and Rosetta.

What could be causing this problem?

Caig Miller

---

The below linked WU crunched for over 2 hours, and yet was stuck at 0.00%. I aborted the unit because it appeared to be completely hung up, and stopped crunching. I would be interested to know what the problem was...

Aborted 5.22 WU link

Here's one from Saturday:

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

And one from Friday:

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

The only two errors for quite q while.

---

Ian Cundell, St Albans, UK

The below linked WU has severe memory leakage...using >275Megs of CPU memory bringing the hosts commit charge to nearly 600Megs. WU was aborted by user.

Aborted WU

When I check with BAM, my resources are shown as Einstein, SETU, and Rosetta.

What could be causing this problem?

Rosetta's servers were just upgraded to support BAM last week. But it looks like BAM did something, not Rosetta.

---

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/

Had a few WUs crashing when hitting the "show graphics" button. The window popped up, closed immediately and trashed the WU. The Wus are:

WU1
WU2
WU3
WU4

Host list is unhidden, host is a Mac Mini Core Duo, 1,66Ghz, 2GB RAM. Please drop a short notice when I can hide my hosts again...

What's strange is: hitting the "show graphics" button a few minutes before worked perfectly, seems to be a random problem...

I had a work unit processing at about 80% complete and it seemed to be going normally. I suspended the project (as well as Einstein and Seti) and quit Boinc. I shutdown the computer and restarted. When Boinc started again, it reported this work unit as complete and uploaded it. Either it was stuck before or isn't actually complete. I had a similar thing happen a couple of days ago and it also reported work units complete even though the completion times were unusually short.

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

iMac Core Duo, Rosetta version 5.22

---

This work unit looks very strange in the graphics. Parts of the protein do not appear to be connected to the rest of it. It's like some of its missing. The protein appears very small. I first noticed the problem when I saw that the work unit is only using 20Mb memory and ~70Mb virtual but has nearly 9 million page faults. Assuming it was a small protein I took a look at the graphics and noticed the disjointed parts. Any ideas? I'll let it continue for now (5 hours into an 8 hour work unit)

If you would like me to screen shot it please let me know the best dimensions for posting into the forum as I have nowhere to upload it to.

Cheers
Stwato

---

After patting myself on the back for so many successful WU's, I get the following error on this unit:

6/12/2006 11:05:25 PM|rosetta@home|Unrecoverable error for result t306__CASP7_JUMPABINITIO_SAVE_ALL_OUT_BARCODE_hom001__680_902_0 ( - exit code -1073741811 (0xc000000d))

This could be a v5.22, BOINC 5.4.9 or a conflict when checking mail with Mozilla Thunderbird.

Win XP Home Service Pack 2

Mozilla Firefox/Thunderbird combo.

Computers are visible and BOINC 5.4.9 should be debug reporting.

Ignore the Linux Computer as mine is a dual booter.

---

This work unit looks very strange in the graphics. Parts of the protein do not appear to be connected to the rest of it. It's like some of its missing. The protein appears very small. I first noticed the problem when I saw that the work unit is only using 20Mb memory and ~70Mb virtual but has nearly 9 million page faults. Assuming it was a small protein I took a look at the graphics and noticed the disjointed parts. Any ideas? I'll let it continue for now (5 hours into an 8 hour work unit)

If you would like me to screen shot it please let me know the best dimensions for posting into the forum as I have nowhere to upload it to.

Cheers
Stwato

this is a known problem with a few of the processing techniques being used. Not all the work units are using the same processing approach. In some cases they are only looking at parts of the protein structure and that somehow affects the display.

---

We Must look for intelligent life on other planets as,
it is becoming increasingly apparent we will not find any on our own.

See Rhiju's post describing "Jumping"

https://boinc.bakerlab.org/rosetta/forum_thread.php?id=1453#15060

rosetta 5.22
WU Name: t314__CASP7_ABRELAX_SAVE_ALL_OUT_hom004__666_16529_0
running on Mac OS 10.4.6

BOINC Manager Tasks tab shows CPU Time stuck at 01:30:40 and 15%
top command shows TIME = 28:53:41 and climbing

stopped and restarted BOINC
CPU Time reverted to 01:13:00 and 15% but no longer stuck

Symptoms are identical to my post for ralph 5.18

Tony, do you have JP's EMail address? The French guy who always needs new Rosetta .exe EMailed? Could you ask him to see if he can help with this post by French person on Q&A boards? The main parts that translated properly were that he's poor, alone and in a wheelchair. Perhaps JP can read between the lines better than the translation website.

---

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/

Tony, do you have JP's EMail address? The French guy who always needs new Rosetta .exe EMailed? Could you ask him to see if he can help with this post by French person on Q&A boards? The main parts that translated properly were that he's poor, alone and in a wheelchair. Perhaps JP can read between the lines better than the translation website.

Mail sent

Another question quickly, efficiently and comprehensivly answered!
Thanks a lot guys.

Stwato

Another for you. Result for WU 20318986

Hope these are useful.

---

Ian Cundell, St Albans, UK

Here's one that went crazy. resultid 23976562

On this host hostid 214416

This host does nothing but crunch.

Another host did complete the WU sucessfully.

<core_client_version>5.4.9</core_client_version>
<message>
- exit code -1073741819 (0xc0000005)
</message>
<stderr_txt>
X_NB neighbors
increase MAX_NB in param.cc
allatom: 1434 res: 95 atom: 1 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1437 res: 95 atom: 3 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1437 res: 95 atom: 3 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1437 res: 95 atom: 3 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1437 res: 95 atom: 3 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1437 res: 95 atom: 3 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1450 res: 95 atom: 4 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1450 res: 95 atom: 4 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1450 res: 95 atom: 4 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1450 res: 95 atom: 4 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1450 res: 95 atom: 4 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1438 res: 95 atom: 5 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1438 res: 95 atom: 5 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1438 res: 95 atom: 5 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1438 res: 95 atom: 5 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1438 res: 95 atom: 5 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1434 res: 95 atom: 1 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1434 res: 95 atom: 1 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1434 res: 95 atom: 1 has more than MAX_NB neighbors

*snipped a lot of lines*

allatom: 1567 res: 103 atom: 4 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1567 res: 103 atom: 4 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1550 res: 103 atom: 5 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1550 res: 103 atom: 5 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1550 res: 103 atom: 5 has more than MAX_NB neighbors
increase MAX_NB in param.cc
allatom: 1550 res: 103 atom: 5 has more than MAX_NB neighbors


Unhandled Exception Detected...

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x0061B538 read attempt to address 0x790C3DE3

Engaging BOINC Windows Runtime Debugger...

---

Problems with download of WUs: Either now work or heavily overcommitted.

https://boinc.bakerlab.org/rosetta/forum_thread.php?id=1703

Hi,

I run SETI@Home, Einstein and Rosetta. Rosetta is set to 20%. The problem is, that once Rosetta has finished all WUs it never downloads any new WUs. Even when the long_term_debt is highly positive (e.g. 30,000 and bigger) it does not download any WUs. The only way to force download is to pause other projects, but in this case it downloads so many WUs that the computer is overcommitted for many days.

I currently run at "Contact server every 3 days". Even when setting this to 0.3 days before suspending the other projects and resetting it after the download it still downloads too many WUs.

This is what I tried:
1. Set "Contact server every 3 days" to 0.3 days.
2. Set SETI@Home and Einstein to "No new work"
3. Suspend SETI@Home and Einstein
4. Rosetta downloads some WUs
5. Set SETI@Home and Einstein to "Allow new work"
6. Restart SETI@Home and Einstein
7. Set "Contact server every xx days" back to 3 days.
8. Now Rosetta downloads even more WUs, which should not happen since SETI and Einstein are both active -> computer is overcommitted.

Is there a solution to this problem? Resetting long_term_dept to 0.0 on all projects does not help either.

The client errors are there because I have other projects running and therefore manually aborted these Work-Units so that the other project get their share as well. Otherwise Rosetta would have taken over my computers exclusively for several days.

I followed your advice and let it run for several days without any interfearance. I did not get any new work for 5 days but tonight it downloaded 30 work-units and is overcommitted again!

Obviously the scheduling of Rosetta does not work at all.

---