Just missed deadline to edit previous post ;)

*new feature of CPU-Z* - CPU-z has a new feature - allows you to post your CPU stats to a website - (Don't worry - this is voluntary, you must actually go to a website and submit your info, so if you DON'T want it, it won't happen. Nothing is sent by cpu-z to anywhere)

However you can then post a URL to your CPU statistics for others to see like so.

Chicken,

A question for you...I've read that the different angle used can cause the WU computation time to change. Is this a somewhat linear function? That is, could a table also be developed that would help in DCF predition based on the angle(s) to be searched in a given WU?

Where does one find his duration correction factor?

---

Where does one find his duration correction factor?

c:\\programfiles\\boinc\\clientstate.xml file. there should be one DCF for each project you're attached too. NOTE: don't save the file if boinc is running when you exit the text editor.

Where does one find his duration correction factor?

c:\\programfiles\\boinc\\clientstate.xml file. there should be one DCF for each project you're attached too. NOTE: don't save the file if boinc is running when you exit the text editor.

Or, somewhat easier to find, on the computer’s Host page for each project it’s attached to.

---

The CPU-Z validator is a pretty nice idea, makes it very simple to share your exact configuration.

My P-D 805 is here.

To make it easier for people, this is how you can submit your computer's details:
Start up CPU-Z by double-clicking it (download from here). When the window opens that shows your computer's details, press F7. It will save a file called xxxxx.cvf. Go to this page, enter your details, point it at the .cvf file you just created and submit it, done.

I'd recommend using the host page provided by each project instead of the xml file to check out your DCF.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

I've read that the different angle used can cause the WU computation time to change. Is this a somewhat linear function? That is, could a table also be developed that would help in DCF predition based on the angle(s) to be searched in a given WU?

It's not very linear, see the table in the Enhanced FAQ, and that's based on the formulas which the splitter uses to produce the rsc_fpops_est.

If those estimates happened to match the curve for any particular system, that system would have a fairly stable DCF. In practice, the curves are only good enough that DCF fulfills it's design goal of ensuring hosts don't get too much work.

                                                          Joe

Thanks, Mmci and Odysseus.

---

Update on my Northwood: DCF is currently at 0.477 but sort of varies around .5

---

My DCFs range from about 0.66 to about 1.8.

---

BOINC WIKI

My P-D 805@3.85 GHz is fluctuating between 0.27 and 0.42, depending on the WUs it gets. My intention behind asking for DCFs is twofold - first, it only gets listed for your own hosts, so asking is all I got ;)

Secondly, I wanted to compare relative platform efficiency of my apps, which works pretty okay using DCF. It does fluctuate more than RAC or other performance measures, but I believe it is a metric that's more useful than anything credit-based.

What has been shown through the DCFs posted is that Pentium-M and Core / Core 2 CPUs are most efficient at crunching S@H. This is true for optimized as well as stock apps. The ones with the largest speedup over stock are Pentium-Ds and recent P4s. AMD machines do not gain as much speedup, but then they are quicker crunching with the stock client than P4-based Intel parts.

Also, I've tested what RAM settings can do for or against performance - keeping my DDR2-667 at the settings selected automatically vs. manually selecting the quickest stable timings -

same clock speed, RAM set to default (5/5/5/17/2T)
67.24 credit WUs - ~12500-13000 seconds

RAM set to tight timings (4/4/4/14/1T):
10300-10600 seconds

No other settings were changed.

I was astonished because the CPU shouldn't have been RAM bandwidth-starved (it runs @ 775 external, RAM runs at 667x2 dual channel and should have more bandwidth than necessary...then I remembered my P-D has 2 CPUs, not one).

So it was actually very much bandwidth-starved and is now ~20% quicker just because I used quality RAM (Corsair) and tweaked it a bit (actually, switching from 2T to 1T got the most performance, timings helped too).

The same is true on AMD systems, although to a lesser degree as they have much more available RAM bandwidth - my A64 S939 with DDR400 still gets way higher bandwidth scores than my P-D with DDR2 667, partly also due to the fact that on A64s/Opterons the RAM bandwidth scales with the clock speed.

