I run off-line, connect only every couple of days, and use only one BOINC project per computer. On the QMC project, I have specified the "time between connects" as four days, but lately it has been taking my computer no more than two days to complete all the work that gets downloaded to its ready queue. [This even when the client has asked for 345600 seconds of work!]

One thing I notice about my "statistics" for this project is that currently my 'result duration correction factor' is shown as 4.0. I *am* running an optimized client (Linux, 5.2.14) -- but I feel there is NO WAY that my actual time-to-complete could be FOUR times as long as the time estimated from the benchmark values. [In my opinion, the optimized client gives me benchmark values no more than twice as good as what an un-optimized client would show.]

Could it be this excessive 'result duration correction factor' that is causing less than four days worth of work to be downloaded to my computer's ready queue?

How come QMC is assigning my computer SO LARGE a 'result duration correction factor' in the first place?
.

The normal Duration Correcion Factor in BOINC, checks how long results on your computer take. Since no result is sent out with a correct wall-clock time to what your computer does to calculate them, DCF recalculates per result how long they take.

With projects where results take about the same time, the DCF will eventually end at 1. Meaning it now knows the length of the unit and will ask work accordingly.

Using an optimised BOINC client, or science application, can cause those numbers to go off. Plus for more work, below 1 for less work.

Although, with the new upcoming 5.4.x (we hope .7) version of BOINC, this may go out the window, as I am running an optimized Einstein science app and I have a DCF of 0.24 there. Go figure. ;)

Check here what it should do.

---

The normal Duration Correcion Factor in BOINC, checks how long results on your computer take. Since no result is sent out with a correct wall-clock time to what your computer does to calculate them, DCF recalculates per result how long they take.

Although, with the new upcoming 5.4.x (we hope .7) version of BOINC, this may go out the window, as I am running an optimized Einstein science app and I have a DCF of 0.24 there. Go figure. ;)

Check here what it should do.

Thank you. I had already viewed the wiki article before posting.

Neither it, nor what you write, explains to me WHY the calculated 'result duration correction factor' was SO HIGH for my computer. According to the wiki description, if my benchmark number were "correct", a 'result duration correction factor' of 4.0 means that work on my computer was estimated to take ONE QUARTER of the time it actually took. Looking at the results of similar work reported by other participants, NO ONE finished work units 75% faster than me - the best I ever saw (from a much more powerful computer) was 60% faster in elapsed time.

That raises the question of how misleading was my benchmark value. With the optimized 5.2.14 client, the BOINC benchmark (see the wiki) reported floating point operations value was 2226. With a 5.4.7 client, that value was 1027. To me, that difference demonstrates the "Linux penalty" built in to the non-optimized BOINC client. [I __realize__ that the ACTUAL performance is determined by the project application run on the client computer, and is INDEPENDENT of the value reported by the BOINC benchmark.] My point is that if I had been running with the un-optimized BOINC client, the calculated 'result duration correction factor' would still have been inappropriately HIGH (e.g., 1027/2226 * 4 = 1.8).

Nothing said in the wiki contradicts my concern that it was the TOO HIGH 'result duration correction factor' that prevented the server from downloading enough work to fill my "time between connects" specified queue size. If this is what happened, project administrators need to be WARNED that TOO HIGH a 'result duration correction factor' can __spoil__ the ("time between connects") queue size specified by users.
.

It may be a "feature" of your optimised client.

My Duration Correction Factor for QMC is 4.8 . The reason is that the completion time estimate for that project is way off the mark and Boinc is compensating for this error to have the correct time on new WU. Just take a look at this QMC thread

---

Boinc V 7.4.36
Win7 i5 3.33G 4GB NVidia 470

I am running SETI. Question, is it normal for the completion time to increase along with the CPU run time? I have one running now (04ap05aa.7473.16023.184644.3.80_1) for 34 hours and the completion time is 11:45 minutes. The seconds are increasing.

As an additional commit: over the last month or so, the amount of time to complete a unit has increased. The question is, what is the actual credit result of the longer duration units compared to the shorter runtime credit units

---

I am running SETI.

Ask questions like that on the Seti forums next time, or read its Number Crunching forum, more in particular the Seti Enhanced FAQ. It will answer a lot.

---