As the title says it won't download new work for all my projects except SETI.

What's up with this? I'm running dry on tasks to crunch.

EDIT: BTW, due to lack of GPU work from all my projects (except SETI and MilkyWay) GPUGrid is running in 'high priority' while I have 2 GPU cards, a GTX-570 and a GTX-550TI. GPUGrid will only run on the GTX570 though (with the <exclude gpu> rule in cc_config.xml).

Anthony.

---

The longer I live, the more reasons I develop for wanting to die.

This is the debug information I get:

Windows-7-PC

1336			Feb/11/2012 02:12:23	[work_fetch] work fetch start	
1337			Feb/11/2012 02:12:23	[rr_sim] start: work_buf min 864000 additional 864000 total 1728000 on_frac 0.974 active_frac 1.000	
1339	GPUGRID	Feb/11/2012 02:12:23	[rr_sim] 4239.37: I1R48-NATHAN_FA5-99-100-RND5020_1 finishes (719073.45G/152.34G)	
1340	GPUGRID	Feb/11/2012 02:12:23	[rr_sim] I1R48-NATHAN_FA5-99-100-RND5020_1 misses deadline by 473632.17	
1396			Feb/11/2012 02:12:23	[work_fetch] ------- start work fetch state -------	
1397			Feb/11/2012 02:12:23	[work_fetch] target work buffer: 864000.00 + 864000.00 sec	
1398			Feb/11/2012 02:12:23	[work_fetch] CPU: shortfall 3115244.87 nidle 0.00 saturated 154398.94 busy 0.00	
1406	GPUGRID	Feb/11/2012 02:12:23	[work_fetch] CPU: fetch share 0.00 rec 962.02268 prio -2.00069 backoff dt 0.00 int 0.00 (no apps)	
1407			Feb/11/2012 02:12:23	[work_fetch] NVIDIA: shortfall 3431927.32 nidle 1.00 saturated 13906.36 busy 0.00	
1415	GPUGRID	Feb/11/2012 02:12:23	[work_fetch] NVIDIA: fetch share 1.00 rec 962.02268 prio -2.00069 backoff dt 0.00 int 0.00	
1423	GPUGRID	Feb/11/2012 02:12:23	[work_fetch] REC 962.022678	
1424			Feb/11/2012 02:12:23	[work_fetch] ------- end work fetch state -------	
1425			Feb/11/2012 02:12:23	[work_fetch] No project chosen for work fetch	
1426			Feb/11/2012 02:12:33	[work_fetch] Request work fetch: Backoff ended for SETI@home	
1427			Feb/11/2012 02:12:33	[work_fetch] work fetch start	
1428			Feb/11/2012 02:12:33	[rr_sim] start: work_buf min 864000 additional 864000 total 1728000 on_frac 0.974 active_frac 1.000	
1430	GPUGRID	Feb/11/2012 02:12:33	[rr_sim] 4239.58: I1R48-NATHAN_FA5-99-100-RND5020_1 finishes (717084.36G/152.34G)	
1431	GPUGRID	Feb/11/2012 02:12:33	[rr_sim] I1R48-NATHAN_FA5-99-100-RND5020_1 misses deadline by 473629.12	
1487			Feb/11/2012 02:12:33	[work_fetch] ------- start work fetch state -------	
1488			Feb/11/2012 02:12:33	[work_fetch] target work buffer: 864000.00 + 864000.00 sec	
1489			Feb/11/2012 02:12:33	[work_fetch] CPU: shortfall 3115259.58 nidle 0.00 saturated 154399.10 busy 0.00	
1497	GPUGRID	Feb/11/2012 02:12:33	[work_fetch] CPU: fetch share 0.00 rec 962.02268 prio -1.17372 backoff dt 0.00 int 0.00 (no apps)	
1498			Feb/11/2012 02:12:33	[work_fetch] NVIDIA: shortfall 3431950.81 nidle 1.00 saturated 13899.72 busy 0.00	
1506	GPUGRID	Feb/11/2012 02:12:33	[work_fetch] NVIDIA: fetch share 1.00 rec 962.02268 prio -1.17372 backoff dt 0.00 int 0.00	
1514	GPUGRID	Feb/11/2012 02:12:33	[work_fetch] REC 962.022678	
1515			Feb/11/2012 02:12:33	[work_fetch] ------- end work fetch state -------	
1516			Feb/11/2012 02:12:33	[work_fetch] No project chosen for work fetch	
1517			Feb/11/2012 02:12:50	[cpu_sched_debug] Request CPU reschedule: periodic CPU scheduling	
1518			Feb/11/2012 02:12:50	[cpu_sched_debug] schedule_cpus(): start	
1519			Feb/11/2012 02:12:50	[rr_sim] start: work_buf min 864000 additional 864000 total 1728000 on_frac 0.974 active_frac 1.000	
1521	GPUGRID	Feb/11/2012 02:12:50	[rr_sim] 4239.94: I1R48-NATHAN_FA5-99-100-RND5020_1 finishes (714597.47G/152.34G)	
1522	GPUGRID	Feb/11/2012 02:12:50	[rr_sim] I1R48-NATHAN_FA5-99-100-RND5020_1 misses deadline by 473629.80	
1578	GPUGRID	Feb/11/2012 02:12:50	[rr_sim] Result I1R48-NATHAN_FA5-99-100-RND5020_1 projected to miss deadline.	
1579	GPUGRID	Feb/11/2012 02:12:50	[rr_sim] Project has 1 projected NVIDIA deadline misses	
1580	GPUGRID	Feb/11/2012 02:12:50	[cpu_sched_debug] earliest deadline: 1329317831 I1R48-NATHAN_FA5-99-100-RND5020_1	
1581	GPUGRID	Feb/11/2012 02:12:50	[cpu_sched_debug] scheduling I1R48-NATHAN_FA5-99-100-RND5020_1 (coprocessor job, EDF) (prio -0.825617)	
1582	GPUGRID	Feb/11/2012 02:12:50	[cpu_sched_debug] reserving 1.000000 of coproc NVIDIA	
1591			Feb/11/2012 02:12:50	[cpu_sched_debug] enforce_schedule(): start	
1592			Feb/11/2012 02:12:50	[cpu_sched_debug] preliminary job list:	
1593	GPUGRID	Feb/11/2012 02:12:50	[cpu_sched_debug] 0: I1R48-NATHAN_FA5-99-100-RND5020_1 (MD: yes; UTS: yes)	
1598			Feb/11/2012 02:12:50	[cpu_sched_debug] final job list:	
1599	GPUGRID	Feb/11/2012 02:12:50	[cpu_sched_debug] 0: I1R48-NATHAN_FA5-99-100-RND5020_1 (MD: yes; UTS: yes)	
1604	GPUGRID	Feb/11/2012 02:12:50	[cpu_sched_debug] scheduling I1R48-NATHAN_FA5-99-100-RND5020_1	
1612	GPUGRID	Feb/11/2012 02:12:50	[cpu_sched_debug] I1R48-NATHAN_FA5-99-100-RND5020_1 sched state 2 next 2 task state 1	
1616			Feb/11/2012 02:12:50	[cpu_sched_debug] enforce_schedule: end	

