On my old P4 based server, with a AGP slot and an HD3850 running Milkyway GPU clients. I use the CPU to crunch Einstein, and FreeHAL when it is available.

FreeHAL is quite intermittent, so, when no work is available I detach this rig from the project. I then attach for the duration work is available.

I am running down my cache of Einstein WUs as the crunching on the current S5R5_a_1 WUs is around 24 hours. Not very productive, and I would like to encourage the GPU to crunch MW at a higher rate than it has (see other thrad about No Work).

As these other projects are running on the CPU and MW on the GPU, this means the Resources Share and the Long term and Short Term Debt begin to come in to play. As shown in the Projects part of the "Client State" file.

My current client state file shows -

<project>
!
!
! <master_url>http://einstein.phys.uwm.edu/</master_url>
<project_name>Einstein@Home</project_name>
!
!
<master_fetch_failures>0</master_fetch_failures>
<min_rpc_time>1238683978.750000</min_rpc_time>
<next_rpc_time>0.000000</next_rpc_time>
<short_term_debt>-1535.484375</short_term_debt>
<long_term_debt>-556155.705381</long_term_debt>
<resource_share>10.000000</resource_share>
<duration_correction_factor>2.321807</duration_correction_factor>
<sched_rpc_pending>0</sched_rpc_pending>
<send_time_stats_log>0</send_time_stats_log>
<send_job_log>0</send_job_log>
<verify_files_on_app_start/>
<dont_request_more_work/>
<ams_resource_share>0.000000</ams_resource_share>
<scheduler_url>http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi</scheduler_url>
<code_sign_key>
1024


I am reasonably content with the impact of the duration_correction_factor.

But, in the context of 1 other project running - CPU Einstein and GPU MW, what does the - short term debt and long term debt mean in this context?

In the case I am quoting they have suddenly become heavily negative. Will this encourage the D/L of MW work for the GPU?

I hope this makes sense?

---

Go away, I was asleep

My current client state file shows -

<project>
!
!
! <master_url>http://einstein.phys.uwm.edu/</master_url>
<project_name>Einstein@Home</project_name>
!
!
<master_fetch_failures>0</master_fetch_failures>
<min_rpc_time>1238683978.750000</min_rpc_time>
<next_rpc_time>0.000000</next_rpc_time>
<short_term_debt>-1535.484375</short_term_debt>
<long_term_debt>-556155.705381</long_term_debt>
<resource_share>10.000000</resource_share>
<duration_correction_factor>2.321807</duration_correction_factor>
<sched_rpc_pending>0</sched_rpc_pending>
<send_time_stats_log>0</send_time_stats_log>
<send_job_log>0</send_job_log>
<verify_files_on_app_start/>
<dont_request_more_work/>
<ams_resource_share>0.000000</ams_resource_share>
<scheduler_url>http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi</scheduler_url>
<code_sign_key>
1024


I am reasonably content with the impact of the duration_correction_factor.

But, in the context of 1 other project running - CPU Einstein and GPU MW, what does the - short term debt and long term debt mean in this context?

In the case I am quoting they have suddenly become heavily negative. Will this encourage the D/L of MW work for the GPU?

I hope this makes sense?

Negative means it owes the other projects that much. The debts are there so that it helps Boinc run each project the amount of time you set it for. If one ltd builds up a lot then it may refuse to ask for work, or give that project a load of wu's.

In the case I am quoting they have suddenly become heavily negative. Will this encourage the D/L of MW work for the GPU?

It would give you more if you were allowed more than 6 wu's/core. Also it shod run mw more if you could get work untill it evens out.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

Negative means it owes the other projects that much. The debts are there so that it helps Boinc run each project the amount of time you set it for. If one ltd builds up a lot then it may refuse to ask for work, or give that project a load of wu's.

It would give you more if you were allowed more than 6 wu's/core. Also it shod run mw more if you could get work untill it evens out.

Thanks for the feedback BW. The short term debt quickly changed to 0.0000, but the long term debt is still negative and at a similar figure to that quoted earlier.

I now only have E@H running, and will detach when the WUs are done. This will just leave MW running on this GPU.

I suppose if I manually changed the long term debt to 0.00 or a positive figure, then the MW work will come down better?

Not true, and the Long Term Debt slowly reverts to zero!

---

Go away, I was asleep

I suppose if I manually changed the long term debt to 0.00 or a positive figure, then the MW work will come down better?

If you do change it, close boinc and use something like wordpad to change the values.

Not true, and the Long Term Debt slowly reverts to zero!

Yes it does, or should if things run normally.

---

Doesn't expecting the unexpected make the unexpected the expected?
If it makes sense, DON'T do it.

As the debt is negative on Einstein, in theory, BOINC should be trying to crunch more MW to make up that debt shortfall. However, since MW doesn't have enough work it can't crunch enough to get the Einstein debt to reduce - except in spurts. All up I'd leave it as is. BOINC also tends to reset the debt for any project that runs out of work - which means it does not necessarily match your resource share allocation.

Thanks for the replies, and leaving well alone. That is except to detach from E@H when the cache is completed. The PC is too slow, so I will let the quads take the strain on that project over the next few weeks.

Interestingly the duration correction factor has not changed since my first post, but the short term and long term debt has (see below).

</net_stats>
<project>
<master_url>http://einstein.phys.uwm.edu/</master_url>
<project_name>Einstein@Home</project_name>
<symstore></symstore>
!
!
<nrpc_failures>0</nrpc_failures>
<master_fetch_failures>0</master_fetch_failures>
!
!
<short_term_debt>-7157.239890</short_term_debt>
<long_term_debt>2280933.583640</long_term_debt>
<resource_share>10.000000</resource_share>
<duration_correction_factor>2.309974</duration_correction_factor>
<sched_rpc_pending>0</sched_rpc_pending>
<send_time_stats_log>0</send_time_stats_log>
<send_job_log>0</send_job_log>
<verify_files_on_app_start/>
<dont_request_more_work/>
<ams_resource_share>0.000000</ams_resource_share>
<scheduler_url>http://einstein.phys.uwm.edu/EinsteinAtHome_cgi/cgi</scheduler_url>
<code_sign_key>
1024

---

Go away, I was asleep

I suppose if I manually changed the long term debt to 0.00 or a positive figure, then the MW work will come down better?

If you do change it, close boinc and use something like wordpad to change the values.

If you do change it, be aware that the sum of the LTDs across all projects must equal zero.
Also each value must have 6 places of decimals, even if zeros.

If you muck it up BOINC will discard client_state and use client_state_prev instead.

Rather than edit the xml by hand, you can use the set_debts command from the boinccmd.exe. Then, to set the debt, you only need to pass in 0.0 instead of 0.000000 for each number. Use "boinccmd.exe --help" to see the syntax for all the commands.

Im running 6.6.20 on two computers one is a mac and i run seti and milkyway. the other is a P4 running seti and milkyway. I dont seem to get any milkway WU on the P4. I am assuming that looking at the properties box that the debt to milkyway is way over. it reads work fetch -2928 and work fetch deferred for 03;06 and work fetch deferred interval 24;00 the seti box says all zeroes. Am i right?

---