| 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 |
|
|
Sgt.Joe
Ace Cruncher USA Joined: Jul 4, 2006 Post Count: 7844 Status: Offline Project Badges: 
|
The 64.8 points awarded wu seems to be wu that were returned after deadline. I do not think that is correct. Mine was returned several days before the deadline, unless there is some weird setting in the WU itself which gives a deadline different than the 10 day deadline. Also I decided to edit the <p_fpops> setting after shutting down BOINC, but I must have done something wrong because after I restarted BOINC the four existing jobs immediately went to "computation error." I used notepad for the edit and kept it as an xml file. Oh. well, I tried Cheers
Sgt. Joe
*Minnesota Crunchers* |
||
|
|
BobCat13
Senior Cruncher Joined: Oct 29, 2005 Post Count: 295 Status: Offline Project Badges: 
|
Also I decided to edit the <p_fpops> setting after shutting down BOINC, but I must have done something wrong because after I restarted BOINC the four existing jobs immediately went to "computation error." I used notepad for the edit and kept it as an xml file. Oh. well, I tried Cheers Don't edit the <p_fpops> as that is your benchmark value. If you haven't already done so, you need to run benchmarks to get that value set back to the correct number. You need to edit the <rsc_fpops_bound> entry on each FAHV task that the client currently has. The easiest way I have found is to open the client_state.xml in Notepad, use the Edit - Find option to search for worldcommunitygrid which will take you to the beginning of the WCG section, then use Find again to look for workunit which will locate the first workunit section under WCG. If it is a FAHV task, change the <rsc_fpops_bound> , then click Find Next until you have gone through all of the WCG tasks on hand. [Edit 2 times, last edit by BobCat13 at Sep 10, 2014 3:41:28 PM] |
||
|
|
BobCat13
Senior Cruncher Joined: Oct 29, 2005 Post Count: 295 Status: Offline Project Badges:
|
The 64.8 points awarded wu seems to be wu that were returned after deadline. I have some too. I still believe it is in the system to catch people trying to cheat when they claim too many credits, but it ends up penalizing honest users when these really long tasks arrive as the high hours X avg. credit per hour causes the claim to be above whatever value WCG has set as the outlier value. Once you claim above that outlier value, it gets automatically changed to the 64.8 as punishment for trying to cheat even though you may not be cheating. |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
If ever you want to mess up the client_state, do it when you've totally exited the core-client, speak boinc.exe i.e. is truly not in memory, or the agent will do it for you. It writes to that file, the name betrays the function, the client_state, every few seconds. When another process has the file open/locked, you get, ahum, garbage.
|
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
Hi.
I'm not one to complain about credits but this is unacceptable, both tasks were singles & run times are about the same on same rig. FAHV_ x3VQA_ IN_ LEDGFa_ rig_ 0222553_ 0051_ 0-- Intel-i7-2700K Valid 9/7/14 05:38:26 9/10/14 22:10:04 21.53 / 21.90 64.8 / 64.8  FAHV_ x3VQA_ IN_ LEDGFa_ rig_ 0222553_ 0064_ 0-- Intel-i7-2700K Valid 9/7/14 05:38:26 9/10/14 22:10:04 20.01 / 20.35 578.5 / 578.5 |
||
|
|
Sgt.Joe
Ace Cruncher USA Joined: Jul 4, 2006 Post Count: 7844 Status: Offline Project Badges:
|
Also I decided to edit the <p_fpops> setting after shutting down BOINC, but I must have done something wrong because after I restarted BOINC the four existing jobs immediately went to "computation error." I used notepad for the edit and kept it as an xml file. Oh. well, I tried Cheers Don't edit the <p_fpops> as that is your benchmark value. If you haven't already done so, you need to run benchmarks to get that value set back to the correct number. You need to edit the <rsc_fpops_bound> entry on each FAHV task that the client currently has. The easiest way I have found is to open the client_state.xml in Notepad, use the Edit - Find option to search for worldcommunitygrid which will take you to the beginning of the WCG section, then use Find again to look for workunit which will locate the first workunit section under WCG. If it is a FAHV task, change the <rsc_fpops_bound> , then click Find Next until you have gone through all of the WCG tasks on hand. Well. I did one thing right which was to exit everything before I tried this. However, if I get another of these long units I will follow these instructions explicitly and have another go at it. Thanks Cheers
Sgt. Joe
*Minnesota Crunchers* |
||
|
|
Sgt.Joe
Ace Cruncher USA Joined: Jul 4, 2006 Post Count: 7844 Status: Offline Project Badges:
|
The 64.8 points awarded wu seems to be wu that were returned after deadline. I have some too. I still believe it is in the system to catch people trying to cheat when they claim too many credits, but it ends up penalizing honest users when these really long tasks arrive as the high hours X avg. credit per hour causes the claim to be above whatever value WCG has set as the outlier value. Once you claim above that outlier value, it gets automatically changed to the 64.8 as punishment for trying to cheat even though you may not be cheating. Well, that outlier value is not set correctly for at least some of these units. Cheers
Sgt. Joe
*Minnesota Crunchers* |
||
|
|
OldChap
Veteran Cruncher UK Joined: Jun 5, 2009 Post Count: 978 Status: Offline Project Badges: 
|
23-27 hours on intel E5-v2 @3.1. The actual runtime is of no concern to me
----------------------------------------Predicted runtime has increased over the last few days from a normal of up to 2-3 hours to 19+hrs. Currently sitting on 300 wu's which represents around 2 days of normal cache for this rig. they are all deadline 4 to 5 days so at least half of these will miss. Normal average of ~32 pts per thread per hour is currently sitting at 5.3, which just proves to me how useless the current points implementation is.... Work more difficult = less reward. Just for added interest I also had a few of these on a similar rig running at 2.4 but with mixed work (mcm1) and the points average was 13-27 for those. I do not seem to have exceeded any time limits  |
||
|
|
Sgt.Joe
Ace Cruncher USA Joined: Jul 4, 2006 Post Count: 7844 Status: Offline Project Badges:
|
I did a little calculating on the one good unit I did complete. That machine usually gets 30+ points per hour on FAHV units. So a 24 hour valid unit should have gotten about 720 points (30 X 24). This must be higher than whatever outlier limit they have imposed, since I got the 64.8. Personally I don't care that much about the points, but I do care about accuracy.
----------------------------------------Cheers
Sgt. Joe
*Minnesota Crunchers* |
||
|
|
Former Member
Cruncher Joined: May 22, 2018 Post Count: 0 Status: Offline |
I just had one complete in a whopping 64+ hours on a XEON E5645 (FAHV_x3VQ8_B_IN_LEDGFa_rig_0221581_0034). A second took nearly 68 hours on a XEON E5520 (FAHV_x3VQ7_IN_LEDGFa_rig_0220723_0040).
|
||
|
|
|