| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: Outsmart Ebola Together
Thread: what the heck happened in the last hours? |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 7
|
|
| Author |
|
|
sgoll
Advanced Cruncher Joined: Oct 24, 2006 Post Count: 87 Status: Offline Project Badges: 
|
> boinccmd --get_state | grep ready| wc -l
----------------------------------------101 Hmmm. Strange. It's a quad-core Intel Atom, set to 1,25 + 0.5 days buffer. <work_buf_min_days>1.250000</work_buf_min_days> <work_buf_additional_days>0.250000</work_buf_additional_days> > boinc@atom:~$ boinccmd --get_state | grep OET| wc -l 297 A little bit to much, but divided by 3 the number is 99 and this looks realistic. So in the last 24 hours (or so) my cruncher got around 80 ... 90 new OET tasks. This cruncher takes 3 ... 11 hours per workunit. Looks like someone played with the estimated computing time and did something wrong. Strange ... -- Stephan  [Edit 1 times, last edit by TKH at Mar 4, 2015 1:33:34 PM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Bar the language in title that's not aligned with the whitey tighties wearing [including Neil Patrick Harris], the device is supposed to get a max of 35 per CPU core, or is it not dear techs
 . Yes, the question on what happened is justified, more bar there being an unannounced change in the max. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
BTW, titles like these are extremely useless and you'd be seeing this thread thrown off most any support forum. A proper title would be along the lines of "Receiving way too many work units on my atom."
 |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
In one scenario, if you happen to be running with a v6.12 or earlier client, strongly recommend upgrading to a v7 release. Before a series of short work units, which OET has intermixed, can completely warp the DCF [Duration Correction Factor]. Here's sample result of my weakly Android tablet... doing them in 3 hours and less.
OET1_ 0000369_ xZAGP-S_ rig_ 20686_ 0-- android_2654196 a Valid 3/2/15 11:23:48 3/2/15 16:44:07 3.14 / 3.24 15.4 / 22.8 It has all of 6 OET buffered, sometimes 7, for 2 cores combined, which is about it. |
||
|
|
ca05065
Senior Cruncher Joined: Dec 4, 2007 Post Count: 325 Status: Offline Project Badges:
|
Yesterday morning the server was sending out workunits with an estimated time duration of 11 minutes at their shortest. Even with a buffer set to 0.5 days, the client kept requesting workunits and in fact reached the limit of in progress workunits for the machine.
Although one batch did have durations of 10 minutes or less, the large number downloaded are taking between 1 and 2 hours. My 0.5 day buffer became over 2 days so I have not downloaded a workunit for the last 36 hours. |
||
|
|
KLiK
Master Cruncher Croatia Joined: Nov 13, 2006 Post Count: 3108 Status: Offline Project Badges:
|
OET simply does a variable time to completion (TTC)...so those estimates are just that - estimates!
----------------------------------------previous jobs on MCM & FA@h were exact to the second of completion... but that would settle, if the computer admins do a recheck of TTCs... |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
From the 1st checkpoint through the 8th OET is darn accurate. It has an unknown wrap up phase at the end, can be seconds, can be minutes, can be hours, longest seen was 9 on a tablet.
The only really relevant part of this thread is, there were 99 tasks assigned per active core, see OP, when 35 is the official max [the safety for plummeting TTC times in the feeder/distributor]. That's a bug, suggesting the feeder/distributor lost count of how much work was actually assigned to the host... as if the IP [In Progress] counter was not being updated in time. This requires Tech attention, certainly clarification. |
||
|
|
|