| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: Outsmart Ebola Together
Thread: Outsmart Ebola Together - v7.19 - Released |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 53
|
|
| Author |
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
It's a limit set on new computers, or in this case on new projects on an old computer. It doesn't seem to work half the time. e.g. 10-Feb-2015 11:39:47 [World Community Grid] Scheduler request succeeded: got 0 new tasks 10-Feb-2015 11:39:47 [World Community Grid] Message from server: No tasks sent 10-Feb-2015 11:39:47 [World Community Grid] Message from server: No tasks are available for Outsmart Ebola Together 10-Feb-2015 11:39:47 [World Community Grid] Message from server: No tasks are available for the applications you have selected. 10-Feb-2015 11:39:47 [World Community Grid] Message from server: This computer has finished a daily quota of 5 tasks 10-Feb-2015 11:41:53 [World Community Grid] Sending scheduler request: To fetch work. Requesting 455361 seconds of work, reporting 0 completed tasks 10-Feb-2015 11:41:58 [World Community Grid] Scheduler request succeeded: got 13 new tasks |
||
|
|
TPCBF
Master Cruncher USA Joined: Jan 2, 2011 Post Count: 2173 Status: Offline Project Badges: 
|
Und die Fahrt wird schneller....
 |
|||
|
||||
|
NixChix
Veteran Cruncher United States Joined: Apr 29, 2007 Post Count: 1187 Status: Offline Project Badges: 
|
I found some OET on my computers and moved them to the top of the crunching queue. Other projects will take a backseat for a bit.
----------------------------------------Cheers   |
||
|
|
Dark Angel
Veteran Cruncher Australia Joined: Nov 11, 2005 Post Count: 728 Status: Offline Project Badges: 
|
Is it just me or are some of these units REALLY short? I just returned one in four minutes without any apparent error, on a 2GHz Sossaman rig (2006 vintage). The task properties suggest there was only one job in it, but still ... four minutes?? The rig in question doesn't normally throw errors or invalids, either.
---------------------------------------- Currently being moderated under false pretences |
||
|
|
asdavid
Veteran Cruncher FRANCE Joined: Nov 18, 2004 Post Count: 521 Status: Offline Project Badges: 
|
They are really short
----------------------------------------OET1_ 0000320_ xZAGP-FW_ rig_ 1717_ 1-- IBM-PBNRE26 Valid 10/02/15 08:25:06 10/02/15 10:05:22 0.26 / 0.27 6.3 / 6.3 OET1_ 0000320_ xZAGP-FW_ rig_ 1704_ 1-- IBM-PBNRE26 Valid 10/02/15 08:25:06 10/02/15 10:05:22 0.26 / 0.28 6.6 / 6.5 Edit to correct an English error
Anne-Sophie
---------------------------------------- [Edit 1 times, last edit by asdavid at Feb 10, 2015 10:45:11 AM] |
||
|
|
KLiK
Master Cruncher Croatia Joined: Nov 13, 2006 Post Count: 3108 Status: Offline Project Badges:
|
thx
---------------------------------------- |
||
|
|
Sandvika
Advanced Cruncher United Kingdom Joined: Apr 27, 2007 Post Count: 112 Status: Offline Project Badges:
|
Is it just me or are some of these units REALLY short? I just returned one in four minutes without any apparent error, on a 2GHz Sossaman rig (2006 vintage). The task properties suggest there was only one job in it, but still ... four minutes?? The rig in question doesn't normally throw errors or invalids, either. We've seen some of these batches in beta. Some of the *ZAGP* WUs such as those in batch 320 are really short, the *MBGP* WUs such as those in batch 309 are really long, comparable to CEP2 in duration. However, there's a lot of variability and I've got a *ZAGP* WU from batch 313 that's only reached 25% after 4 hours. I sincerely hope that there isn't an 18 hour limit per WU as with CEP2 because that led to me losing >10% of my work and baling out of the project. The WU duration estimates across my devices vary hugely, probably as an artifact of getting a wild mix of durations with the first WUs crunched. This governs how much work BOINC requests, so I have one device maxed out with 25 WUs in progress per thread because it decided they only take 40 minutes. In fact the WUs currently crunching will take 4x longer than that, so I guess it will recalibrate in due course and stop asking for more work. Meanwhile, those devices that started with big WUs are still constrained by the quota system and are not getting more work either. Fingers crossed that it will all settle down quite quickly.    |
||
|
|
anhhai
Veteran Cruncher Joined: Mar 22, 2005 Post Count: 839 Status: Offline Project Badges: 
|
Nice, the race is back on for badges!!!
---------------------------------------- |
||
|
|
Falconet
Master Cruncher Portugal Joined: Mar 9, 2009 Post Count: 3315 Status: Offline Project Badges: 
|
Is it just me or are some of these units REALLY short? I just returned one in four minutes without any apparent error, on a 2GHz Sossaman rig (2006 vintage). The task properties suggest there was only one job in it, but still ... four minutes?? The rig in question doesn't normally throw errors or invalids, either. We've seen some of these batches in beta. Some of the *ZAGP* WUs such as those in batch 320 are really short, the *MBGP* WUs such as those in batch 309 are really long, comparable to CEP2 in duration. However, there's a lot of variability and I've got a *ZAGP* WU from batch 313 that's only reached 25% after 4 hours. I sincerely hope that there isn't an 18 hour limit per WU as with CEP2 because that led to me losing >10% of my work and baling out of the project. The WU duration estimates across my devices vary hugely, probably as an artifact of getting a wild mix of durations with the first WUs crunched. This governs how much work BOINC requests, so I have one device maxed out with 25 WUs in progress per thread because it decided they only take 40 minutes. In fact the WUs currently crunching will take 4x longer than that, so I guess it will recalibrate in due course and stop asking for more work. Meanwhile, those devices that started with big WUs are still constrained by the quota system and are not getting more work either. Fingers crossed that it will all settle down quite quickly. I remember Autodock had a built-in fail-safe system that ended the work unit after a very long period of time. No idea if the same with Vina. Don't understand how you lost 10% of work with the CEP2 18 hour cut-off. After 18 CPU hours, the work-unit simply ends and work is returned. Nothing is lost.  - AMD Ryzen 5 1600AF 6C/12T 3.2 GHz - 85W - AMD Ryzen 5 2500U 4C/8T 2.0 GHz - 28W - AMD Ryzen 7 7730U 8C/16T 3.0 GHz |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Is it just me or are some of these units REALLY short? I just returned one in four minutes without any apparent error, on a 2GHz Sossaman rig (2006 vintage). The task properties suggest there was only one job in it, but still ... four minutes?? The rig in question doesn't normally throw errors or invalids, either. We've seen some of these batches in beta. Some of the *ZAGP* WUs such as those in batch 320 are really short, the *MBGP* WUs such as those in batch 309 are really long, comparable to CEP2 in duration. However, there's a lot of variability and I've got a *ZAGP* WU from batch 313 that's only reached 25% after 4 hours. I sincerely hope that there isn't an 18 hour limit per WU as with CEP2 because that led to me losing >10% of my work and baling out of the project. The WU duration estimates across my devices vary hugely, probably as an artifact of getting a wild mix of durations with the first WUs crunched. This governs how much work BOINC requests, so I have one device maxed out with 25 WUs in progress per thread because it decided they only take 40 minutes. In fact the WUs currently crunching will take 4x longer than that, so I guess it will recalibrate in due course and stop asking for more work. Meanwhile, those devices that started with big WUs are still constrained by the quota system and are not getting more work either. Fingers crossed that it will all settle down quite quickly. Assumptions is the pitfall. If you have a client version 7.x you could do with a major rewrite on your last paragraph. Factors <dont_use_dcf/>, device benchmark constant, server determined average FPOPS on returned work by the pool. And no, CEP2 has a purposeful cut-off in hard hours. Other sciences have a 5-10 times sometimes 40 times overrun build in as in estimated FPOPS times whatever applicable project factor. The actual average runtime on CEP2 never exceeded 9 hours in last 11 months, had a one time peak out at 13.5, see http://bit.ly/WCGART , meaning 18 hour devices are the exception, should indeed be considered to not be opted in. Conversely, even completing the first of 8 jobs in a task before the cut-off would have been contributing. Doing jobs #1-3 is better and #4-7 is cranberry juice on top of the icing. |
||
|
|
|