Anthony.

---

The longer I live, the more reasons I develop for wanting to die.

It seems that BOINC 7.0.15 will only download 1 WU per GPU. If I remove the <exclude_gpu> option from the cc_config.xml file it will download a second WU (for my 2nd GPU), while with version 6.12.34 it downloaded 2 WU's per GPU, and I have 2 GPU's, so I did end up with 4 WU's at one time (until I went back to a 2 client setup). So now it will only download 2 WU's if I remove that option which is a pain in the but. And if I leave the option in the cc_config file then I don't know when it will start to download a new WU. Will it do that after reporting the finished one, because that might take a while as the upload of a WU might take a while with mu upload speed.

Anthony.

---

The longer I live, the more reasons I develop for wanting to die.

It seems that BOINC 7.0.15 will only download 1 WU per GPU. If I remove the <exclude_gpu> option from the cc_config.xml file it will download a second WU (for my 2nd GPU), while with version 6.12.34 it downloaded 2 WU's per GPU, and I have 2 GPU's, so I did end up with 4 WU's at one time (until I went back to a 2 client setup). So now it will only download 2 WU's if I remove that option which is a pain in the but. And if I leave the option in the cc_config file then I don't know when it will start to download a new WU. Will it do that after reporting the finished one, because that might take a while as the upload of a WU might take a while with mu upload speed.

