One advantage of having a slow rig and then a very slow one is that I get a full 10 day cache on each.

I could only wish.

Cheers.

Once the APs finish splitting my cache last about a day and half then it's back to MBs.

Hi Folks,
Just recently had a problem with a mis-configured app_info file:-(
With the result that Boinc promptly deleted my entire cache of WU, incl 1 x AP:-/
Now the other side of this misery is that when Boinc decides to bin an entire cache it doesn't bother to tell the servers. So I guess that anyone who was also working on those WU is gonna wait quite at time before s@h servers decide to re-issue those WU.

Maybe it might be an idea for the devs to consider having the cache trasher [boinc] actually report to the servers that its deleted WU and which ones its binned.
Anyone consider this a reasonable idea? or not? if not why not?

Over to you folks:-)

Regards,

---

Cliff,
Been there, Done that, Still no damm T shirt!

I am sorry to hear that happened. The feature that you described would be rather handy. If you want to release your tasks back to the grid before the return date, here is the easiest thing I find to do in this situation is return lost task is turned off. Set no new tasks. Empty cache of work. Then D attach from the project and reattach. If you are using Lunatics processing you will need to reinstall this

---

Once the APs finish splitting my cache last about a day and half then it's back to MBs.

So long as my CPU cores are kept happy with AP's for several days then I only have to worry about keeping my GPU's fed with MB's, or letting them have at it with a backup project.

With the ratio of AP's produced compared to MB's it only seems fitting to me to limit my CPU cores to AP's and just let my GPU's deal with the MB's. ;-)

Now as to keeping my main rig's GPU's fed during a slightly extended outrage is another story which usually ends in another project being done for a day (my other rig has a 50% longer lasting GPU cache with it's extra GPU). :-(

Cheers.

Right now my machine has a full load of AP tasks. Early this morning the machine went south because it got excited and overheated. When I started it back up I noticed that there were no CPU tasks running, therefore I have 100 AP CPU tasks sitting around gathering dust. I can find nothing in the event log to suggest something wrong. I'm running a max of 7 CPUs, 2 cores for GTX750TIs @ x2 each, leaving 3 cores for CPU tasks and had no problems with the AP 7.03(sse2) until now. Running NVIDA 347.88, BOINC 7.6.3 (x64) and Lunatics. Any help will be greatly appreciated.

---

I don't buy computers, I build them!!

How many GPU tasks are you running at the same time?

As he said two:

I'm running a max of 7 CPUs, 2 cores for GTX750TIs @ x2 each, leaving 3 cores for CPU tasks

He could be running more than two tasks per GPU.

If there is any restriction of cores in boinc or more than 2 tasks per GPU, that could explain it, as each AP opencl TASK uses 1 core, unless -use_sleep is implemented.(running lunatics)

To clear things up I'm running 2x AP tasks on twin Gtx750TIs. Each task is allocated .5 CPU core on a 4770K hyper threaded machine. Before anyone shouts that I must have 1 core free for each AP task, I've been running this way for several years, ever since my first 1st gen. i7/930. With 80% CPU utilization set in local prefs (6 cores) I'm usually been able to 4~5 CPU AP tasks at the same time. If I suspend all of the GPU tasks, I get 6 CPU tasks running, and as soon as I resumed some of the GPU tasks, they their started running along side 4 CPU tasks after placing 2 CPU task in "waiting to run" status.

13-Jul-2015 11:08:53 [SETI@home] [cpu_sched] Preempting ap_05fe15ad_B0_P0_00211_20150711_12329.wu_0 (removed from memory)
13-Jul-2015 11:08:53 [SETI@home] [cpu_sched] Preempting ap_04jn15ac_B6_P0_00320_20150711_09600.wu_0 (removed from memory)
13-Jul-2015 11:08:53 [SETI@home] Starting task ap_05fe15ac_B0_P1_00386_20150711_24137.wu_0
13-Jul-2015 11:08:53 [SETI@home] [cpu_sched] Starting task ap_05fe15ac_B0_P1_00386_20150711_24137.wu_0 using astropulse_v7 version 705 (opencl_nvidia_100) in slot 0
13-Jul-2015 11:08:53 [SETI@home] Starting task ap_04jn15ab_B4_P1_00359_20150711_08549.wu_1
13-Jul-2015 11:08:53 [SETI@home] [cpu_sched] Starting task ap_04jn15ab_B4_P1_00359_20150711_08549.wu_1 using astropulse_v7 version 705 (opencl_nvidia_100) in slot 2
13-Jul-2015 11:08:53 [SETI@home] Starting task ap_04jn15ab_B5_P0_00321_20150711_08794.wu_0
13-Jul-2015 11:08:53 [SETI@home] [cpu_sched] Starting task ap_04jn15ab_B5_P0_00321_20150711_08794.wu_0 using astropulse_v7 version 705 (opencl_nvidia_100) in slot 3
13-Jul-2015 11:08:53 [SETI@home] Starting task ap_05fe15ad_B0_P0_00292_20150711_12329.wu_0
13-Jul-2015 11:08:53 [SETI@home] [cpu_sched] Starting task ap_05fe15ad_B0_P0_00292_20150711_12329.wu_0 using astropulse_v7 version 705 (opencl_nvidia_100) in slot 8

I then resumed the rest of the suspended tasks. As soon as the running GPU tasks completed and new ones started, the 4 running CPU tasks went into "waiting to run" status.

Here is an example from 5 July running a max of 5 cores. You'll notice there are 2 MB and I AP CPU tasks running.

05-Jul-2015 07:53:55 [---] [dcf] scaling all duration correction factors by 1.024786
05-Jul-2015 07:53:56 [SETI@home] [cpu_sched] Restarting task ap_30no14ab_B2_P0_00331_20150701_18156.wu_0 using astropulse_v7 version 703 (sse2) in slot 9
05-Jul-2015 07:53:56 [SETI@home] [cpu_sched] Restarting task 04fe15ab.14621.2627.438086664202.12.69.vlar_1 using setiathome_v7 version 700 in slot 7
05-Jul-2015 07:53:56 [SETI@home] [cpu_sched] Restarting task 04fe15ab.14621.3854.438086664202.12.228.vlar_0 using setiathome_v7 version 700 in slot 6
05-Jul-2015 07:53:56 [SETI@home] [cpu_sched] Restarting task ap_04fe15ab_B5_P0_00246_20150624_04101.wu_1 using astropulse_v7 version 705 (opencl_nvidia_100) in slot 8
05-Jul-2015 07:53:56 [SETI@home] [cpu_sched] Restarting task ap_07ja15aa_B0_P0_00089_20150624_22554.wu_0 using astropulse_v7 version 705 (opencl_nvidia_100) in slot 11
05-Jul-2015 07:53:56 [SETI@home] [cpu_sched] Restarting task ap_04fe15ab_B6_P1_00245_20150624_24572.wu_0 using astropulse_v7 version 705 (opencl_nvidia_100) in slot 12
05-Jul-2015 07:53:56 [SETI@home] [cpu_sched] Restarting task ap_06fe15aa_B4_P0_00386_20150624_06136.wu_1 using astropulse_v7 version 705 (opencl_nvidia_100) in slot 13

Regardless what I've set the "Use at most % of CPUs", CPU tasks will not run concurrent with GPU tasks. I'm thinking of reverting back to 7.4.42 to see if that will make a difference.

[edit]It seems that my ap_cmdline_7.05_windows_intelx86_opencl_nvidia_100.txt is not working. I might have to reinstall Lunatics. MANY THANKS WehZ for asking my settings.[/edit]

-use_sleep -unroll 10 -ffa_block 12288 -ffa_block_fetch 6144 -tune 1 64 8 1 -tune 2 128 8 1 -ocIFFT_plan 256 16 512 -hp

---

I don't buy computers, I build them!!

[edit]It seems that my ap_cmdline_7.05_windows_intelx86_opencl_nvidia_100.txt is not working. I might have to reinstall Lunatics. MANY THANKS WehZ for asking my settings.[/edit]

-use_sleep -unroll 10 -ffa_block 12288 -ffa_block_fetch 6144 -tune 1 64 8 1 -tune 2 128 8 1 -ocIFFT_plan 256 16 512 -hp

Well, file I have to edit is named ap_cmdline_win_x86_SSE2_OpenCL_NV.txt

I'm using is Lunatics Win64 v0.43a. Maybe the difference is that I'm using AMD CPU and You are using Intel CPU??? Don't know for sure...

And btw, it's WezH, not WehZ. And don't worry, You are not the first one to mess it, and You will not be last one :)

