Index  | Recent Threads  | Unanswered Threads  | Who's Active  | Guidelines  | Search
 

Quick Go »
No member browsing this thread
Thread Status: Active
Total posts in this thread: 24
Posts: 24   Pages: 3   [ Previous Page | 1 2 3 | Next Page ]
[ Jump to Last Post ]
Post new Thread
Author
Previous Thread This topic has been viewed 2883 times and has 23 replies Next Thread
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: Is there any way to prevent "rush" jobs?

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]
[May 16, 2012 6:17:18 AM]   Link   Report threatening or abusive post: please login first  Go to top 
mwroggenbuck
Advanced Cruncher
USA
Joined: Nov 1, 2006
Post Count: 87
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: Is there any way to prevent "rush" jobs?

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.
[May 16, 2012 8:40:56 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: Is there any way to prevent "rush" jobs?

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! biggrin
[May 16, 2012 9:18:25 PM]   Link   Report threatening or abusive post: please login first  Go to top 
martin64
Senior Cruncher
Germany
Joined: May 11, 2009
Post Count: 445
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: Is there any way to prevent "rush" jobs?

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
----------------------------------------

[May 16, 2012 10:09:20 PM]   Link   Report threatening or abusive post: please login first  Go to top 
knreed
Former World Community Grid Tech
Joined: Nov 8, 2004
Post Count: 4504
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: Is there any way to prevent "rush" jobs?

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.
[May 17, 2012 12:57:06 PM]   Link   Report threatening or abusive post: please login first  Go to top 
mwroggenbuck
Advanced Cruncher
USA
Joined: Nov 1, 2006
Post Count: 87
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: Is there any way to prevent "rush" jobs?

Thank you!
[May 17, 2012 9:22:39 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Former Member
Cruncher
Joined: May 22, 2018
Post Count: 0
Status: Offline
Reply to this Post  Reply with Quote 
Re: Is there any way to prevent "rush" jobs?

Many thanks!
[May 17, 2012 10:51:27 PM]   Link   Report threatening or abusive post: please login first  Go to top 
JollyJimmy
Advanced Cruncher
USA
Joined: Aug 23, 2005
Post Count: 115
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: Is there any way to prevent "rush" jobs?

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!
----------------------------------------
[May 17, 2012 11:44:46 PM]   Link   Report threatening or abusive post: please login first  Go to top 
mwroggenbuck
Advanced Cruncher
USA
Joined: Nov 1, 2006
Post Count: 87
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: Is there any way to prevent "rush" jobs?

Is there any news on this? When is the change likely?
[Sep 11, 2012 8:46:46 PM]   Link   Report threatening or abusive post: please login first  Go to top 
rilian
Veteran Cruncher
Ukraine - we rule!
Joined: Jun 17, 2007
Post Count: 1460
Status: Offline
Project Badges:
Reply to this Post  Reply with Quote 
Re: Is there any way to prevent "rush" jobs?

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]
[Sep 11, 2012 9:54:28 PM]   Link   Report threatening or abusive post: please login first  Go to top 
Posts: 24   Pages: 3   [ Previous Page | 1 2 3 | Next Page ]
[ Jump to Last Post ]
Post new Thread