[boinc_dev] Aborted (by user)?
HI! I recently learned that newer clients automatically abort tasks that have not been started and are already past the deadline. I like this better than the previous ... consider aborting it message. However this is something the user has no control about. So the text aborted by user at various places (at least in the web code) is outdated and somewhat misleading. Additionally I, as a project manager, would really like to know whether a task was aborted by the client because it passed the deadline (which might suggest an extension of the deadlines), or whether it was aborted manually for other reasons. Is there a way to distinguish these two cases? If not, could there be made one e.g. by using a different exit status? The way the web code should be updated / fixed would clearly depends on whether these cases can be distinguished. Best, Bernd ___ 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.
Re: [boinc_dev] Aborted (by user)?
My apologies - I gave Bernd that impression on the strength of http://boinc.berkeley.edu/trac/changeset/17399 and lines 1143-1158 of the current (trunk) client_state.cpp Changeset 17399 contains #define ERR_UNSTARTED_LATE -233 which again appears in current code, but appears not to be listed on that Wiki page. Actually the client doesn't make the decision to abort tasks; it's instructed to do so by the scheduler. It's possible to discriminate most cases: see http://boinc.berkeley.edu/trac/wiki/JobStatus -- David On 18-Apr-2011 1:29 AM, Bernd Machenschalk wrote: HI! I recently learned that newer clients automatically abort tasks that have not been started and are already past the deadline. I like this better than the previous ... consider aborting it message. However this is something the user has no control about. So the text aborted by user at various places (at least in the web code) is outdated and somewhat misleading. Additionally I, as a project manager, would really like to know whether a task was aborted by the client because it passed the deadline (which might suggest an extension of the deadlines), or whether it was aborted manually for other reasons. Is there a way to distinguish these two cases? If not, could there be made one e.g. by using a different exit status? The way the web code should be updated / fixed would clearly depends on whether these cases can be distinguished. Best, Bernd ___ 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. ___ 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.
Re: [boinc_dev] #GPUs #cores
Bernd: Please verify this experimentally; I'm not convinced. -- David On 15-Apr-2011 1:12 AM, Bernd Machenschalk wrote: On 15.04.11 08:00, David Anderson wrote: The client tries to use all GPUs, even if this overcommits the CPUs. The assumption is that this maximizes throughput. Is there evidence that it doesn't? There are two types of GPU applications: such that run almost entirely on the GPU and just need a small fraction of a CPU core, and such that use the GPU mainly as a coprocessor for certain parts of the computation (e.g. FFT) and require a full CPU core. I'd say the assumption is true for the former, but not for the latter. So similar to the distinction made between these two types of Apps in assigning process priority, I'd do this in resource counting, too. Best, Bernd ___ 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.
