How do I stop my DCF being silly?

Questions and Answers : Getting started : How do I stop my DCF being silly?
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile red-ray
Avatar

Send message
Joined: 24 Jun 99
Posts: 308
Credit: 9,029,848
RAC: 0
United Kingdom
Message 1200454 - Posted: 27 Feb 2012, 21:29:23 UTC
Last modified: 27 Feb 2012, 21:40:22 UTC

At moment my DCF is going up and down like a yo-yo, but more up than down. I enabled <dcf_debug> and am seeing changes such as

27/02/2012 20:46:05 | SETI@home | [dcf] DCF: 0.395857->1.277240, raw_ratio 1.277240, adj_ratio 3.226520

The root cause of the issue is that I have 2 fast and 2 slow GPUs, further it seems to go up far faster that it comes down (I looked in the BOINC C++ code and this is by by "design"). My system is quite capable of processing 12 x 50 + 4 x 400 = 2200 WUs in at most 4 days but I can't get all 1600 GPU WUs as my DCF is far higher than it should be.
Is there a way I can set an upper DCF limit?
ID: 1200454 · Report as offensive
John McLeod VII
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 15 Jul 99
Posts: 24806
Credit: 790,712
RAC: 0
United States
Message 1200496 - Posted: 27 Feb 2012, 23:55:17 UTC

No.

DCF has two related functions. The more important for the projects is the safety of not getting too much work - hence the rapid up vs slower down.


BOINC WIKI
ID: 1200496 · Report as offensive
Profile red-ray
Avatar

Send message
Joined: 24 Jun 99
Posts: 308
Credit: 9,029,848
RAC: 0
United Kingdom
Message 1200499 - Posted: 28 Feb 2012, 0:09:19 UTC - in response to Message 1200496.  
Last modified: 28 Feb 2012, 0:52:01 UTC

Yes, I know that. I read it in the code.

There seems to be far too much effort put into stopping too many WUs being sent and far too little into keeping high RAC computers stocked up.

// The given result has just completed successfully.
// Update the correction factor used to predict
// completion time for this project's results
//
void PROJECT::update_duration_correction_factor(ACTIVE_TASK* atp) {
RESULT* rp = atp->result;
double raw_ratio = atp->elapsed_time/rp->estimated_duration_uncorrected();
double adj_ratio = atp->elapsed_time/rp->estimated_duration();
double old_dcf = duration_correction_factor;

// it's OK to overestimate completion time,
// but bad to underestimate it.
// So make it easy for the factor to increase,
// but decrease it with caution
//
if (adj_ratio > 1.1) {
duration_correction_factor = raw_ratio;
} else {
// in particular, don't give much weight to results
// that completed a lot earlier than expected
//
if (adj_ratio < 0.1) {
duration_correction_factor = duration_correction_factor*0.99 + 0.01*raw_ratio;
} else {
duration_correction_factor = duration_correction_factor*0.9 + 0.1*raw_ratio;
}
}
// limit to [.01 .. 100]
//
if (duration_correction_factor > 100) duration_correction_factor = 100;
if (duration_correction_factor < 0.01) duration_correction_factor = 0.01;

if (log_flags.dcf_debug) {
msg_printf(this, MSG_INFO,
"[dcf] DCF: %f->%f, raw_ratio %f, adj_ratio %f",
old_dcf, duration_correction_factor, raw_ratio, adj_ratio
);
}
}


Yes, there is I edit the code and re-compie BOINC!

The problem is my DCF is so far out the adj_ratio < 0.1 clause kicks in a lot of the time.
ID: 1200499 · Report as offensive
John McLeod VII
Volunteer developer
Volunteer tester
Avatar

Send message
Joined: 15 Jul 99
Posts: 24806
Credit: 790,712
RAC: 0
United States
Message 1200513 - Posted: 28 Feb 2012, 1:51:43 UTC - in response to Message 1200499.  

Yes, I know that. I read it in the code.