Anthony.

So you have a machine with dual GPU's and your cc_config file specifies an exclude on one (presumably allocating one to seti and other to GPUgrid). You have the "connect every" set to 1 day and "additional buffer" set to 1 day. Is this correct?

Can you post your cc_config.xml file please. Also whats your on_frac value? You will have to browse your client_state.xml to find it.

I have reported issues with GPU work fetch (or lack of). CPU seems to work correctly as far as I can tell but GPU falls way too short.

---

BOINC blog

So you have a machine with dual GPU's and your cc_config file specifies an exclude on one (presumably allocating one to seti and other to GPUgrid). You have the "connect every" set to 1 day and "additional buffer" set to 1 day. Is this correct?

Can you post your cc_config.xml file please. Also whats your on_frac value? You will have to browse your client_state.xml to find it.

I have reported issues with GPU work fetch (or lack of). CPU seems to work correctly as far as I can tell but GPU falls way too short.

I have the "connect every" set to 1 day and "additional buffer" set to 10 days.

<on_frac>0.975064</on_frac>

My cc_config.xml

<cc_config>
    <log_flags>
        <file_xfer>1</file_xfer>
        <sched_ops>1</sched_ops>
        <task>1</task>
        <app_msg_receive>0</app_msg_receive>
        <app_msg_send>0</app_msg_send>
        <benchmark_debug>0</benchmark_debug>
        <checkpoint_debug>0</checkpoint_debug>
        <coproc_debug>0</coproc_debug>
        <cpu_sched>0</cpu_sched>
        <cpu_sched_debug>0</cpu_sched_debug>
        <cpu_sched_status>0</cpu_sched_status>
        <dcf_debug>0</dcf_debug>
        <priority_debug>0</priority_debug>
        <file_xfer_debug>0</file_xfer_debug>
        <gui_rpc_debug>0</gui_rpc_debug>
        <heartbeat_debug>0</heartbeat_debug>
        <http_debug>0</http_debug>
        <http_xfer_debug>0</http_xfer_debug>
        <mem_usage_debug>0</mem_usage_debug>
        <network_status_debug>0</network_status_debug>
        <poll_debug>0</poll_debug>
        <proxy_debug>0</proxy_debug>
        <rr_simulation>0</rr_simulation>
        <rrsim_detail>0</rrsim_detail>
        <sched_op_debug>0</sched_op_debug>
        <scrsave_debug>0</scrsave_debug>
        <slot_debug>0</slot_debug>
        <state_debug>0</state_debug>
        <statefile_debug>0</statefile_debug>
        <std_debug>0</std_debug>
        <task_debug>0</task_debug>
        <time_debug>0</time_debug>
        <trickle_debug>0</trickle_debug>
        <unparsed_xml>0</unparsed_xml>
        <work_fetch_debug>0</work_fetch_debug>
        <notice_debug>0</notice_debug>
    </log_flags>
  <options>
       <abort_jobs_on_exit>0</abort_jobs_on_exit>
        <allow_multiple_clients>0</allow_multiple_clients>
        <allow_remote_gui_rpc>0</allow_remote_gui_rpc>
        <client_version_check_url>http://boinc.berkeley.edu/download.php?xml=1</client_version_check_url>
        <client_download_url>http://boinc.berkeley.edu/download.php</client_download_url>
        <disallow_attach>0</disallow_attach>
        <dont_check_file_sizes>0</dont_check_file_sizes>
        <dont_contact_ref_site>0</dont_contact_ref_site>
        <exit_after_finish>0</exit_after_finish>
        <exit_before_start>0</exit_before_start>
        <exit_when_idle>0</exit_when_idle>
        <fetch_minimal_work>0</fetch_minimal_work>
        <force_auth>default</force_auth>
        <http_1_0>0</http_1_0>
        <http_transfer_timeout>300</http_transfer_timeout>
        <http_transfer_timeout_bps>10</http_transfer_timeout_bps>
        <max_file_xfers>8</max_file_xfers>
        <max_file_xfers_per_project>2</max_file_xfers_per_project>
        <max_stderr_file_size>0</max_stderr_file_size>
        <max_stdout_file_size>0</max_stdout_file_size>
        <max_tasks_reported>0</max_tasks_reported>
        <ncpus>-1</ncpus>
        <network_test_url>http://www.google.com/</network_test_url>
        <no_alt_platform>0</no_alt_platform>
        <no_gpus>0</no_gpus>
        <no_info_fetch>0</no_info_fetch>
        <no_priority_change>0</no_priority_change>
        <os_random_only>0</os_random_only>