[edit]It seems that my ap_cmdline_7.05_windows_intelx86_opencl_nvidia_100.txt is not working. I might have to reinstall Lunatics. MANY THANKS WehZ for asking my settings.[/edit]

-use_sleep -unroll 10 -ffa_block 12288 -ffa_block_fetch 6144 -tune 1 64 8 1 -tune 2 128 8 1 -ocIFFT_plan 256 16 512 -hp

Well, file I have to edit is named ap_cmdline_win_x86_SSE2_OpenCL_NV.txt

I'm using is Lunatics Win64 v0.43a. Maybe the difference is that I'm using AMD CPU and You are using Intel CPU??? Don't know for sure...

And btw, it's WezH, not WehZ. And don't worry, You are not the first one to mess it, and You will not be last one :)

Both files have the same settings, but it has had no effect on the CPU(SSE2) tasks. When I looked at my valid AP GPU tasks, I noticed that the CPU & and total run time were basically the same, there should have been a marked difference between the two. I reinstalled Lunatics and will wait until new GPU tasks to see if it took.

---

I don't buy computers, I build them!!

With 80% CPU utilization set in local prefs (6 cores) I'm usually been able to 4~5 CPU AP tasks at the same time.

Set it 100% and watch.(no restriction)

As I stated in one of the previous posts -

Regardless what I've set the "Use at most % of CPUs", CPU tasks will not run concurrent with GPU tasks.

That also included no restrictions.

