| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: Suggestions / Feedback
Thread: Option to prevent Devices from receiving 'urgent'/'rush' WU's |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 4
|
|
| Author |
|
|
gb009761
Master Cruncher Scotland Joined: Apr 6, 2005 Post Count: 2977 Status: Offline Project Badges: 
|
Is it possible to create an option for a device to prevent them from receiving 'rush', 'repair' or 'urgent' WU's - those with a shorter deadline from 'the norm'?
----------------------------------------I currently have 2 machines - one of which, is an older/slower laptop that can easily manage the 7 day ARP WU's (if I kick them off as soon as I spot them, they can easily meet the due date), but if one comes in with the shorter deadline, then it's really 'touch and go' as to whether it'll get back in time - causing a 'No Reply', and thus, another WU to be sent out (quite often, then my WU is returned, but not quick enough for that other WU to be 'Server Aborted').  |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Not sure what the shorter deadline is these days, 50% i.e. 3.5 days?
Theoretically if the return time is say 5 days, the machine should not be qualifying for that project's 'reliable' mark, but don't know if this is measured at project level or WCG general/all project wide i.e. if you run SCC on the side the machine could still be seen as a relatively reliable 'quick' returner' Anyway a trick could be: 1) Set on device in app_config how many can run concurrent 2) Set in device profile number allowed on host equal to allowed to run concurrent PLUS 1. This with a runtime of the same 5 days gives you multiple days to catch these before they get a chance to start and abort them. Of course, any buffered task starts deadline count down, so when the previous 'regular' finishes the buffered one has already lost several days from it's 7 day deadline. |
||
|
|
gb009761
Master Cruncher Scotland Joined: Apr 6, 2005 Post Count: 2977 Status: Offline Project Badges:
|
Hi lavaflow,
----------------------------------------On my slower machine (indeed, for both of my machines), I've got a max setting of 3 ARP WU's - and 24 for MIP WU's, for which, there's no issue due to the relatively shortness of those tasks (this could be maintaining my machines 'reliable status'). With regards to ARP1, I've had 28 WU's arrive on my slower machine, with a spread of 62.68 -> 107.16 actual hours of runtime (average = 87.38, of which, 13 ran under the 84 hours that is the current short-deadline of ARP1 WU's). Of course, if there's any delay (there wasn't in this particular case - as soon as it came in, it kicked off in 'high priority' state), my machine crashes/reboots etc., then that severely lowers the chances of it being returned within 3.5 days - due to the very long timespans between checkpoints. Of course, for my slower machine, there's no issue with the 'normal' return timelimit of 7 days (168 hours) - as I generally kick these WU's off as soon as I see them, and even then, I've got some leeway. Edit: Added in the latest returned ARP1 WU (the one that was a short deadline - which had a runtime of 106.06 actual hours). [Edit 1 times, last edit by gb009761 at Apr 10, 2020 3:59:04 PM] |
||
|
|
|