<proxy_info>
    <socks_server_name></socks_server_name>
    <socks_server_port>80</socks_server_port>
    <http_server_name></http_server_name>
    <http_server_port>80</http_server_port>
    <socks5_user_name></socks5_user_name>
    <socks5_user_passwd></socks5_user_passwd>
    <http_user_name></http_user_name>
    <http_user_passwd></http_user_passwd>
    <no_proxy></no_proxy>
</proxy_info>
        <rec_half_life_days>10.000000</rec_half_life_days>
        <report_results_immediately>0</report_results_immediately>
        <run_apps_manually>0</run_apps_manually>
        <save_stats_days>30</save_stats_days>
        <skip_cpu_benchmarks>0</skip_cpu_benchmarks>
        <simple_gui_only>0</simple_gui_only>
        <start_delay>0</start_delay>
        <stderr_head>0</stderr_head>
        <suppress_net_info>0</suppress_net_info>
        <unsigned_apps_ok>0</unsigned_apps_ok>
        <use_certs>0</use_certs>
        <use_certs_only>0</use_certs_only>
        <zero_debts>0</zero_debts>
		<use_all_gpus>1</use_all_gpus>
		<exclude_gpu>
		<url>http://www.gpugrid.net</url>
		<device_num>1</device_num>
		</exclude_gpu>
   </options>
</cc_config>

Anthony.

---

The longer I live, the more reasons I develop for wanting to die.

Well that's a good sample cc_config. Every option it can do, even if most of them are off.

Why have a 10 day additional buffer? GPUgrid usually has short deadlines. So effectively you are asking the client to get 11 days of work when it does a work fetch. Under the newer scheduling in 7.x it will use the "connect every" number (1 day) as a min cache, but will try and ask for 11 days work. I suggest you reduce the "additional" figure down to say 3 days which should be enough to survive a SETI outage. It should also allow it to meet project deadlines (typically 7 days on here).

Like I said before, I still think it has gpu work fetch issues and I haven't yet managed to convince Dr Anderson.

---

BOINC blog

It just downloaded 4 (long) WU's while I'm only using 1 GPU for this project.
I aborted 1 WU so that the other 3 will (probably) finish within 24 hours.

Anthony.

---

The longer I live, the more reasons I develop for wanting to die.

Like I said before, I still think it has gpu work fetch issues

I agree - its a feast or famine regime.

Some Projects will drip feed me one at a time (which is fine) until it catches up to the required number, more than half the time it will not download at all until the cache is near empty, and I get it all at once. Thats with unchanged settings ... I usually set for half a day (1 day at most) on the primary cache at Projects, and never use the days delay aspect, even with that the work fetch is getting in a twist.

Its going to be a big issue if not resolved by the time 7.X.X goes Production.

Regards
Zy

I notice that under 7.0.15 that its now been labelled "Minimum work buffer" and "Max additional work buffer". The idea is it will build up the cache and wait until it gets below the minimum level before asking for more work, to reduce the number of requests for work.

