| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: Suggestions / Feedback
Thread: Completion Dates Less than 10 Days |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 16
|
|
| Author |
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges: 
|
Of course Ingleside, as so many times, we need to underline for you that we're talking WCG [sec] But the problem isn't WCG-specific, so atleast to me it makes more sence trying to fix the problem for all BOINC-projects, instead for making a band-aid only usable by a single project. Also, even if looks only on WCG, doesn't beta-work routinely have a fairly short deadline, but some batches has a long deadline? If so, how does your suggested fix stop users downloading short-deadline beta-work and at the same time not stop them from downloading long-deadline beta-work? A general preference of "Don't send work with less than N days deadline" to me makes more sence than your WCG-specific "Don't send repair-work"... But, hang on, this option is already included, since: if ("Connected..." > deadline) => don't send the work.  "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." [Edit 1 times, last edit by Ingleside at Apr 24, 2010 3:34:44 PM] |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
The band aid is that the policies at WCG may not be same to what other projects practice. I'd thus make it a DC project specific function, that others can activate too when WCG contributes this back to Berkeley.
----------------------------------------Beta goes to anyone, no return history criteria, no reliability history. For clients that do not have regular uptime thus the wiser choice would be to associate to a device profile / venue that does not have beta activated. The connect interval is a daring employment, if the up-time is variable. Does it tick when the lid is closed? Probably yes, but what if the device dries up and is not scheduled to connect ... would it override the setting? Think not, not sure though. edit: added the profile bit for beta.
WCG
----------------------------------------Please help to make the Forums an enjoyable experience for All! [Edit 2 times, last edit by Sekerob at Apr 24, 2010 3:51:13 PM] |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges:
|
The band aid is that the policies at WCG may not be same to what other projects practice. I'd thus make it a DC project specific function, that others can activate too when WCG contributes this back to Berkeley. Yes, the policies is different... But as for making it a project-specific option, this doesn't make much sence to me... For WCG, the suggestion would mean: 1: Only triggered for computers with average turnaround-time < 2 days, let's say it's 1.9 days. 2: User can enable an option so he won't get repair-work with 4 days deadline. This is more than 2x his average turnaround-time... 3: And, even if he does get this task, and it somehow passes the deadline, he can AFAIK return it 2 days after the deadline and still get credited for it... This is more than 3x his average turnaround-time... As comparison, let's use my example, with another BOINC-project: 4: Has variable-deadline work with 20 days and 2 days deadline. 5: Let's again say the average turnaround-time is 1.9 days... 6: User gets a 2-days deadline-task... 7: And misses the deadline on this... This gives 2 possible outcomes: 7a: It's not re-issued, meaning wu is dead the moment his task passes deadline, and even if he returns it 1 minute after the deadline, it's useless, and he won't get any credit for it. 7b: It's re-issued. In this instance, he'll only get credited if he beats the re-issue back. So, WCG can exceed average turnaround-time with 2.10x before re-issued again, and 3.15x before will be useless. In the BOINC-project with some short-deadline work, even a 5% increase over the average turnaround-time, and the result can be useless. Atleast to me, a global option with "Don't send me work < N days deadline" would be much better than the "Don't send me re-issue work".  Beta goes to anyone, no return history criteria, no reliability history. For clients that do not have regular uptime thus the wiser choice would be to associate to a device profile / venue that does not have beta activated. This would be the recommended choise, but users chasing their beta-badge doesn't always follow the recommendations.  The connect interval is a daring employment, if the up-time is variable. Does it tick when the lid is closed? Probably yes, but what if the device dries up and is not scheduled to connect ... would it override the setting? Think not, not sure though. With a 0.01 days cache-setting the client won't make a connection if it's currently disabled, and the same is true if you're using a 4-days cache-setting. "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Colleague,
One of the things I do is to run my system in such a way that it only requests new work when a WU is within about a half hour from completion. My system runs 24 hrs a day nonstop (with the exception of a scheduled [or unscheduled sometimes] reboot) so my WU's are almost always guaranteed of finishing on time or rather within almost any "reasonable" deadline imposed. There are other benefits to setting up a machine in this kind of configuration and of course some consequences too. The benefits are if your machine becomes a "pending validation wing-man" as soon as you get the WU your machine is either working on the WU or will be very soon. The WU isn't stuck in a deep queue awaiting to run for days on end that conform with the normal WCG policy. Of course, there are consequences too. Some of which become if you are interested in only one project and don't opt for other WU's to be selected when your preferred area of interest runs out of WU's your machine can sit idle meaning your the WU's you get are basically only the ones you are running or are about to run. Of course, if you should choose to go on vacation for say several days (likely > 14) and your WU's are pending in that period of time, .... well... you can guess the rest. Anyway, this might be a method to help you get more WU's completed. Now for me personally, I just let things run as they come, so if there are beta's in the queue; or if high priority WU's come in they get selected immediately and returned as quickly as possible. In effect my configuration becomes akin to a First-in-(kinda-first-out). I personally despise being the hold-up for anyone's results to being validated. |
||
|
|
Hypernova
Master Cruncher Audaces Fortuna Juvat ! Vaud - Switzerland Joined: Dec 16, 2008 Post Count: 1908 Status: Offline Project Badges: 
|
I personally despise being the hold-up for anyone's results to being validated. Ok shame on me. I admit I have a one day cache standard. But then what about those with 10 day caches. Should they be hanged?   |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Ok shame on me. I admit I have a one day cache standard. But then what about those with 10 day caches. Should they be hanged? Naw... Hanging is to sever ... Perhaps a hours worth of flogging with some really boiled spaghetti ? Perhaps having to brush your teeth for an extra 30 seconds ? Perhaps having to take a bath in Ice Water? Perhaps being forced to read a "Girly" mag after all the interesting pictures have been removed? But Hanging is definitely over the limit.  |
||
|
|
|