Changing DCF on the fly

[Beyond]

Would it be possible to allow changing a projects DCF on the fly for a machine (much like can be done with debt)?  I run into frequent instances where a given task takes an inordinate amount of time and totally messes up the DCF which can then only be corrected by going to the machine, stopping BOINC and manually editing the DCF for the project, then restarting BOINC.  Of course this restarts any WUs that may have gone for hours without checkpointing

[fred]

Would it be possible to allow changing a projects DCF on the fly for a machine (much like can be done with debt)?  I run into frequent instances where a given task takes an inordinate amount of time and totally messes up the DCF which can then only be corrected by going to the machine, stopping BOINC and manually editing the DCF for the project, then restarting BOINC.  Of course this restarts any WUs that may have gone for hours without checkpointing

Depends on what they intend to do with the DCF.
The DCF has to be changed in the client_state.xml file. Stopping the client -> change the value -> Start the client. Not something to think lightly about.
The Rescheduler can do this for you http://www.efmer.eu/forum_tt/index.php?topic=439.0 But only for the Seti projects.
The DCF is something you better not change, there is a server based value also, to make it more interesting. So adjusting the DCF may work counter productive to the automatic client and server based system, how badly they sometimes work.

In projects that allow a app_info.xml you could set a <flops> statement and tell the project how fast the machine really is.

To make matters more interesting, in the new BOINC 6.13 the debt system is gone. They seem to have started from scratch...

[Beyond]

Would it be possible to allow changing a projects DCF on the fly for a machine (much like can be done with debt)?  I run into frequent instances where a given task takes an inordinate amount of time and totally messes up the DCF which can then only be corrected by going to the machine, stopping BOINC and manually editing the DCF for the project, then restarting BOINC.  Of course this restarts any WUs that may have gone for hours without checkpointing

Depends on what they intend to do with the DCF.
The DCF has to be changed in the client_state.xml file. Stopping the client -> change the value -> Start the client. Not something to think lightly about.
The Rescheduler can do this for you http://www.efmer.eu/forum_tt/index.php?topic=439.0 But only for the Seti projects.
The DCF is something you better not change, there is a server based value also, to make it more interesting. So adjusting the DCF may work counter productive to the automatic client and server based system, how badly they sometimes work.

Thanks for the explanation.  Altering the DCF does fix the problem of WU time overestimation, but it's a pain to do for the above mentioned reasons.  The project that really seems to be prone to this for me is Yoyo.  The way the DCF works is a problem.  One too long WU time and it immediately rockets the estimated time upward to that figure and then takes FOREVER to trickle back down.

To make matters more interesting, in the new BOINC 6.13 the debt system is gone. They seem to have started from scratch...

From the Alpha site:

EXTRA WARNING

The new BOINC 6.13 range is using completely new, from the ground up written code for many of its parts. It is not to be used if you are not an alpha tester. It is not to be used on all of your machines, just on one. When it doesn't work, report your problems to the developers and return to the latest 6.12.recommended.

At this time we're specifically testing whether or not the new CPU/GPU scheduling code works without using debt, and if projects will fetch work.

This is not a version that you install and walk away from, it needs constant checking, including the use of all the correct client configuration flags. Make sure your log files are of sufficient size so you can log through the night.

I tried 6.13.0 and 6.13.1 on 2 machines.  Bugs galore and bad ones.  One box needed a registry restore to get Win7-64 working correctly again. 

[fred]

I tried 6.13.0 and 6.13.1 on 2 machines.  Bugs galore and bad ones.  One box needed a registry restore to get Win7-64 working correctly again.

BOINC was probably getting too stable.