And one more note on this issue: IMHO current SETI@home beta project practice to "keeping pipe warm" while there is nothing to test is bad one and should be avoided (on SETI beta and on other such beta projects too). It just stimulates such incorrect user impression about purpose and goal of test project. If there is no new apps to test and no new BOINC server side changes that require testing before being applied to main project, test project SHOULD NOT DISTRIBUTE ANY WORK. End of story. This way users will definitely know when their participation in test project required and when they just waste electricity. "Just keeping pipe warm" should be avoided. Some users just use SETI beta project as non-limited supply of workunits and don't care if their processing worthless currently. This situation just highlighted this issue. It's duty of test project itself to cut work supply when work not needed. SETI beta has some work always - and this should not be the case.
Среда, 8 мая 2013, 1:44 -04:00 от "Josef W. Segur" <jse...@westelcom.com>: >On Tue, 07 May 2013 21:30:10 -0400, Nicolás Alvarez < >nicolas.alva...@gmail.com > wrote: > >> 2013/5/7, Charles Elliott < elliott...@verizon.net >: >>> There are three facts of which you are obviously unaware: >>> >>> 1. It is intensely humiliating to experience the loss of thousands of >>> workunits, especially after one has spent hours trying to avoid that exact >>> situation, and after taking exactly the same actions that had avoided that >>> loss previously. >> >> "Task no longer usable" means the tasks were cancelled on the server. >> Maybe whatever test S@H Beta was doing with those tasks was finished, >> so they aborted the remaining tasks for that test. If the client kept >> processing them, the server would reject the result because the task >> was cancelled; that would be a huge waste of time and resources. > >I've trimmed the rest to note a side effect based on just that part. The >cancelled tasks and the server aborts which ensued resulted in most hosts >having their quotas reduced to 1 as if there had been a compute error on each >of those aborted tasks. > >At one time there was special handling for server aborts which avoided that >effect, but it has since gone missing. I think some thought should be put into >the purpose of reducing quota and which kinds of errors ought to be exempted. >There have been other situations where a server problem has resulted in >transfer errors, for instance, though it would be more difficult to >distinguish those from a client side problem. >-- > Joe >_______________________________________________ >boinc_dev mailing list >boinc_dev@ssl.berkeley.edu >http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >To unsubscribe, visit the above URL and >(near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
