| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: BOINC Agent Support
Thread: What happens if a task is aborted? |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 11
|
|
| Author |
|
|
GTRsdk
Cruncher Joined: Aug 30, 2012 Post Count: 1 Status: Offline Project Badges: 
|
Sorry if this was posted elsewhere, but I couldn't find what happens what happens when a task is aborted.
Does the task get sent to someone else to work on? What exactly happens when a task is aborted? GTRsdk |
||
|
|
Filip Falta
Cruncher Joined: Sep 2, 2010 Post Count: 12 Status: Offline Project Badges: 
|
Task will be sent to someone else. Nothing will be lost :)
|
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
if originally a single rep. it becomes a double for validation. not sure if it effects your reliability or not..
----------------------------------------[Edit 1 times, last edit by Former Member at Sep 19, 2012 11:46:49 PM] |
||
|
|
cjslman
Master Cruncher Mexico Joined: Nov 23, 2004 Post Count: 2082 Status: Offline Project Badges: 
|
Well, I think it does affect the cruncher's reliability... every time I abort a WU, my next delivered WUs have validation.
----------------------------------------CJSL Crunching for a better world... |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
It's not supposed to, it's just that momentarily tasks that end with code 202 and 203 are let's say, misinterpreted [there's an open blackboard item on this]. Fortunately, "reliability", the allowance to run the zero redundant [ZR] sciences alone is administered at science app level, so having one error on DSFL, does not affect any of the other ZRs... SN2S/HFCC/GFAM etc. For the quorum 2 and over sciences it's wurscht altogether, no change to reliability, a simple reassignment of a new copy to another cruncher.
----------------------------------------P.S. The 202/203 problem is seemingly only there for those running client 7. I'm seeing wingman that do get the proper Server Aborted / User Aborted registration. [Edit 1 times, last edit by Former Member at Sep 20, 2012 7:44:19 AM] |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges: 
|
It's not supposed to, It's always been this way. With the pre-v7 server-code, the checks for "reliable" was: 1: Enough valid results in a row. 2: Turnaround-time < 2 days (except some platforms with higher limit). 3: Computers daily quota = max daily quota. Since any abortions regardless of type decreased the quota with 1, your computer wasn't reliable any longer. But of course, since daily quota doubled on next "success"-report, in most instances users didn't detect this temporary loss of "reliable".  "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
OK OK, it's the usual "reliable" and "reliable" confusion that goes around, in Norway too I gather. Anything non-valid goes against quota, including aborts. "It's not supposed to"... go against "reliable" as in getting repair tasks. Still getting them when I or the servers abort a task [for whatever reason], and a lot more repairs under S700 than under S601 (And I cant be bothered with them, but we hope to have this "don't send me repairs" in the future, since it's on the unscheduled to-do list) ;>)
|
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Only now saw an offline reply by knreed dated October 10, that he made a change so that the server/user aborts [code 202/203] don't go against the reliability count anymore: Snip
"user aborts and server aborts should no longer reset the 'consecutive valid' counter on the host_app_version table. That will allow them to retain their 'reliable' status." So, whilst for some clients the response code on the Result Status page still prints "Error" when it involves certain clients, it no longer has the undesired impact for the Zero Redundant state [the server code patch to print the proper status will surely follow at some point]. Just observed on a Linux machine how one got a 202 and the following 7 of the same science did it alone and validated promptly without wingman. This will improve the efficiency a few percentage points for the ZR sciences. Happy days are here again [actually, a smile requires 30% less muscle action than a grumpy face... yes really] |
||
|
|
Bearcat
Master Cruncher USA Joined: Jan 6, 2007 Post Count: 2803 Status: Offline Project Badges: 
|
It definately doesn't go against your machine for aborting as I aborted 52 GPU wu's yesterday, due to issues. Once I fixed it, reselected HCC and they came pouring back right away. Didn't want them erroring out and wasting computing time. No reason to penalize user aborts which am glad it doesn't.
----------------------------------------
Crunching for humanity since 2007!
 |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Right, but any result of any return status goes against the [daily] quota, so your 52 did get subtracted from the total daily device allowance]. Just in case the pouring suddenly stops with that infamous message ;>) (Reason is, else someone could generate many thousands of repair results a day, unintentional or willful, which causes the overall repair queue to back up, which causes those that are not repair queue rated to be short of slots... more complaints.)
|
||
|
|
|