Cio,

I'm stumped as to why 1 machine does perfect with 5.8.2 and the other on 5.8.2 does not.... it pulled 10-again and is depleting them and will deplete them fully before tomorrows lunchtime whilst buffer was set to 5.0 just for the exercise..... the DCF continues to drop, so maybe there is as tilting point, plus changing that 6.25 to 100 andhitting update might do the trick...... patience patience.

U choosing WCG as your sole project is definitely the best news to a WCG-CA of the day.

ciao

By grabbing 10 wu and not getting any more before empty, it can seems like you're overcommitted... One possibility is by using too large cache-size, BOINC often doesn't like if cache-size > 1/2 deadline...


V5.8.2 has many logging-capabilities, to enable detailed logging of work-request-decisions, make a text-file called cc_config.xml, and place it in main BOINC-directory.

cc_config.xml should include atleast this, but can also include more flags:

<cc_config>
<log_flags>
   <rr_simulation>1</rr_simulation>
   <work_fetch_debug>1</work_fetch_debug>
</log_flags>
</cc_config>

After saving this file, in BOINC-Manager Advanced view, select Advanced, Read config file.
With v5.8.1 and later, you do not need to stop BOINC core client any longer to enable/disable debug-flags.

To disable, edit cc_config.xml again, and change the ones to zeroes, and use BOINC-Manager again to re-read config.file.


If a project isn't contactable, work_fetch_debug will show this, and should also show why it's not contactable...

Hmm, if you haven't typed-it in yourself, no idea why you've got 6.25%, it's possible WCG has made an :oopsie: but default should be 100%.


In any case, the full text for these preferences are:
"Use at most N percent of CPU time"; Enforced by version 5.6 and greater. (default 100%)
"Use at most N % of memory when computer is in use"; Enforced by version 5.8 and greater. (default 50%)
"Use at most N % of memory when computer is idle"; Enforced by version 5.8 and greater. (default 90%)


WCG is apparently only using #1 and #3 of these...


But basically, with a setting of 6.25% CPU time, you'll crunch roughly 1 second, and be idle 9 seconds...

I think I'm seeing some light here. I'm running FAAH too as sole project on the resisting machine, the other one does not run FAAH, just HDC and GC. There were duration estimate changes made late last week, coinciding with me upgrading to 5.8.2.... did something go awry there?

15-1-2007 20:29:57|World Community Grid|[rr_sim] result faah1235_d112n854_x2BPZ_01_1 finishes after 25726.520504 (20865.772013/0.811061)
15-1-2007 20:29:57|World Community Grid|[rr_sim] result faah1235_d112n854_x2BPZ_01_1 misses deadline by 88402.631325
15-1-2007 20:31:05||rr_simulation: end; total shortfall 629778.597587
15-1-2007 20:31:05||[work_fetch_debug] compute_work_requests(): cpu_shortfall 629778.597587, overall urgency Need

Definitely the best diagnostic tip for baffled BOINC users.



Update: Attached the machine to SIMAP (periodic project), and it started pulling down work without much ado, confirming the install is not thinking it's overcomitted.

Yes, as long as a project has one or more "misses deadline", BOINC will not ask the same project for more work, except if you've got an idle cpu...

But, as long as expected run-time of all cached work isn't larger than cache-size, you can still ask another project for more work, as Sekerob successfully did.



As for why BOINC thinks "misses deadline", not sure, but let's try...
Now, 5 days = 120 hours.
You're using a 2.5 days cache? this is 60 hours.

120 hours - (60 hours + 24 hours (safety)) = 36 hours till work must be finished.

Also, according to rr_sim, the result will take 168168 seconds, or 46.7 hours.

Since 46.7 h > 36 hours, you've missed the deadline...


But, to get 46.7 hours run-time, rr_sim also used 0.140175, and I'm not quite sure how this is calculated...

Hmm, a quick test, if all cpu's active and no cached work, rr_sim uses on_frac * active_frac * cpu_efficiency, so far so good...

If 1 other runnable result for another project with same resource-share, switched to 1/2 and 1/2...

... So, other projects? Or low active_frac, on_frac or cpu_efficiency? These are in client_state.xml, and is close to 1 if crunches 24/7 and computer not doing any other cpu-intensive work.



Anyway, just as a "fun" calculation at the end, not exactly sure if it's completely correct, but for someone trying to run with a 5-day cache, you'll likely get:

7 days deadline - (5 days + 1 day safety) = 1 day till deadline.

In other words, the second expected run-time is over 1 day on client, you've being blocked from asking for more work from this project...
... Or maybe even earlier, since to be on the safe-side, client expects the estimates is a little worse to guard against wrong estimates...

With a 2-day cache on the other hand:
7 days deadline - (2 days + 1 day safety) = 4 days till deadline.


So, surprisingly, you'll likely have a larger cache of WCG-work if cache-size is set to 2 days, than if you set it to 5 days...