Message boards : BOINC client : Suggestion - allow for updating the deadlines
Message board moderation
Author | Message |
---|---|
Send message Joined: 6 Jul 10 Posts: 585 |
Change the deadline on the server side is to prevent an additional copy going out, whilst in the know your client is working on the task in high priority. WCG does the same thing, which is of particular interest to the project that trickles intermediate results... they extend the deadline, whenever there is a planned/unplanned longer outage. At the same time, their scheduler sets a message ready for unstarted tasks to be aborted. When that message goes across to the client, the client ignores it when the task is already running. Now the question, what seems like a not very useful communication... changing the deadline on the client side. Not sure how the client responds... rotates away to another task under deadline duress? Coelum Non Animum Mutant, Qui Trans Mare Currunt |
Send message Joined: 5 Oct 06 Posts: 5134 |
I've just replied to a query from a project administrator, who is seeing a spate of ERROR_UNSTARTED_LATE tasks. A previous volunteer running the same project had reported a spate of EXIT_TIME_LIMIT_EXCEEDED errors. Both of these are client-generated errors, but I suspect arise from a common cause: poor runtime estimation by the project server. In the specific case of this particular project, I suspect (but haven't had confirmation yet) that a run of very quick-finishing tasks has driven the APR values stored in the host_app_version table to impossible heights: I've seen evidence of a CPU supposedly running at over 200 GFlops. I've given the usual advice: Ensure rsc_fpops_est is accurate Set rsc_fpops_bound to a high multiplier Mark infeasible runtimes as outliers - all of which we've known about for years (runtime outliers were documented in 2014, although I remember the original discussion as being earlier than that). As things stand at the moment, it's very hard for a volunteer to recover from EXIT_TIME_LIMIT_EXCEEDED and ERROR_UNSTARTED_LATE errors - it can be easiest to force-generate a new HOSTID (itself not easy), and thus start with a fresh HAV row. The ERROR_UNSTARTED_LATE (client) errors could be addressed by the OP's suggestion, and it should be an issue on GitHub. I couldn't find an existing one this morning - I'll search again, more carefully, and start one if needed and nobody beats me to it. |
Copyright © 2025 University of California.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License,
Version 1.2 or any later version published by the Free Software Foundation.