My highest DCF is 1.45 on an AMD Duron 800.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Trying to get a feel for how much and how the DCF varies, I started logging my dcf every two hours last Friday, using a little script that greps the dcf from the client_state file to a csv formatted file that's easily included in a spreadsheet program. I quickly noticed the exponential decay, and then the sudden jumps up as a short WU came up. Yesterday and this morning my computer had some other things to do, so it wasn't available for seti for awhile. Around this time, I also happen to notice quite a big jump up in the dcf: whereas I'm normally around or below .5 it was now briefly over .8. Here's how my dcf has progressed over the last 65 hours or so (and I'll keep monitoring):



That sudden jump up after not crunching for a bit is probably a coincidence, as boinclogx history also shows three WUs finishing early this morning which ran for only a little over a minute each (this being one of them, which seems to have finished succesfully, yet with some overflow errors). Or does the dcf somehow relate to the total elapsed (as opposed to CPU) time taken for WUs (which makes sense if you're basing cache sizes and work overcommitment etc. on it)?

---

The dcf changes when a unit is reported, if the time was shorter than predicted the dcf is lowered so that the predicted time of the time of the next unit is lowered by 10% of the difference. If the processing time is longer then the dcf jumps so the next unit, if of similar angle_range, is predicted to take the same longer time.

JM7 designed it, before enhanced, when most units took about the same time to crunch, with enhanced it is a bit more complicated because the angle_range also affects the crunch time.

It would appear that at high AR's Intel and AMD cpu's behave differently and I suspect yours are AMD's as you a seeing a big jump for the high AR (short) units.

My Pent M has stayed at 0.4 +/- 0.03 for the last couple of weeks.

Andy

I suspect yours are AMD's as you a seeing a big jump for the high AR (short) units.

It's an Intel (a Northwood to be exact). Which is why I was so surprised to see it jump that high. Of course I happened to get three of those very short units right after each other, which can't have helped.

I guess the morality of the story is that if you post your DCF here to find the minimum DCF, it might pay to keep an eye on the value for a while, as it might vary considerably (so you can pick your lowest to look good...).

I'm wondering what it is we're benchmarking anyway: the speedup seti cruncher can get with respect to a generic benchmark, or the benchmark itself behaving differently on different types of cpus... ;)

---

The DCF is based on the fpops estimate as given by the server, and for the different angle ranges of S@H, the fpops estimate is different. If the estimates were scaled perfectly for each result, the DCF would not change - even though the run times did vary greatly.

Example:

Initial DCF = 0.5

First result - uncorrected time estimate 1 hour - corrected time estimate 30 minutes - actual time 30 minutes. DCF unchanged.

Second result - uncorrected time estimate 100 hours - corrected time estimate 50 hours - actual time 50 hours. DCF unchanged.

Third result - uncorrected time estimate 100 hours - corrected time estimate 50 hours - actual time 40 hours. DCF = .5 * .9 + .4 * .1 = .45 + .04 = .49

---

BOINC WIKI

I just added This computer a few days ago, and it already has a DCF of 0.646927.

---

For those interested, here's how my dcf varied over the last week. You can clearly see it raise suddenly as a short WU came by, and then decaying exponentially afterwards as regular WUs are being processed which have a better benchmark-to-compute-time ratio. During this week (all in the beginning actually), my highest dcf was .834425 and the lowest .454350 (quite a large range), though if I were not to get any short WUs anymore, it looks like it might drop to about .40.

---

My brand new Conroe rig is currently showing a dcf of .262831, been online for less than 3 days. Is running much better since I pulled back on the overclock and stopped getting errors on every other wu. Yowza! Oh, and BTW, this is courtesy of Mr. Chicken and his Seti BBQ apps. How about it, Mr. Chicken, stand up and take a bow (did you ever figure out if SSE4 was worth pursuing for Seti crunching)?

---

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

Hiya,

I have an SSE4 version compiled, but so far have not had any test results from my one tester with access to Woodcrest/Conroe systems.

So if you want to test that version, head on over to my site, register and I'll bump your access so you can see the test app boards and downloads (either email or msg me your username after registering).

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Hiya, yourself. I just registered on Zadra under msattler. How may I serve you (or, I guess, the common good of all Seti crunchers)?

---

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

Now .256576 and still dropping, I think.

---

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