| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: FightAIDS@Home
Thread: Have very slow WU # FAHV_x3VQ7_IN_LEDGFa_rig_0220728_0005 |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 234
|
|
| Author |
|
|
KWSN - A Shrubbery
Master Cruncher Joined: Jan 8, 2006 Post Count: 1585 Status: Offline |
Seems to me the anti-cheat code kicks in at some point just past 48 hours. You'll have to get an official response for more accuracy.
----------------------------------------Oddly enough, my points are going way too far the other way. I'm getting up to 600 for a 38 hour result.  Distributed computing volunteer since September 27, 2000 |
||
|
|
Seoulpowergrid
Veteran Cruncher Joined: Apr 12, 2013 Post Count: 820 Status: Offline Project Badges: 
|
Oddly enough, my points are going way too far the other way. I'm getting up to 600 for a 38 hour result. lol, sounds like you found the butter zone. |
||
|
|
KWSN - A Shrubbery
Master Cruncher Joined: Jan 8, 2006 Post Count: 1585 Status: Offline |
Something to do with the Beta. New projects take some time to even out their point distributions. Apparently the systems that got Beta work had that RAC carry over to other sciences.
----------------------------------------Not that I'm complaining, but when my fastest system doubles its average credit, something is seriously wonky(TM). Distributed computing volunteer since September 27, 2000 |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
What is certainly 'drôle', to keep that word in swung, is that no work is being returned from the monsters that run multi-days. This prevents the server side learning how much runtime to predict for new tasks submitted. Though having reduced the buffer to only 0.5 days and being loaded up by the 200+ hour running x3zsm and the 62 hours running x3zso, got one of the latter on the android to top the reserves up.
----------------------------------------Btw, i've cancelled a few x3zcm ready to start on the tab. Three are running now 20 , 16 and 12 hours non stop and progress is at 9.3 , 7.8 and 5.7 percent. The only thing in the projection being right is the progress percent, so they will need over 200 hours. Does anyone know what happens with 'mobiles' that get these tasks and just 10 days deadline? Not going to make it, let alone the 9 tasks that will be sitting in the buffer for 9 days before even allowed to be started. Looking at day statistics, 287 years, either there's an enormous amount of work 'in progress' through unfinished tasks, or the lights are dimming. Last weekend 799 years, this weekend 619. [Edit 1 times, last edit by Former Member at Sep 22, 2014 6:20:16 AM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
The "-131 (file size too big)" error should be corrected on any work units sent out by the server from this point forward (including resends). Any work units that have already been downloaded may still encounter this problem though. Thank you for your (continued) patience as we work through these issues. Seippel After writing another post on the anticipated runtime on android, over 200 hours, just realized 2 things on the x3zcm and one on the pc going '-131' after completing and reporting, well failing to upload of course. 1) These arrived couple of days ago on the android before starting, due all the other buffered tasks taking much much longer. This means they complete after deadline, causing more copies to be circulated, with the correct allowed output file size this time. 2) This x3zcm on the pc going out with -131 means the older now running on android could very well have the same faith after 200+ hours. Just hit the abort button on all 3 running, regardless of them already having build 50 hours computing time. See no point in processing 600+ hours worth on what has a quite predictable negative outcome, -131. [Edit 1 times, last edit by Former Member at Sep 22, 2014 7:12:09 AM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Also aborted all the buffered 'repair' assignments. The x3zco will run 62 hours on android, the percent progress being the one part reliable to extrapolate to total time. This means they complete after deadline and any in cache that will start in 62 hours will than already be overdue. More copies rendered useless.
----------------------------------------Now have set the device to not fetch any more work. Like to have my tab with me when out, not locked to a desktop. [Edit 1 times, last edit by Former Member at Sep 22, 2014 7:48:25 AM] |
||
|
|
Speedy51
Veteran Cruncher New Zealand Joined: Nov 4, 2005 Post Count: 1311 Status: Offline Project Badges: 
|
Looking at day statistics, 287 years, either there's an enormous amount of work 'in progress' through unfinished tasks, or the lights are dimming. Last weekend 799 years, this weekend 619. I have contributed 47.83 hours worth of work to the statistics this was just one task. I am surprised to see that in statistics the average return time is in the vicinity of 4 hours, that was surprised to be  |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
.......decided to switch all to MCM until this problem of gigantic VINA with little points is solved....tired of micro-manage and deleting all Vina, sometimes get caught out overnight with a re-send running High Pri and wasting hours 'n hours for little to show!
 |
||
|
|
Chris Holvenstot
Cruncher USA Joined: Aug 26, 2011 Post Count: 19 Status: Offline Project Badges: 
|
This just keep getting better and better </sarcasm>
----------------------------------------I had made the decision to hold off on accepting new FAAH jobs until the issues were resolved, but to allow those already in my work queue to execute (or not) in a normal fashion. I looked at the overnight harvest of tasks with 131 errors and discovered that several of them had already been through the mill on 2 or 3 other systems and had run for their 20 to 40 hours in each before getting the 131 error. I guess it makes sense. What does not make sense is why these jobs were allowed to bounce around all weekend. Could not have the technical staff jumpped in and issued a server-side abort? [Edit 1 times, last edit by Chris Holvenstot at Sep 22, 2014 11:42:08 AM] |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
If you'd read the thread you'd seen the message by seippel half a dozen up, posted at 11:15pm on september 21, to say from that point forward all new and resents were being issued with a bigger file allowance: http://www.worldcommunitygrid.org/forums/wcg/viewpostinthread?post=469576
----------------------------------------Guess this was the first point to jumpp in, or the first point of realization, that the 'rare' incidence was not so rare  [Edit 1 times, last edit by Former Member at Sep 22, 2014 12:56:23 PM] |
||
|
|
|