Projects with short deadline sometimes give me this :

Message from server: (won't finish in time) Computer on 100.0% of time, BOINC on 100.0% of that, this project gets 11.4% of that

Of course that's complete nonsense. The server doesn't know how much shares a project gets as it obviously doesn't know which projects are allowed to work.

The example above is taken from a project that gets 100% with no other project competing for the CPU time.

There are other projects on that box - but currently not working

It depends on the latest DCF reading. Edit the DCF for that project in client_state.xml and it'll get work again. Yes, even if it's the only project allowed to get work.

But do tell, which BOINC version are you using on that computer for that project only?

---

You're right, the latest WU series does have a correction factor mismatch (compared to previous series) - but the crunching boxes are supposed to crunch so they don't have monitors attached. Some are on a KVM so I could edit the client_state file - but the concept of making the server decide about the deadline with not enough information about the client settings isn't such a good idea so it should be fixed on server side (that project uses 509 / APS@Home).

... But do tell, which BOINC version are you using on that computer for that project only?

It's 5.2.12tx36, a team mate updated his BOINC as he wanted to work in Hydrogen@home and he has nothing but trouble with the client side scheduler. The BOINC version terror isn't a good thing anyway, set&forget, not install and update and update and update ...

YIt's 5.2.12tx36, a team mate updated his BOINC as he wanted to work in Hydrogen@home and he has nothing but trouble with the client side scheduler. The BOINC version terror isn't a good thing anyway, set&forget, not install and update and update and update ...

Well, one thing different, it's not a BOINC version. It's a Truxsoft version.
You can ask him to upgrade to a 5.8.16 version (not 5.10 please) and to edit his client_state.xml file so the DCF resembles something like <duration_correction_factor>1.000000</duration_correction_factor> (I set mine lower, to 0.668142 to be fine with it).

The old 5.2 versions of BOINC (And Truxoft or how you spell it) lack the better work request scheduler software of 5.4 and 5.8. Perhaps an update is needed.

---

I am aware that tx36 is not a Berkeley version but the TruXoft version seems not to have any differences in the DCF handling (on some boxes I still use 4.19 btw., firewall authentication problems with later ones)

The DCF is volatile, set it to a certain value and the core client will adjust it upwards immediately or downwards with 10% (or 1% in certain cases), so the estimated time sooner or later will match the real time.

But then a new WU series comes requiering a different DCF (caused by not matching FPOPS Estimated) and you've got the same problem again.

Adjusting the DCF is always only a temporary solution.

---

��u�

Adjusting the DCF is always only a temporary solution.

True and not one I advocate, but for in the extreme cases.

Yet trying to stay up-to-date on BOINC versions isn't bad either. A lot of projects already require a 5.8.x version of BOINC. The server backend is requested to be of the 5.10 variety. There's only so much time between now and BOINC 6.0, that won't allow you to run 4.x or 5.2.x versions of BOINC anymore and for you to find out what does and doesn't work.

And if it doesn't, then tell the devs where it doesn't work.

---