| 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 |
|
|
anhhai
Veteran Cruncher Joined: Mar 22, 2005 Post Count: 839 Status: Offline Project Badges: 
|
I personally have disabled FAAH from my project list. My systems can't handle these wide swings. Hopefully this issue will be resolved soon
---------------------------------------- |
||
|
|
Werinbert
Advanced Cruncher United States Joined: Jun 13, 2013 Post Count: 57 Status: Offline Project Badges: 
|
For what it is worth...
----------------------------------------I have an Intel Atom running one of these long work units. 108+ hours and only 40% done. At first I didn't think anything of the WU as normal vina WUs can run up to 4 days. Crossing my fingers that this WU gets done by the deadline.  |
||
|
|
Sgt.Joe
Ace Cruncher USA Joined: Jul 4, 2006 Post Count: 7844 Status: Offline Project Badges: 
|
Now I am seeing reports of over 100 hours so I wonder if the maximum seconds allowed is variable for these units. They seem to be rather scarce as I only have one more of these monsters running. I am going to let it run its course. I extrapolate it will take about 100 to 110 hours. If this one also gives me an error with "Maximum time exceeded" I will abort any further units of this type on the q6600. I will let them continue on the Xeon machine as that is much faster and should be able to handle them in a reasonable amount of time. There is no use running them if you already know they will error out because the machine is too slow.
----------------------------------------Cheers
Sgt. Joe
*Minnesota Crunchers* |
||
|
|
BobCat13
Senior Cruncher Joined: Oct 29, 2005 Post Count: 295 Status: Offline Project Badges: 
|
Now I am seeing reports of over 100 hours so I wonder if the maximum seconds allowed is variable for these units. The maximum runtime is determined by settings in the workunit template that is loaded into the client_state.xml when each task is downloaded, but it is fpops instead of seconds. For the FAHV tasks, the setting is: <rsc_fpops_bound>559664462780720.000000</rsc_fpops_bound> Near the beginning of the client_state.xml file is the fpops from when benchmarks are run. Mine looks like this: <p_fpops>2824852176.496806</p_fpops> So if we divide the <rsc_fpops_bound> value by <p_fpops>, we get the result of: 198121.681353 which is the number of seconds before the task reaches "Maximum time exceeded" on my machine. The number of seconds each machine has to finish will be different based on the benchmarks that machine produces. If anyone feels courageous enough to edit their client_state.xml file, they can extend the time allowed by adding extra numbers to the left of the decimal in <rsc_fpops_bound> for each FAHV task. Note: If editing the client_state.xml file, you need to stop the core client, edit the file, save the file, and start the core client again. [Edit 1 times, last edit by BobCat13 at Sep 10, 2014 3:44:23 AM] |
||
|
|
BobCat13
Senior Cruncher Joined: Oct 29, 2005 Post Count: 295 Status: Offline Project Badges:
|
And I finished one, but I guess it claimed too many credits and was marked as an outlier and got slapped down to the penalty credit setting.
----------------------------------------FAHV_ x3VQA_ IN_ LEDGFa_ rig_ 0222548_ 0035_ 0-- Valid 9/7/14 05:32:30 9/10/14 03:37:33 53.47 / 54.64 64.8 / 64.8 [Edit 1 times, last edit by BobCat13 at Sep 10, 2014 3:42:23 AM] |
||
|
|
David Autumns
Ace Cruncher UK Joined: Nov 16, 2004 Post Count: 11062 Status: Offline Project Badges: 
|
Anyone from IBM or the FAAH project team picked this up as yet?
----------------------------------------38 hours on a 4Ghz 8150 compared with a normal Vina WU of less than 3 hours !  |
||
|
|
Sgt.Joe
Ace Cruncher USA Joined: Jul 4, 2006 Post Count: 7844 Status: Offline Project Badges:
|
And I finished one, but I guess it claimed too many credits and was marked as an outlier and got slapped down to the penalty credit setting. FAHV_ x3VQA_ IN_ LEDGFa_ rig_ 0222548_ 0035_ 0-- Valid 9/7/14 05:32:30 9/10/14 03:37:33 53.47 / 54.64 64.8 / 64.8 Thanks for the info. It also seems strange that the number of points awarded for your unit is exactly the same - 64.8 - as the points for my successful unit and the points claimed for my unsuccessful unit. Now my brain is wondering about that also.  Cheers
Sgt. Joe
*Minnesota Crunchers* |
||
|
|
Eric_Kaiser
Veteran Cruncher Germany (Hessen) Joined: May 7, 2013 Post Count: 1047 Status: Offline Project Badges: 
|
I let them run. Even if a wu passes the deadline. The chance is very high that I'll return a result first. Status went/goes to 'pending validation'.
---------------------------------------- |
||
|
|
ryan222h
Senior Cruncher Joined: Sep 4, 2006 Post Count: 425 Status: Offline |
And I finished one, but I guess it claimed too many credits and was marked as an outlier and got slapped down to the penalty credit setting. FAHV_ x3VQA_ IN_ LEDGFa_ rig_ 0222548_ 0035_ 0-- Valid 9/7/14 05:32:30 9/10/14 03:37:33 53.47 / 54.64 64.8 / 64.8 Thanks for the info. It also seems strange that the number of points awarded for your unit is exactly the same - 64.8 - as the points for my successful unit and the points claimed for my unsuccessful unit. Now my brain is wondering about that also. Cheers I checked on my results status and there were a few work units that awarded 64.8 points regardless of run time. Of course in my case they seemed to be the longest running ones, had a few run 30 hours and get 64.8 points for for a rate of 2 points per hour.   |
||
|
|
Eric_Kaiser
Veteran Cruncher Germany (Hessen) Joined: May 7, 2013 Post Count: 1047 Status: Offline Project Badges:
|
The 64.8 points awarded wu seems to be wu that were returned after deadline. I have some too.
----------------------------------------For example: FAHV_ x3VQ7_ IN_ LEDGFa_ rig_ 0220639_ 0000_ 5-- - In Progress 08.09.14 05:30:33 11.09.14 17:30:33 0.00 0.0 / 0.0 FAHV_ x3VQ7_ IN_ LEDGFa_ rig_ 0220639_ 0000_ 4-- 716 Error 08.09.14 05:25:57 08.09.14 05:30:08 0.01 0.3 / 0.0 FAHV_ x3VQ7_ IN_ LEDGFa_ rig_ 0220639_ 0000_ 3-- 716 Error 08.09.14 05:14:10 08.09.14 05:25:17 0.01 1.7 / 0.0 FAHV_ x3VQ7_ IN_ LEDGFa_ rig_ 0220639_ 0000_ 2-- 716 Pending Validation 04.09.14 17:13:16 09.09.14 05:37:39 94.70 64.8 / 0.0 FAHV_ x3VQ7_ IN_ LEDGFa_ rig_ 0220639_ 0000_ 1-- 716 Error 04.09.14 17:03:21 04.09.14 17:12:56 0.08 0.5 / 0.0 FAHV_ x3VQ7_ IN_ LEDGFa_ rig_ 0220639_ 0000_ 0-- - In Progress 04.09.14 17:02:40 14.09.14 17:02:40 0.00 0.0 / 0.0 My result is the one with 'Pending Validation' status. This example also reveals that the deadline settings on resends is somehow ridiculous. The initial sending of this wu has a deadline on 09/14/14 while the resends have a deadlines before the origin deadline... So I missed the deadline on 9/9/14 and will be punished for that while the first recipient still has some days left... Another wu I've returned on time with a runtime close to the one above has a claimed credit of 468.1. |
||
|
|
|