| 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: 5
|
|
| Author |
|
|
gb009761
Master Cruncher Scotland Joined: Apr 6, 2005 Post Count: 3010 Status: Offline Project Badges:
|
I've got 2 computers here, one a reasonably fast one, and another, a lot slower/older, and I'd like the ability to decide whether to receive repair WU's (i.e. those with a shorter deadline than normal) on a particular device for a particular project. Yes, "in theory", the system should only send WU's out to devices that it thinks can return the WU's in time - but, time, time, time and again, I've received long ARP WU's on my slower computer with shorter deadlines than normal, and I can't recall EVER, my machine returning them within the deadline (and therefore, triggering off another copy being sent out to another device). They're more often than not, either returned "too late" or after the repair WU sent out to replace the repair WU my device received, has already been started - and thus, doesn't then get "server aborted", as it's already "up and running" somewhere else. Thus, wasted CPU cycles spent on crunching them, whereas they could have been used to crunch a normal deadline ARP WU instead.
----------------------------------------I've now resorted to manually aborting any shorter deadline WU's that arrive on that particular device - but, there will be times when I'm not able to do this. Can this be considered as a future enhance ment to the system? ![]() |
||
|
|
TPCBF
Master Cruncher USA Joined: Jan 2, 2011 Post Count: 2173 Status: Offline Project Badges:
|
I've got 2 computers here, one a reasonably fast one, and another, a lot slower/older, and I'd like the ability to decide whether to receive repair WU's (i.e. those with a shorter deadline than normal) on a particular device for a particular project. Yes, "in theory", the system should only send WU's out to devices that it thinks can return the WU's in time - but, time, time, time and again, I've received long ARP WU's on my slower computer with shorter deadlines than normal, and I can't recall EVER, my machine returning them within the deadline (and therefore, triggering off another copy being sent out to another device). They're more often than not, either returned "too late" or after the repair WU sent out to replace the repair WU my device received, has already been started - and thus, doesn't then get "server aborted", as it's already "up and running" somewhere else. Thus, wasted CPU cycles spent on crunching them, whereas they could have been used to crunch a normal deadline ARP WU instead. Well, it rather looks like your system in question isn't matching the system requirements for ARP, which are well above any other project on WCG, to begin with. Just have a profile for that host that doesn't include ARP at all, and this is much less likely to happen...I've now resorted to manually aborting any shorter deadline WU's that arrive on that particular device - but, there will be times when I'm not able to do this. Can this be considered as a future enhance ment to the system? Ralf |
||
|
|
Cyclops
Senior Cruncher Joined: Jun 13, 2022 Post Count: 295 Status: Offline |
I've got 2 computers here, one a reasonably fast one, and another, a lot slower/older, and I'd like the ability to decide whether to receive repair WU's (i.e. those with a shorter deadline than normal) on a particular device for a particular project. Yes, "in theory", the system should only send WU's out to devices that it thinks can return the WU's in time - but, time, time, time and again, I've received long ARP WU's on my slower computer with shorter deadlines than normal, and I can't recall EVER, my machine returning them within the deadline (and therefore, triggering off another copy being sent out to another device). They're more often than not, either returned "too late" or after the repair WU sent out to replace the repair WU my device received, has already been started - and thus, doesn't then get "server aborted", as it's already "up and running" somewhere else. Thus, wasted CPU cycles spent on crunching them, whereas they could have been used to crunch a normal deadline ARP WU instead. I've now resorted to manually aborting any shorter deadline WU's that arrive on that particular device - but, there will be times when I'm not able to do this. Can this be considered as a future enhance ment to the system? Noted |
||
|
|
gb009761
Master Cruncher Scotland Joined: Apr 6, 2005 Post Count: 3010 Status: Offline Project Badges:
|
Thanks Cyclops.
----------------------------------------Just FYI, my slower machine has just been sent yet another ARP repair WU with a short deadline - which I've subsequently aborted. To be clear Ralf, this machine CAN process 2 ARP WU's at a time (with a mix of OPN) and return them in time for 'normal' deadline WU's. On my faster machine, repair WU's with a shorter deadline, isn't an issue. ![]() |
||
|
|
MarkH
Advanced Cruncher United States of America Joined: May 16, 2020 Post Count: 66 Status: Offline Project Badges:
|
I have run ARPs on a circa 2008 laptop with a Pentium processor and 2 Gb RAM (!) The work takes up to 36 hours to run, even under Linux. I have not missed a deadline yet, but I wonder if re-benchmarking your hardware has any effect on job assignments?
----------------------------------------
That science of the people, by the people, for the people, shall not perish from the Earth.
|
||
|
|
|