Discussion Thread for the Continuous GW Search known as O2MD1 (now O2MDF - GPUs only)

Mine did not fail when I was running two GW WUs on a 4GB card and exceeded 4GB.  It just used system RAM and went a lot slower (about 3-4 times slower).

How about changing it to 0.5+ 0.1? It will poll more frequently while not carrying as big a cache. And your production will be the same.

Tom M

Lovely, missing reference to both GW tasks. Fixed.

I have thrown up my hands and dropped the excludes and switched on GW gpu only.  Its beginning to look like you can have one or the other but running both on the same machines gpus is a major hassle.

I've been running the beta app (v2.08, GW-opencl-ati-Beta) overnight on my 4-thread Linux system and have seen a good performance boost over the standard app. All the runs have been with VelaJr1 tasks, so I don't yet know about validations, but there have been no errors so far from about 100 completed tasks.

Comparisons of realized single run times (minutes) for 2 RX 570s, running O1MDFV2g_VelaJr1_1475.xxHz:

Times for the standard app differ from what I previously posted because the tasks spanned a different set of analysis frequencies, I'm guessing.

Beta can run a single task about 10% faster, but the biggest improvement was a more efficient use of system resources to allow higher task multiplicities and greater task productivity. Previously, I was not able to run 2GPU@2x with the std app because either GPU or GPU resources were limiting, which resulted in longer realized task times. With the Beta app, however, at least with this current batch of tasks, I can run four concurrent tasks and see shortened task times.

Even better task times can be had at 3x tasks on a single GPU, but running both GPUs at 3x resulted in a nearly doubled increase of task time. I found a trick, however, to run 5 concurrent tasks across two GPUs on my system to realize the best of all possible worlds: in app_config.xml set gpu_usage to 0.33 and cpu_usage to the default 0.9 (or 1). I usually have cpu_usage set to 0.4 or 0.5, which allows boinc-client to run 6, or even 8, concurrent tasks across two GPUs. Increasing cpu_usage restricts the number of concurrent tasks to 5, thus maximizing task productivity on my system. I expect that systems with different CPU and GPU capacities would need different boinc-client configurations to maximize productivity. I don't know how well this odd-ball configuration works with the non-VelaJr GW tasks.   

Arcana note: Background system processes of smda0 and comp_1 now use far less CPU resources than previously, whereas previously (i.e. last month) they would take up the majority of CPU time at higher multiplicities for GW GPU tasks.  Through observation I have learned that these two processes are related to AMD GPU activity, and guess they are called by the AMD drivers. One smda0 process is run for one active GPU, two for two active GPUs; 'active' meaning a non-zero GPU load. One comp_1 process is needed for each active boinc task on a GPU, or associated with one smda0 process; i.e. 3 concurrent tasks have 3 comp_1 processes running (comp_1.0.0, comp_1.1.0, comp_1.2.0); a second GPU running @ 3x doubles up on those comp processes.
I am not sure whether the lighter CPU use of these processes is because of the current set of tasks, or because of a recent AMDGPU driver package update that I did for the OpenCL component (amdgpu-pro-20.10-1048554-ubuntu-18.04, updated from amdgpu-pro-19.50-967956-ubuntu-18.04),