You mean I did all that math for nothing??? :D

---

PROUD MEMBER OF Team Starfire World BOINC

What is the consequence of dropping the flops entry in app_info?

Very little to none. Your initial estimates for time required for tasks will be off, but BOINC figures them out soon enough. They're not very accurate anyway. I quit entering values for flops and platform in app_info.xml quickly. With a mix of machines running 32 and 64 bit operating systems with varying CUDA capability, I found it to be WAY more trouble than it's worth.

That's what I thought too, and ditto - I deleted the entries as well.

But it seems BOINC downloads way too many WUs for the report deadline, so I don't think it's working the way I'd like.

I will monitor this and furter lower my value for the work cache.

Morten

---

Morten Ross

What is the consequence of dropping the flops entry in app_info?

Very little to none. Your initial estimates for time required for tasks will be off, but BOINC figures them out soon enough. They're not very accurate anyway. I quit entering values for flops and platform in app_info.xml quickly. With a mix of machines running 32 and 64 bit operating systems with varying CUDA capability, I found it to be WAY more trouble than it's worth.

That's what I thought too, and ditto - I deleted the entries as well.

But it seems BOINC downloads way too many WUs for the report deadline, so I don't think it's working the way I'd like.

I will monitor this and furter lower my value for the work cache.

I am running with zero "connect about every" and three "additional work buffer" using 6.6.20 on various versions of Windows and Linux. It seems quite accurate relative to the problems 6.4.x had.

---

--
Classic 82353 WU / 400979 h

What is the consequence of dropping the flops entry in app_info?

Very little to none. Your initial estimates for time required for tasks will be off, but BOINC figures them out soon enough. They're not very accurate anyway. I quit entering values for flops and platform in app_info.xml quickly. With a mix of machines running 32 and 64 bit operating systems with varying CUDA capability, I found it to be WAY more trouble than it's worth.

That's what I thought too, and ditto - I deleted the entries as well.

But it seems BOINC downloads way too many WUs for the report deadline, so I don't think it's working the way I'd like.

I will monitor this and furter lower my value for the work cache.

Morten

It really doesn't matter what absolute value you put in. What makes a difference are the relative speeds of the different applications on your particular hardware - both CPU and GPU.

The quote from Andy above says 'BOINC figures them out'. Not quite true: BOINC will try to figure them out, but will keep getting four different answers (AP, AP_v5, MB/CPU, and MB/CUDA). In particular, if you don't put in the CUDA speed, BOINC will assume that it runs at the same speed as your CPU. Not if it's a decent CUDA card, it won't be. So a run of CUDA task completions will drive BOINC's estimate downwards: in its naivety, BOINC will assume that AP is as optimised as your CUDA card, and will over-fetch. Then an AP task will finish, BOINC will switch to a different estimate - and won't fetch any more work for possibly days. For anything.

The object of the calculations is to avoid these wild lurches in Duration Correction Factor. They don't have to be exact, but the easiest way to get the decimal point in the right place is to paste <p_fpops> into Windows Calculator and paste the result back. It really doesn't take long, and you only have to do it once per machine - once per class of machine, if you have at least some which are broadly similar. Believe me, a little bit of effort here keeps the work flowing smoothly and efficiently for a long time to come - my productivity has greatly increased since I first posted a version of this procedure at Beta six weeks ago.

There are moves afoot to include separate DCF calculations for the separate applications in a future version of BOINC - at which point you can all put calc.exe away again - but that won't be until at least BOINC v6.8, and so far as I know they haven't even started work on that yet.

Thanks for the clarification Richard.

When Mark posted his app_info.xml file I too wondered what all that was about. I went through all the calcs and have created separate directories on the server for each machine in my inventory. Looks like the only change I will have to make will be with the graphics card calcs as they will likely be the only thing changing for a while.

G

---

Boinc Wiki




"Great spirits have always encountered violent opposition from mediocre minds." -Albert Einstein

Ok, I have an 8500gt that is estimated at 5 GFLOPS. When I report 6.08s it drags the time to completion of the APs down. So, I should raise the GFLOP in my app_info for the GPU ? Maybe refigure for 6GFLOPs instead of 5?

By the time I've finished an AP V5 I've turned in so many 6.08s the Time to completion guesstimate on the rest of the APs are down to around 12 hours. It really takes me about 60 hours each. Also, when the APs do report it jumps the time for the 6.08s up to around 20 hours and the APs to upwards of 100 hours. I'm sure I did the math right but this is really confusing.

---

PROUD MEMBER OF Team Starfire World BOINC

Ok, I have an 8500gt that is estimated at 5 GFLOPS. When I report 6.08s it drags the time to completion of the APs down. So, I should raise the GFLOP in my app_info for the GPU ? Maybe refigure for 6GFLOPs instead of 5?

By the time I've finished an AP V5 I've turned in so many 6.08s the Time to completion guesstimate on the rest of the APs are down to around 12 hours. It really takes me about 60 hours each. Also, when the APs do report it jumps the time for the 6.08s up to around 20 hours and the APs to upwards of 100 hours. I'm sure I did the math right but this is really confusing.

