| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
| World Community Grid Forums
|
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 24
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Consider as interim, if your system does more than 2 days work in 10 days, to set the cache to 2.5 days. This way any result will be on average returned after the 48 hours repair criterion, which will knock the device from the "repair" list. If tasks get older than 10 days, and the client connects to the server and someone else already did the "repair" for your "no reply", than the instruction is send to your client of "server abort". In that mode of operation, do not choose HCC [the shortest project] as these have a 7 day standard deadline... unless your device does do more than 2 days work in 7 days. Then you could choose that science to in this scheme.
----------------------------------------Others will just have to wait a bit longer... which is why 7/10 days deadline is granted, so irregular computing devices can also be volunteered to compute at WCG. Anyway, this is not something the client is likely to ever get a setting for, as all projects outside WCG manage their repairs and repair deadlines differently. There are BOINC projects that have standard return time requirements that are less than WCG's repair deadline. It would become a website device profile feature, when it makes it to the active 'ToDo' list, [by popular demand]. --//-- edit: There's a snag in this, to which I'm just discussing at the developers, since my dual boot system is not getting enough work to bridge scheduled nightly off-line crunch periods. It's the <on_frac> control that measures how much time BOINC is ''on''. Parttime systems have that value reduced with time [unless off for longer than 10 days], so proportioned amounts of work are fetched matching the mean time that BOINC is loaded. You'd probably need a cache setting of higher than 3, to stop the rush jobs coming. Experiment. [Edit 2 times, last edit by Former Member at May 16, 2012 8:06:02 AM] |
||
|
|
mwroggenbuck
Advanced Cruncher USA Joined: Nov 1, 2006 Post Count: 87 Status: Offline Project Badges:
|
I don't quite fit into any of your scenarios. My computer is on about an hour a day. I have 4 cores running this, so I get 4 hours of time a day. That does not add up to 48 hours in 10 days.
What I have been doing is aborting the short jobs when I see them. They have become more and more infrequent. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
It would become a website device profile feature, when it makes it to the active 'ToDo' list, [by popular demand]. Count my vote for this option to be added to the ToDo list! ![]() |
||
|
|
martin64
Senior Cruncher Germany Joined: May 11, 2009 Post Count: 445 Status: Offline Project Badges:
|
Consider as interim, if your system does more than 2 days work in 10 days, to set the cache to 2.5 days. You'd probably need a cache setting of higher than 3, to stop the rush jobs coming. Experiment. Setting the cache to e.g. 4 days will prevent your computer from getting repair jobs. That's how I solved exactly this problem. But there is an issue when you have it running all time over a weekend and then only an hour a day: It will buffer too many tasks and run into panic mode. In this case cancelling some of the oldest jobs that have not started will help. So that's a workaround, but it creates a similar issue, albeit with a somewhat more relaxed time line. You have my vote for the "no repair jobs" button (maybe in an "advanced settings" section?). Ragards, Martin ![]() |
||
|
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges:
|
We have added this to our development backlog. However, we do not have a timeframe for implementation at this time. This means that we agree with you that it will provide value to some volunteer but we have to prioritize the request against other initiatives so it could be an extended period before we could implement the change.
|
||
|
|
mwroggenbuck
Advanced Cruncher USA Joined: Nov 1, 2006 Post Count: 87 Status: Offline Project Badges:
|
Thank you!
|
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Many thanks!
|
||
|
|
JollyJimmy
Advanced Cruncher USA Joined: Aug 23, 2005 Post Count: 115 Status: Offline Project Badges:
|
I vote for what Seke said about an option who's outcome would [...] knock a device permanently into "Not Reliable" state.
----------------------------------------Not only will it accomplish the necessary from an owner perspective, but I think it is also in WCGrid's (and BOINC's) very own interest to eliminate, umm, "reliable slow pokes" (got one of those myself) from rush jobs like repairs and betas. Allowing the owner to manually and permanently mark down such a machine is perfect for everybody! |
||
|
|
mwroggenbuck
Advanced Cruncher USA Joined: Nov 1, 2006 Post Count: 87 Status: Offline Project Badges:
|
Is there any news on this? When is the change likely?
|
||
|
|
rilian
Veteran Cruncher Ukraine - we rule! Joined: Jun 17, 2007 Post Count: 1460 Status: Offline Project Badges:
|
hi mwroggenbuck , you can keep project on "No New Tasks" and download only when you need.
----------------------------------------If you occasionally download 4-days task, abort it. the more tasks you abort, the less "reliable" your computer is. if it is not very reliable, it would not receive 4-day tasks at all you can also try to set WCG on 0 resource share so it would not load tasks unless there are no tasks at all BOINC already has all needed features for you. try looking at http://boinc.berkeley.edu/wiki/Client_configuration maybe you will spot some better option ---------------------------------------- [Edit 2 times, last edit by rilian at Sep 11, 2012 9:56:24 PM] |
||
|
|
|