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.

---

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

Manually aborted at 1% after 52 hrs, it was a dodgy truncate unit I missed when checking systems.

Thing is though it did run for 52 hours does that mean the workunit timeouts only work on windows systems not linux? It would be good to know as I wont always be able to check up as often as I have been on these servers.

Thanks

---

Thanks for the report. Timeouts should happen on all machines -- but in BOINC they're tied to the number of floating point operations, not wall clock time, unfortunately. Because the Windows app appears to be a little bit faster than the Linux app, timeouts will generally take more time on the linux apps.

We completely understand that you can't check up on the servers all the time -- we're being extra vigilant to make sure this sort of problem doesn't happen again.

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

Manually aborted at 1% after 52 hrs, it was a dodgy truncate unit I missed when checking systems.

Thing is though it did run for 52 hours does that mean the workunit timeouts only work on windows systems not linux? It would be good to know as I wont always be able to check up as often as I have been on these servers.

Thanks

---

I just aborted WU TRUNCATE_TERMINI_FULLRELAX_1b3aA_433_20_2 as this was still at 1.04% at close to 10 hours (CPU time= 35,419.17 seconds).

When I checked the graphics a few times in the last hour nothing was hapening there also.

Ray

---

Pizza@Home Rays Place Rays place Forums

Preferece run time 2 hours
actual cpu time 5 hours 50 minutes
Measured floating point speed 1417.88 million ops/sec
Measured integer speed 3114.3 million ops/sec
Done 1.48%
Windows XP
Rosetta 4.98
<message>aborted by user
https://boinc.bakerlab.org/rosetta/result.php?resultid=17217056

---

Click signature for global team stats

Preferece run time 2 hours
actual cpu time 5 hours 50 minutes
Measured floating point speed 1417.88 million ops/sec
Measured integer speed 3114.3 million ops/sec
Done 1.48%
Windows XP
Rosetta 4.98
<message>aborted by user
https://boinc.bakerlab.org/rosetta/result.php?resultid=17217056

Hi Carlos

I had 1 of those on a P4 2,8.

It took 3 H + to compete it.

Anders n

---

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

Aborted at 1.8% after 5 hours or so, because the graphics also stopped.

---

Hi,

Thanks for reporting this. We are working on maintaining a relative stable run time on these WUs. Also see my reply to this thread.

Bin

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

Aborted at 1.8% after 5 hours or so, because the graphics also stopped.

---

7521_largescale_large_fullatom_relax_dec7521_1_02_9.pdb_437_133_0

7486_largescale_large_fullatom_relax_dec7486_1_10_4.pdb_435_177_0

stuck (and aborted) at ~ 1%

---

Work unit stuck at 1.04% with more than 175 HOURS of processing time (I really should check this computer more often).

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

Needless to say, I think I'll abort it...

50% error rate today...

https://boinc.bakerlab.org/rosetta/result.php?resultid=17261491
https://boinc.bakerlab.org/rosetta/result.php?resultid=17261490
https://boinc.bakerlab.org/rosetta/result.php?resultid=17261489
https://boinc.bakerlab.org/rosetta/result.php?resultid=17261456

All with the same error:

<core_client_version>5.2.13</core_client_version>
<message>Onjuiste functie. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
# random seed: 3316837
# random seed: 3316837
# cpu_run_time_pref: 7200
# Exception caught in nstruct loop ii=1 i=2
#   num_decoys:1 attempts:2 cpu_run_time:5760.47
ERROR:: Exit at: .nblist.cc line:541

</stderr_txt>

"Onjuiste functie" is Dutch ( :) ) for "wrong function"

4/15/2006 12:26:24 PM|rosetta@home|Unrecoverable error for result ALL_TOPOLOGY_CODES_1shfA_434_201_0 (aborted by user)
aborted result

This seemed to freeze at 2.42% (I think - didn't do screen shot) and the CPU time in Boinc Manager had been stopped for almost an hour. Couldn't get into "show graphics" to look at progress. see this thread for no graphics problem

---

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 one was up to 8 hours and 1.04% done, with 16 hours to go. So I aborted it.

• The WU was created on : 11 Apr 2006 17:46:10 UTC
  
• name: TRUNCATE_TERMINI_FULLRELAX_2tif__433_637
  
• Computer was : AuthenticAMD AMD Athlon(tm) Processor
  
• Operating System: Microsoft Windows XP
  
• Home Edition, Service Pack 2, (05.01.2600.00)
  
• Memory 639.42 MB
  

---