12 hours, 1% - Linux
https://boinc.bakerlab.org/rosetta/workunit.php?wuid=13955810
TRUNCATE_TERMINI_FULLRELAX_1enh__433_645

10 hours, 1% - Windoz
https://boinc.bakerlab.org/rosetta/workunit.php?wuid=13960661
TRUNCATE_TERMINI_FULLRELAX_1ptq__433_697

---

dag
--Finding aliens is cool, but understanding the structure of proteins is useful.

Find a post that does a link, then click on "reply to this post" for that post. Look at the quoted text in the editing window and it will show how they did it.

You're right, it does. I'd not noticed that before!

---

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

Pardon my ignorance, but how does one technically do a link? Thanks!

Find a post that does a link, then click on "reply to this post" for that post. Look at the quoted text in the editing window and it will show how they did it.

In BBCode you use the opening and closing "square brackets" characters, "[" and "]".

I can't show you eactly because obviously, it would create a link, but, type an open square bracket then type url= then paste in the URL you want, (open the page in your browser and copy the contents from the address line), then a closing square bracket.

What you type next will ne the "highlighted text" of your link.

The put another open square bracket followed by /url and a final closing square bracket.

Thats a link.

17128664

That one has an open square brack "url=https://boinc.bakerlab.org/rosetta/result.php?resultid=17128664" then a close square bracket. It has 17128664 next as "highlighted text", then the open square bracket "/url" and a close square bracket.

Thank you both very much! I have saved these responses for my future reference!

---

Regards,
Bob P.

Here's another 1% hang...again at 1.04%...on a 3rd machine.

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

Here's an odd one...

Rosetta 4.98, WU 7449_largescale_large_fullatom_relax_dec7449_1_08_2.pdb_431_25_0 (deletia)

cwangersky, these are very big WUs which take a loooong time per model, on some P4s they might even take more than 2hr PER MODEL, so unless you have "Leave in mem when pre-empted"=YES, the PC can't complete even 1 model in 2hr before Rosetta gets swapped out to run SETI and your PC starts the WU from 0 again...

Solution: increase "time between swaps" to e.g. 4hr (deletia)

THank you -- I'll give that a try.

---

This work unit was stuck at 1.04% for over six hours. Windows XP SP2.

TRUNCATE_TERMINI_FULLRELAX_1ptq__433_663_0

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

---

This unit stuck at 1.04% for 5.5 hours on Linux with Rosetta 4.98:
TRUNCATE_TERMINI_FULLRELAX_1enh__433_593_0

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

---

Just a reminder to those who are posting stuck WU's -- please abort the 4 work units below. We know why they're hanging, are not sending out anymore, and are giving credits to any of these jobs that have timed out! Thanks.

Found a bug! David Baker and I just tracked down the problem with these 4 workunits. Its a stupid infinite loop that only occurs with proteins with lengths of exactly 44 residues using one particular mode of Rosetta -- somehow no one in our group had ever looked at a protein exactly that size! So TallGuy-13088, you predicted right ...

Please do abort these workunits (below); otherwise, your client will continue to crunch the jobs until it times out (about 48 hours on a Windows machine). The good news is that we will give credit to all the jobs that time out, and are increasing the rigor of in-house testing to prevent this from happening in the future. And this little adventure helped us track down a pernicious bug in our code. Unfortunately, we don't yet have fixes for *all* the stuck jobs, though -- please continue to post info on other jobs that stop moving. It helps!

Jobs that should be aborted:
TRUNCATE_TERMINI_FULLRELAX_1enh__433
TRUNCATE_TERMINI_FULLRELAX_1b3aA_433
TRUNCATE_TERMINI_FULLRELAX_1ptq__433
TRUNCATE_TERMINI_FULLRELAX_2tif__433

---

This one stuck at 1.04% for over 13 hours.

https://boinc.bakerlab.org/rosetta/workunit.php?wuid=13967978

---

Another one (almost 6 hours at 1.04% on Mac OS X) - aborted.

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

---

abort by gui
Windows
20 hours, 1.043%
https://boinc.bakerlab.org/rosetta/workunit.php?wuid=13969518

---

abort by gui
windows
20.15 Hour, 1.042%
https://boinc.bakerlab.org/rosetta/workunit.php?wuid=13977888

---

Just a reminder to those who are posting stuck WU's -- please abort the 4 work units below. We know why they're hanging, are not sending out anymore, and are giving credits to any of these jobs that have timed out! Thanks.

I read the above as saying, no credit granted when we actually abort the stuck units although credit is granted when we leave them to timeout? Will this now be the standard way of dealing with all workunit timeouts or only in this case?

