Now I can't get that damn Wizard of Oz song out of my head :oP

Anyway, you should now see an extra forum category with two boards inside it called "Pre-Release Applications".

Post to your heart's content, you may also find some info already posted informative.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

So previously I guessed that my dcf could go as low as .40 looking at the graph I posted. I thought I'd test that. Given the subsequent DCF values and the knowledge that 10% of the difference is taken (as so eloquently explained by WinterKnight earlier in this topic), it is of course easy to compute the real ratio for a certain WU by amplifying that difference by a factor 10 (only in case the DCF dropped of course: if it went up, just take the value itself, since then it's a short WU we're dealing with). This of course only works if exactly one WU completed between the times I measure the DCF (every 2 hours, and thereby not synced to WU completion), so it can also be the case that no WU completed (in that case the DCF remains the same, so there's no information, and in the graph below I basically just repeat the previous value), or that more WUs completed (in which case amplifying the difference gives way too low a ratio). Computing that for the dcfs I measured over the last week, gives the following graph:



Apart from a few high values (corresponding to short WUs) and a few very low values (corresponding to periods between measurements where more than 1 WU finished; I'm running 2 WUs simultaneously on at HT CPU after all), the rest of the values show a lot less variance, and thereby a prediction of what the dcf would be after stabilising in the absence of short WUs. The median of the values in the graph (which filters out the outliers discussed earlier) is .424885 so it turns out I was too optimistic with my estimation of .40 earlier.

---

Well, my new Conroe cruncher has been online for about 80 hours now. DCF is down to .232285 this morning, but it looks like it's about to munch through a batch of those pesky 'little' wu's, so that might be about as low as it's going to get, but I'll post again if it does anything fancy. Many thanks to the Chicken!

---

"Time is simply the mechanism that keeps everything from happening all at once."

Well, my new Conroe cruncher has been online for about 80 hours now. DCF is down to .232285 this morning, but it looks like it's about to munch through a batch of those pesky 'little' wu's, so that might be about as low as it's going to get, but I'll post again if it does anything fancy. Many thanks to the Chicken!

Really, the peskiest workunits are the ones with AR between about 0.6 and 1.0 degree. They only yield about 18 credits per hour per thread versus some 25 for an average. Some of those little ones at around 1.2 degree do pretty well, yielding over 30 for a Pentium D950. Maybe for a Conroe it's different.

---

Well, my new Conroe cruncher has been online for about 80 hours now. DCF is down to .232285 this morning, but it looks like it's about to munch through a batch of those pesky 'little' wu's, so that might be about as low as it's going to get, but I'll post again if it does anything fancy. Many thanks to the Chicken!

Really, the peskiest workunits are the ones with AR between about 0.6 and 1.0 degree. They only yield about 18 credits per hour per thread versus some 25 for an average. Some of those little ones at around 1.2 degree do pretty well, yielding over 30 for a Pentium D950. Maybe for a Conroe it's different.

Probably no different for a Conroe vs other Intel chips, may be different vs AMD processors. You are most likely correct. I have not really been looking at the AR of the wu's, I have just noticed that the ones with the shortest estimated 'to completion' times are the ones with the lowest return for time spent crunching.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Then there is the sample-to-sample variation: I saw three results, all sent in at about 1AM EDT, while I was sleeping, so I wasn't listening to internet fifties then. All had identical angle ranges and and credit. Their ID numbers varied by only nine, total. (I didn't look at their numbers from the tape because doing so would have meant writing down those long numbers.) But one took only 1607 seconds to do while the other two took 1924.

---

My new Conroe cruncher must have finally had a run of meaty wu's to munch on, got the DCF down to the lowest value I've had yet, .211084 but it's gone up a tad since then.

---

"Time is simply the mechanism that keeps everything from happening all at once."

Crunching with my new computer, I've got a DCF of 0.382063.

---

using chickens opt client on both

amd 4200 x2, 0.518
intel 3GHz HT, 0.333


interesting that the amd is alot higher...also, the benchs for the amd are alot lower on chicken app, than previously..


Cheers.

UPDATE. July 20th

They are now
amd 4200 x2, 0.468
intel 3GHz HT, 0.415

UPDATE. August 11th

AMD 4200 X2, 0.558
Intel 3GHz HT, 0.381
Intel 2.4GHz, 0.606

---

On my newer PC, my DCF is hovering around 0.67901.

---

I wish I could get My DCF that low, But I have AMD cpus, Their overclocked and My apps are Chickens and so I get a DCF of anywhere from 0.98 or so to maybe 1.23 or so. I'd love to see the DCF stay near 0.60 or so. If I've left something out and I may or may not have, please ask Me. As I'm not sure about that.

The way I understand DCF is that it is most desirable for having it at or near 1.0. This would mean no correction at all. I think the estimated time to completion sent by the server is multiplied by the DCF to arrive at the actual estimated completion time shown in BOINC. So a lower OR higher DCF than 1 means more correction is needed in the original estimate. Example, estimated completion time sent from the server is 1 hour. DCF-1. 1X1=1, your estimated time to completion in BOINC would show as 1. Now 1 hr from the server X 0.6 DCF = 0.6 hr or about 36 minutes. The server guesses way off! My DCF stays right around 1.06 which means that Berkeley is estimating my completion times almost right on the money.
I think the reason the question was asked in this manner is to see if the system needs modifications to get the estimates more in line with the actual times.

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

Currently my Conroe X6800 is at .284, my E6600 is at .234
Both are heavily overclocked.
The lower your DCF the better. It is an indication that your cpu is processing wu's faster than Boinc estimates you will, but I am not sure what the baseline is estimated from, maybe benchmark scores, but I'm not sure.
And the DCF will vary on a given computer considerably over time. If one of these systems processes a few wu's with a poor AR, they will jump up to the .39 range, and the slowly work back down after processing a number of wu's with good AR.

---

"Time is simply the mechanism that keeps everything from happening all at once."

My DCF is 0.418742...not sure if that's good or not, lower is better right?

---

Human Stupidity Is Infinite...

My DCF is 0.418742...not sure if that's good or not, lower is better right?

Yes, lower DCF's indicate more efficient wu processing, see my post below.
And yes, .418 is a pretty good DCF from what I have seen.

---

"Time is simply the mechanism that keeps everything from happening all at once."

It's really not about "good" or "bad" - it's about how much the BOINC estimates are off on how long your CPU and app will take to crunch a specific WU (as Jim-R. pointed out a few posts ago).

What it does tell you is how much less or more time, on average, your host takes to crunch WUs than BOINC estimates. These estimates are based on the benchmark scores AFAIK - other people have noted that Linux BOINC clients give much lower benchmark scores than Windows ones, further skewing DCF calculation (their DCF will be even lower).

Since BOINC uses the DCF, again AFAIK, to decide how much work to request, this may lead to problems (either too much work or dry cache, depending where your DCF is).

I do not have much data available on DCF from people using stock apps, though the project obviously does - this data is being used to generate new estimates for future S@H app versions (there was a sticky thread about this a while ago, if you recall).

Another point to note is that optimized applications may be quicker at most ARs but actually slower at some others, and this causes DCF to behave somewhat erratically (on WUs with short processing time, this behaviour is most pronounced).

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

I do not have much data available on DCF from people using stock apps, though the project obviously does - this data is being used to generate new estimates for future S@H app versions (there was a sticky thread about this a while ago, if you recall).

Well, here is a DCF for you from Linux running the stock Linux 5.12 app, 1.06 as of when I posted earlier. Specifically, 1.062378.
This is on a 950 mhz AMD Duron overclocked to 1015mhz with 256mb mem running Linux Slackware 10.2 (newest release).

---

Jim

Some people plan their life out and look back at the wealth they've had.
Others live life day by day and look back at the wealth of experiences and enjoyment they've had.

percentage time Boinc running = 91%
precentage time cruching while boinc running = 99%
Duration correction factor = 1.134778

5.4.9 with Crunch3r opt app.

I suppose if I had boinc running 100% the DCF would go down?

how is the time running calculated? I have boinc on automatic startup as windowws opens and never bother closing it, so does it calculat the amount of time the computer was turned off? since 11% sounds about right for transport etc of my laptop around the place.

I just noticed my cpu effiency is kind of low, 89.6%!

---

Human Stupidity Is Infinite...

My cruncher just hit

Result duration correction factor 0.387794

This doesn't make sense to me given that I'm taking ~1/2 as long to finish a WU as BOINC predicts, not ~2/5 or ~1/3 as long. Shouldn't my RDCF be ~.5?

---

My cruncher just hit

Result duration correction factor 0.387794

This doesn't make sense to me given that I'm taking ~1/2 as long to finish a WU as BOINC predicts, not ~2/5 or ~1/3 as long. Shouldn't my RDCF be ~.5?

The "To completion" time shown in BOINC Manager includes the RDCF. Because RDCF is designed to be near the maximum to avoid fetching too much work, actual completion times will typically be considerably less; 1/2 is not unusual.

If the shape of the estimation curves matched your system more closely, the RDCF would probably be lower and more stable. And the "To completion" times would be close to actual.

                                                              Joe