Those that want to try 7.x before its released I would suggest you use a smallish number in both. For GPUgrid you'd want to keep the total under 7 days so it can meet deadlines. Given GPUgrid is rarely offline you could almost run it with 1 day Min and zero in the Max but it depends on what other projects you need to allow for. For my GPUgrid crunchers I run on a Min of 0.01 and zero for Max, so it waits until its almost finished a wu before requesting another and internet is always available.

---

BOINC blog

GPUGrid only issues 2 tasks per card maximum, so with high end CC2.0 cards running 24/7 (or close to), you don't actually have a high cache of GPU tasks anyway. This means you can safely up your cache, to reduce the chance of such issues, and perhaps better accommodate some CPU projects, especially the ones more prone to outages.

If on the other hand you run multiple GPU projects, anything other than a very small cache size will mean missing GPUGrid bonuses (which exist to expedite the project). For smaller cards, a very low cache is preferable. These setups are most likely to suffer outages if there is a problem with 7.0.15.

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

GPUGrid only issues 2 tasks per card maximum, so with high end CC2.0 cards running 24/7 (or close to), you don't actually have a high cache of GPU tasks anyway.

So why did it download 4 WU's, whil GPUGrid is assigned to 1 GPU only (out of 2)?

Anthony.

---

The longer I live, the more reasons I develop for wanting to die.

Because there are two GPU's, and Boinc's not that smart. Obviously such configurations are an exception as would be configuring an app_info file.

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

And now it won't download a new task while I only have just over 20 minutes of crunching time left on my last GPUGrid WU.

What is it cool to run BOINC 7.0.15 (being sarcastic).

Anthony.

---

The longer I live, the more reasons I develop for wanting to die.

And now it won't download a new task while I only have just over 20 minutes of crunching time left on my last GPUGrid WU.

What is it cool to run BOINC 7.0.15 (being sarcastic).

Anthony.

It usually waits until the task has a about 5 mins left before it goes and requests a new one (assuming you are running .01 + 0).

If you are running 1 + 3 then it should keep 1 days worth and when it falls below that its meant to request 3 days plus whatever its shortfall from the 1 day minimum is.

I have raised a bug where in project properties it doesn't show that a gpu has been excluded. As skgiven has said it may be requesting work for the excluded gpu. The joys of running alpha-test software.

---

BOINC blog

It's only cool to use Alpha Boinc versions is you have the following recommended cc_config and report issues to the alpha email list:

<cc_config>
<log_flags>
<task_debug>1</task_debug>
<cpu_sched>1</cpu_sched>
<sched_op_debug>1</sched_op_debug>
<cpu_sched_debug>1</cpu_sched_debug>
<work_fetch_debug>1</work_fetch_debug>
<rr_simulation>1</rr_simulation>
</log_flags>
<options>
<max_stdout_file_size>181192000</max_stdout_file_size>
</options>
</cc_config>

Recently I have been too busy to be 'cool', so I mostly run the alpha releases to familiarize myself with changes, be able to help people with issues and just to participate at one project. I do occasionally investigate, report issues/annoy people and make 'cool' suggestions, but most fall by the wayside. Some do get implemented, and some more will, hopefully, eventually...

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

I had turned on some suggested log-flags but it flooded my BoincTasks message window so I turned them off.

Edit: but I did post a very extensive cc_config.xml so propably all options are in there. I got it through an option in BoincTasks (edit configfile(cc_config)).

Anthony.

---

The longer I live, the more reasons I develop for wanting to die.

I had turned on some suggested log-flags but it flooded my BoincTasks message window so I turned them off.

Edit: but I did post a very extensive cc_config.xml so propably all options are in there. I got it through an option in BoincTasks (edit configfile(cc_config)).

Anthony.

I think work_fetch_debug and sched_op_debug would be sufficent log flags if you are going to report stuff to the mailing list. Also Dr Anderson likes the client emulator, so if you can create a scenerio there it might help debug things. Its on the Boinc Alpha web site.

---

BOINC blog

I was getting a lot of error last night si I went back to 6.12.34 for the moment.

Anthnony

---

The longer I live, the more reasons I develop for wanting to die.