Random, I suppose.
I have let a Wu go on (graphics were moving) so it timed out or it aborted itself and no credits.
Can't be positive anymore about this project.
Have run it for about 5 months and another fortnight and than it's over.

---

Workunit aborted after 23 hours. Stuck at 1.04 %.

https://boinc.bakerlab.org/rosetta/workunit.php?wuid=13940837

Link


edit: looks like this may be one of the 4 already flagged in the postings above ...

---

The 1.4 stalls are still coming I am vary tired of aborting them and losing the tens of thousands of points that are NOT granted in wasted CPU time.
If this project is going to keep letting out BAD work WU's.
Rosetta need to find a way to purge these Bad WU's from there servers when they are found to cause problems like these have. And / or send commands to the users client to delete or abort the Bad WU's on any upload / download to the Rosetta servers.
To keep all the bad WU's in the system or on the Rosetta servers and forcing us to run them to purge them them from the Rosetta system is unfair to us and does damage to the project reputation.
if this continue with out relief people will start to abandon this project

---

If You Want The Best You Must forget The Rest
---------------And Join Free-DC----------------

The 1.4 stalls are still coming I am vary tired of aborting them and losing the tens of thousands of points that are NOT granted in wasted CPU time.
If this project is going to keep letting out BAD work WU's.
Rosetta need to find a way to purge these Bad WU's from there servers when they are found to cause problems like these have. And / or send commands to the users client to delete or abort the Bad WU's on any upload / download to the Rosetta servers.
To keep all the bad WU's in the system or on the Rosetta servers and forcing us to run them to purge them them from the Rosetta system is unfair to us and does damage to the project reputation.
if this continue with out relief people will start to abandon this project

again, we are very sorry for the problems of the recent days. we have spent most of today taking steps to ensure that these problems do not occur again. all the problem work units have been cancelled, and everything should be back to normal very soon (once the jobs that have already been downloaded have left your machines).

since CASP is starting soon, and many of the proteins will be larger, we wanted to do some calculatoins on a broader range of sizes. before pursuing this much further, we need some way of ensuring that these jobs are only sent out to machines appropriate for them, which is difficult with the current BOINC setup; we hope Rom can help us with this.

---

since CASP is starting soon, and many of the proteins will be larger, we wanted to do some calculatoins on a broader range of sizes. before pursuing this much further, we need some way of ensuring that these jobs are only sent out to machines appropriate for them, which is difficult with the current BOINC setup; we hope Rom can help us with this.

Beta 5.00 under Ralph@home preliminarily seems to be successfully processing work units that had previously failed under earlier versions of Rosetta. So it may not be the machines that are at fault, but the underlying Rosetta software itself (which seems to be on the way to being cleaned up if these early successes continue to hold up).

---

Regards,
Bob P.

since CASP is starting soon, and many of the proteins will be larger, we wanted to do some calculatoins on a broader range of sizes. before pursuing this much further, we need some way of ensuring that these jobs are only sent out to machines appropriate for them, which is difficult with the current BOINC setup; we hope Rom can help us with this.

When you upload information to the server, does it verify who it's coming from, or just blindly accept it, and then process it to see if it came from an actual machine running Rosetta?
If Boinc sends a request from hostid=121218 for another workunit, can't the amount of ram (and cpu speed) be looked up from the database that displays this info: https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=121218
Oops.. it doesn't list speed.. just the text cpuID. (speed would thus be based on the floating point and integer ratings..)

And then use something like this to determine what to send to each machine?
(Ram=Ram/number of cpu cores)
If hostid(121218).Ram > 750 Megs, then send EvenBiggerRamWU.
If hostid(121218).Ram > 500 Megs, then send BigRamWU.
If hostid(121218).Ram > 225 Megs, then send NormalWU.

---

But what about the removal of bad WU's from your servers You must set up a way to stop the resending out of the BAD WU's Letting the system purge it self is not right. You have the capability to do auto upgrades you should have the capability to auto abort bad WU;s on client side To let bad WU's run on yours or our system is a BAD THING

---

If You Want The Best You Must forget The Rest
---------------And Join Free-DC----------------

But what about the removal of bad WU's from your servers You must set up a way to stop the resending out of the BAD WU's Letting the system purge it self is not right. You have the capability to do auto upgrades you should have the capability to auto abort bad WU;s on client side To let bad WU's run on yours or our system is a BAD THING

The bad WU's are removed from our servers, but we can't remove them from your machines. Hopefully there will be no more bad WU's at all so this won't be a problem anymore.

---