Another idea on optimization here, which just came in to play with Rosetta. If a file fails the signature verification, and the client marks the task as a download failure, why continue downloading the other files only that task requires?
It would seem as though either the failed file should first be tried from any secondary servers, or all other downloads specific to tasks that are now marked as download failures should be aborted. The present behavior seems to be to continue all of the downloads, and not to retry the file that failed the signature. So these downloads have no hope of being useful. However, the potential exists that there are files in common with other tasks that do not require the problem file. So I tried to word the above carefully. The next scheduler request then gets another task that needs the file that caused the signature problem, and since the client doesn't have it, it downloads it again, presumably almost always from the same server as just failed 2 minutes ago based on timezone of client. Meanwhile the task reporting back with download failure causes another task to be created on same WU, and the process continues. The server churns trying to do all the downloads, only to get all the failures reported back. So, another thought while on the topic would be that the server should have some means of detecting chronic problems and insulating itself from the otherwise inevitable results (scheduler timeouts, no tasks available, server too busy to receive completed tasks, etc.). It might insulate itself in several ways. Not reissueing the tasks would at least save you half (in Rosetta's case with max errors of 2) of the downloads. Reverifying the signature to attempt to correct the problem might help keep the problem from continueing to penetrate the client base. Making a hold on or marking as failed all tasks that require the problem file(s). If there is other work that does not require the file, this would help get that work to clients without all the fruitless churn to burn through the problem tasks. Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running rose...@home just might! http://boinc.bakerlab.org/rosetta/ _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
