| 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: 15
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Ok.. so I understand the selection algorithm for work units handed off to external systems to process..
Now I am curious about the actual work selection of work units by the client itself. I modified my preferences to have 10 days of work in my queue. I had kind of anticipated the client itself would have prioritized the work units my system was working on by completion date... meaning it would constantly select the WU's with the closest date first... but that certainly doesn't seem to happen... It looks like this is a "FIFO" queue processing by the client... instead of selecting by due date... quite interesting. Can someone explain this phenomenon to a simple guy? TIA ---Barney |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
The client only works first deadline first if it believes it is in danger of missing a deadline. Otherwise, it works on work in the order received.
This prevents a project with short deadlines from hogging all the processing time. |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
You can have your 10 days buffer sure enough, but do you need it? If a bug develops you'll be sitting there crunching horded junk. WCG is able set a message ready for your client so if it seeks to contact the servers, it will be told to cancel/abort the bad jobs, but with 10 days buffer the client does not frequently make contact. And what if your machine is unable to contact the servers for a day and longer? Risk of overdue work, and zero credit.
----------------------------------------AND, your computer will be known as a very slow returner given the FIFO principle and not likely ever to qualify for BETA jobs or rush work and the most likable part in quorum 2, let the other guy in the quorum wait for his points on that Help Cure Cancer project. The other projects including soon DDDT & FAAH will not suffer noticeably as they will run a distribution similar to RICE or HPF2, where slowness of a few won't hold up validation as that start at 10 and 14 respectively out of the 19 send out per set. For most 2 or 3 days is good if having an intermittent connection and wanting some protection against server outages.
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
knreed
Former World Community Grid Tech Joined: Nov 8, 2004 Post Count: 4504 Status: Offline Project Badges:
|
YThe other projects including soon DDDT & FAAH will not suffer noticeably as they will run a distribution similar to RICE or HPF2, A little off topic, but actually DDDT and FAAH will be run differently then Rice and HPF2. Rice and HPF2 have to compute a lot of info from the same set of input files so we can create one workunit and send it out to a lot of clients (which are then actually generating different result data from that shared set of input data). DDDT and FAAH still have the same amount to compute with the same input data. As a result, each workunit will start out with only one result associated with it. When we are ready to launch the second phase of beta testing for them I will write up some more info about how this will all work. |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Appreciating that the jobs themselves don't change, was more thinking in terms of having a set to combine i.e. the flops computed in each and deriving a credit claim/flop ratio. For instance on Rice and to make it more transparent it would be nice to see the number of seed for all work units on the Result Status detail. People can then compute for themselves how their crunchers in ratio are doing. Momentarily cant make head nor tails of the claims / credits relation.
----------------------------------------
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
You can have your 10 days buffer sure enough, but do you need it? If a bug develops you'll be sitting there crunching horded junk. WCG is able set a message ready for your client so if it seeks to contact the servers, it will be told to cancel/abort the bad jobs, but with 10 days buffer the client does not frequently make contact. And what if your machine is unable to contact the servers for a day and longer? Risk of overdue work, and zero credit. AND, your computer will be known as a very slow returner given the FIFO principle and not likely ever to qualify for BETA jobs or rush work and the most likable part in quorum 2, let the other guy in the quorum wait for his points on that Help Cure Cancer project. The other projects including soon DDDT & FAAH will not suffer noticeably as they will run a distribution similar to RICE or HPF2, where slowness of a few won't hold up validation as that start at 10 and 14 respectively out of the 19 send out per set. For most 2 or 3 days is good if having an intermittent connection and wanting some protection against server outages. interesting... this almost implies that if my client is set up to communicate with WCG every 24 hrs; then my machine will be identified as a slow performer without regard to the quantity of result provided. |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Yes, because WCG logs the actual time it takes to get a result back, per device.
----------------------------------------
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3716 Status: Offline Project Badges:
|
And with your 10-day extra work buffer it will be the same even if you set your client as permanently connected, because the jobs that you will return will have been sent to you many days before.
----------------------------------------You will not be considered as a slow performer but as a slow returner. Cheers. Jean. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
And with your 10-day extra work buffer it will be the same even if you set your client as permanently connected, because the jobs that you will return will have been sent to you many days before. You will not be considered as a slow performer but as a slow returner. Cheers. Jean. Jean, So how does this get undone?... I suspect over time with results being returned one gets out of this scenario? BTW... thanks to everyone for all the explanations.. I appreciate it.. Wish there were a nice, concise, rules of the road (things to consider) if you will... on possible ramifications on all this. |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Simply set your buffer to a lower number and your machine will not fetch work for the period you reduced it, thus for 10 to 2 days means that no work will be fetched for about 8 days.
----------------------------------------You don't want to abort that 8 days work, because that will put you in the bucket of unreliable clients. Rules of road are preset in the profiles that have been created in the device profiles specially for starting crunchers. Then, when you want to change something read different wiki's that are around. The BOINC client is smart but very complex. It's hates being stared at given it's an AI ;D
WCG
----------------------------------------Please help to make the Forums an enjoyable experience for All! [Edit 2 times, last edit by Sekerob at Jul 17, 2008 6:17:35 PM] |
||
|
|
|