I've since uninstalled 7.6.3 and did a clean install of 7.4.42. since this is my daily machine I set "Use at most 70% of CPUs" (5 cores, 2, GPU, 3 CPU), which allows for 4 GPU & 3 CPU tasks to run concurrently. Looking at the properties for the GPU tasks, it seems that the ap_cmdline_7.05_windows_intelx86_opencl_nvidia_100.txt was not functioning. I then installed 7.6.1 over 7.4.42, then 7.6.2 over 7.6.1, which I'm currently running, with the same results as 7.4.42. I'll keep this version for now until I find out why the ap_cmdline is not functioning. Anyone running Lunatics have any suggestions?

Unfortunately I can't go back further than 8 July to see when the ap_cmdline starting failing. The CPU run time should be a very small fraction of the total run time.

---

I don't buy computers, I build them!!

If I'm not mistaken ... But I could be completely wrong ...

ap_cmdline_7.05_windows_intelx86_opencl_nvidia_100.txt
Is for Stock apps

ap_cmdline_win_x86_SSE2_OpenCL_NV.txt
Is for Lunatics

---

Hey Cliff,

Sorry I haven't gone back and re-read all your post ( I'll do that soon). 1 thing that sticks in my mind is you are setting the % utilization at 70%.

I don't know if you saw one of my post where I commented on that I don't think that is the right approach for reserving cores.

Telling the computer that it can only use 70% of the cores then thinking that it's going countermand that order and use part of the 30% for feeding the cores doesn't make sense. To me, it's more likely going to steal some time from that 70% of cores.

I went a different route. This only works if you are only doing 1 project.

I use the <project_max_concurrent> in the app_config.

Keeping the number of work units on the GPU for APs and MB the same (ie 2 per card in this case)
I figure out how many total (for both CPU and GPU, in your case 7) and list that in the <project_max_concurrent>

Then I allow the computer 100% use of all cores. This way It will only allow that total max to run at any point (as long as you have work) and their isn't any straggling or fighting for CPU cores. When I did that, my times improved and system was better responsiveness.

Something to think about. Looking at the CPU task I have running. They use 99.9% of each core. So there isn't much left for the GPU depending on what you have their CPU usage set at.

My 2 cents....

Zalster

Edit..

Cliff, if you suspend GPU crunching, do the CPU task start up?

I followed Zalster's advice a few weeks ago and tweaked it some just using the max_concurrent variable to free more cpu cores for these APs. When the APs dry up I will increase my max_concurrent variable to allow for more cpu wus, knowing that the MBs don't need as much cpu support. His advice is sound and did the trick for my multiple gpu setups.

---

This is the current version app_config.xml -

<app_config>
<app>
<name>setiathome_v7</name>
<gpu_versions>
<gpu_usage>.33</gpu_usage>
<cpu_usage>.5</cpu_usage>
</gpu_versions>
</app>
<app>
<name>astropulse_v7</name>
<max_concurrent>8</max_concurrent>
<gpu_versions>
<gpu_usage>.5</gpu_usage>
<cpu_usage>1</cpu_usage>
</gpu_versions>
</app>
</app_config>

The only recent change done was to change the cpu_usaage from .5 -> 1 to see if the kernel thrashing is reduced. Because the thrashing has not been reduced is more proof that the app_cmdline is not functioning. With the use of -use_sleep, thrashing should have been eliminated.

---

I don't buy computers, I build them!!

This is the current version app_config.xml -

<app_config>
<app>
<name>setiathome_v7</name>
<gpu_versions>
<gpu_usage>.33</gpu_usage>
<cpu_usage>.5</cpu_usage>
</gpu_versions>
</app>
<app>
<name>astropulse_v7</name>
<max_concurrent>8</max_concurrent>
<gpu_versions>
<gpu_usage>.5</gpu_usage>
<cpu_usage>1</cpu_usage>
</gpu_versions>
</app>
</app_config>

The only recent change done was to change the cpu_usaage from .5 -> 1 to see if the kernel thrashing is reduced. Because the thrashing has not been reduced is more proof that the app_cmdline is not functioning. With the use of -use_sleep, thrashing should have been eliminated.

Not sure you need that <max_concurrent> in the app_config.xml

Have you tried shutting down boinc and remove that max concurrent, save then restarting boinc and seeing if it makes any difference?

Just curious to see what it does.

This is the current version app_config.xml -

<app_config>
<app>
<name>setiathome_v7</name>
<gpu_versions>
<gpu_usage>.33</gpu_usage>
<cpu_usage>.5</cpu_usage>
</gpu_versions>
</app>
<app>
<name>astropulse_v7</name>
<max_concurrent>8</max_concurrent>
<gpu_versions>
<gpu_usage>.5</gpu_usage>
<cpu_usage>1</cpu_usage>
</gpu_versions>
</app>
</app_config>

The only recent change done was to change the cpu_usaage from .5 -> 1 to see if the kernel thrashing is reduced. Because the thrashing has not been reduced is more proof that the app_cmdline is not functioning. With the use of -use_sleep, thrashing should have been eliminated.

Not sure you need that <max_concurrent> in the app_config.xml

Have you tried shutting down boinc and remove that max concurrent, save then restarting boinc and seeing if it makes any difference?

Just curious to see what it does.

Made no difference.

---

I don't buy computers, I build them!!