There seems to be far too much effort put into stopping too many WUs being sent and far too little into keeping high RAC computers stocked up.

// The given result has just completed successfully.
// Update the correction factor used to predict
// completion time for this project's results
//
void PROJECT::update_duration_correction_factor(ACTIVE_TASK* atp) {
RESULT* rp = atp->result;
double raw_ratio = atp->elapsed_time/rp->estimated_duration_uncorrected();
double adj_ratio = atp->elapsed_time/rp->estimated_duration();
double old_dcf = duration_correction_factor;

// it's OK to overestimate completion time,
// but bad to underestimate it.
// So make it easy for the factor to increase,
// but decrease it with caution
//
if (adj_ratio > 1.1) {
duration_correction_factor = raw_ratio;
} else {
// in particular, don't give much weight to results
// that completed a lot earlier than expected
//
if (adj_ratio < 0.1) {
duration_correction_factor = duration_correction_factor*0.99 + 0.01*raw_ratio;
} else {
duration_correction_factor = duration_correction_factor*0.9 + 0.1*raw_ratio;
}
}
// limit to [.01 .. 100]
//
if (duration_correction_factor > 100) duration_correction_factor = 100;
if (duration_correction_factor < 0.01) duration_correction_factor = 0.01;

if (log_flags.dcf_debug) {
msg_printf(this, MSG_INFO,
"[dcf] DCF: %f->%f, raw_ratio %f, adj_ratio %f",
old_dcf, duration_correction_factor, raw_ratio, adj_ratio
);
}
}


Yes, there is I edit the code and re-compie BOINC!

The problem is my DCF is so far out the adj_ratio < 0.1 clause kicks in a lot of the time.

What we really need is a DCF / device...


BOINC WIKI
ID: 1200513 · Report as offensive
Profile BilBg
Volunteer tester
Avatar

Send message
Joined: 27 May 07
Posts: 3720
Credit: 9,385,827
RAC: 0
Bulgaria
Message 1200707 - Posted: 28 Feb 2012, 16:36:45 UTC - in response to Message 1200454.  

Is there a way I can set an upper DCF limit?


You can cap this using BoincRescheduler
http://www.efmer.eu/forum_tt/index.php?topic=428.0

"config.xml

<dcf_min>0.1</dcf_min>
<dcf_max>0.2</dcf_max>
"


 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 
ID: 1200707 · Report as offensive
Profile red-ray
Avatar

Send message
Joined: 24 Jun 99
Posts: 308
Credit: 9,029,848
RAC: 0
United Kingdom
Message 1200907 - Posted: 29 Feb 2012, 10:40:38 UTC - in response to Message 1200707.  

Thank you for the link. I wonder how it does this and if I could get SIV to do the same.
ID: 1200907 · Report as offensive
Profile BilBg
Volunteer tester
Avatar

Send message
Joined: 27 May 07
Posts: 3720
Credit: 9,385,827
RAC: 0
Bulgaria
Message 1201196 - Posted: 1 Mar 2012, 1:10:50 UTC - in response to Message 1200907.  
Last modified: 1 Mar 2012, 1:18:52 UTC


The value is in client_state.xml

<project>
<master_url>http://setiathome.berkeley.edu/</master_url>
<project_name>SETI@home</project_name>
......
<duration_correction_factor>2.439095</duration_correction_factor>


BoincRescheduler shuts down BOINC (uses boinccmd.exe --quit)
then BoincRescheduler edits the value and restarts boinc.exe


If client_state.xml becomes broken you may lose all the tasks.
So I hope you will do tests with precautions (backup of BOINC Data and network disabled)

Be careful - boincmgr.exe restarts automatically boinc.exe after 30 (?) seconds.

Better ask Fred personally about any tricky things he faced doing that.

See Fred's and my posts here:
BOINC client is restarting automatically
http://boinc.berkeley.edu/dev/forum_thread.php?id=5879


 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 
ID: 1201196 · Report as offensive

Questions and Answers : Getting started : How do I stop my DCF being silly?


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.