This is what I don't understand in the real world. As Richard posts, DCF should be going all over the place because of CUDA 608s vs CPU AP v5s. As I noted elsewhere, the DCF on some of my CUDA capable machines is as low as 0.02. But BOINC 6.6.20 does not go crazy with downloading APs. Thankfully, but I don't understand why not.

The real fix, as Richard also posts, will be to have separate DCFs for each application.

---

--
Classic 82353 WU / 400979 h

What final flops figures are you using for AP, AP_v5, MB603 and MB608?

Claggy

Why does CPU-Z say I have SSE3 and Boinc says SSE2? Which is the correct I wonder...

Why does CPU-Z say I have SSE3 and Boinc says SSE2? Which is the correct I wonder...

CPU-Z should be Correct, Boinc only reports what the OS reports.

Claggy

Sorry, had to wait for one to finish before I stopped SETI.

My PFPOPs 1851545749

Est. GFLOPs 5Gflops

AP 5.00 4194755270

AP 5.03 4847272757

MB 6.03 3269311494

MB 6.08 1000000000

---

PROUD MEMBER OF Team Starfire World BOINC

The figures you posted are correct, double check your app_info figures,
but i assume you got them from there, so it should't be different,
on my E8500, AP_v5 tends to drive completion times down,
while MB608 eithier drives completion times up or down depending on the AR,
and you're running a VLAR killer, so they won't be driving completion times really high,
Must be something to do with the GPU being very slow, compared to MarkJ's,
I'd try lowering the GPU flops figure first, say 800000000
Put this in a cc_config.xml and monitor what dcf is doing first:

<cc_config>
<log_flags>
<dcf_debug>1</dcf_debug>
</log_flags>
</cc_config>

Claggy

Ok, a cuda task finished. This is the DCF

4/19/2009 5:47:04 PM SETI@home [dcf] DCF: 0.576175->0.528535, raw_ratio 0.099773, adj_ratio 0.173164

and a 6.03 finished with this dcf

4/19/2009 5:51:17 PM SETI@home [dcf] DCF: 0.528535->0.523195, raw_ratio 0.475133, adj_ratio 0.898962

and another 6.03

4/19/2009 6:04:16 PM SETI@home [dcf] DCF: 0.523195->0.516565, raw_ratio 0.456895, adj_ratio 0.873279

---

PROUD MEMBER OF Team Starfire World BOINC

Well you dcf is getting driven down, should end up around 0.2,
you might find particular AR's drive it and completion times back up a bit,
just monitor it for now, let us know what astropulse does,

Claggy

Edit: your CPU time spent feeding the GPU is 4 times what mine is (9800GTX+ on PCI-X 16), i wonder what difference that makes?

It may take awhile before I get to another Astropulse. I got swamped with a bunch of 6.03s while ttc was down. I'd like to clear some of them out before I do another AP. As I said, the Astropulse takes me 60+ hours to complete.

---

PROUD MEMBER OF Team Starfire World BOINC

....but you'll need to do the cpu flops numbers as I don't have access to your <f_pops> figure.

<p_fpops> (sic) for a Core2 is often very close to the speed in GHz. My E5320 is showing <p_fpops> = 1828798802.551730 - and with a Xeon, there won't be any overclocking to worry about.

And Morten's E5320 Windows 7 host shows "Measured floating point speed 1807.52 million ops/sec" which indicates a <p_fpops> of 1807520000. Six digits of accuracy is more than ample.

                                                               Joe

Im running an app_info very similar to the one featured in this post. I have upgraded to 6.6.20 in the hope of finally being able to stop micro-managing all my hosts, but Im still having problems with CUDA/AP units. Im running a dual core with a 8800GT and ideally would like the CPU to crunch AP only while the GPU crunches MB units. I have set max_cpu to 3 previously, should I be undoing this in 6.6.20. I am running all the latest optimised apps
I keep getting in from work to find myy host crunching 3 AP units on 2 cores with the GPU idle.
What is the best way to resolve this please?

On another seperate note, is there a problem with BOINC stats or the berkley databases as I have had a total of 450 approx units credit from SETI???

http://boincstats.com/stats/boinc_user_graph.php?pr=bo&id=1405036

Thx for the help

---

I have set max_cpu to 3 previously, should I be undoing this in 6.6.20.


On another seperate note, is there a problem with BOINC stats or the berkley databases as I have had a total of 450 approx units credit from SETI???

Definitely get rid of the max_cpus setting. BM 6.6.20 has this function built in.

As for the stats, they are pulled from the replica database which has been down several days for repairs.

---

--
Classic 82353 WU / 400979 h

I have set max_cpu to 3 previously, should I be undoing this in 6.6.20.


On another seperate note, is there a problem with BOINC stats or the berkley databases as I have had a total of 450 approx units credit from SETI???

Definitely get rid of the max_cpus setting. BM 6.6.20 has this function built in.

As for the stats, they are pulled from the replica database which has been down several days for repairs.

Actually there might be further confusion here. The max_ncpus [sic] setting is in app_info.xml and is typically around 0.1 - this is used for feeding the GPU data. A setting of three sounds more typical for the ncpus [sic] setting in cc_config.xml which is the one that is no longer necessary. Get rid of cc_config.xml entirely unless you are using it for debugging purposes.

---

--
Classic 82353 WU / 400979 h

Ok..
Cheers for the help, will apply the changes when I get in tonight.
Thanks again

---