| 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: 13
|
|
| Author |
|
|
Mike.Gibson
Ace Cruncher England Joined: Aug 23, 2007 Post Count: 12594 Status: Offline Project Badges:
|
Lane Ferm
ARP & MCM have the same deadlines - 6 days. \\\\however, resends (_2 etc) have their deadline halved and there are more of them with ARP. ARP has a much more intense computing requirement so more crunching required. ARP is more suited to 24/7 crunching. If you must shut down, try suspending units first, or use sleep (hibernate) mode instead. Mike |
||
|
|
catchercradle
Senior Cruncher England Joined: Jan 16, 2009 Post Count: 167 Status: Offline Project Badges:
|
In addition to what Mike has said, the issue is similar to some work for CPDN which admittedly has much longer deadlines. With climate work, it is not unusual for the results of one batch of work to be dependent on previous batches of work. If too many work units get severely delayed this could cause a bottleneck preventing new work from going out.
Not 100% sure if this is going on here but if so, it would be a good reason for the deadlines not being any longer than for the MCM tasks. I am fortunate enough to have a machine that unless running ARP tasks in a VM in which case they take 20%+ longer to complete will finish them in under 5 hours. |
||
|
|
TPCBF
Master Cruncher USA Joined: Jan 2, 2011 Post Count: 2173 Status: Offline Project Badges:
|
why is it that ARP has a long running time and a short completion time ?? also, when my computer restarts, ARP losses about 4 hrs running time. MCM has short running times and long completion times. People actually need to read the system requirements of a given project. ARP1 is simply different than a lot of other projects within WCG. The data and algorithm worked on result in a much longer run time and much larger resource requirements. There are two more things that make ARP1 more ardous, and that is connected with the longer runtime, when people don't pay attention to the system requirements. A lot of folks insist on running and loading more WUs than they can reasonably crunch, thus resulting in missing original deadlines. Resends at that point (ending in _2 through _8, in worst case) will then be send out with a shortened, higher priority deadline. Unfortunately, this results a lot of times in more missed deadlines due to WCG/BOINC sending out those resends to "lesser qualified" hosts. Those might be very well able to finish a normal (_0 and _1) ARP1 WU within the 6 day deadline, but might just miss a 3 day deadline. This happens to me a lot, with the less performant hosts keep getting resends while the more powerful crunchers don't see an ARP1 WU for weeks on end... And as for "losing 4hr" on a restart, well, if you restart your system a lot, ARP1 just isn't a project for you to work on. Due to the algorithm used, checkpoints (the point in the whole process where computation can continue after being interrupted being every 12.5%. Other projects have check points at a single digit percentage (and a much short overall runtime), thus any "loss" is less noticeable. Again, people need to understand the system requirements and not just trying to play point ******.... Ralf |
||
|
|
|