It you installed the driver from windows, Microsoft doesn't usually supply the OpenCL components. It competes with their DirectCompute offering.
You need to go to GeForce.com and download the driver directly from Nvidia. Once you've got it make sure you do a "clean install" to remove the MS supplied driver. Once you've done that and rebooted check your BOINC start-up messages. After the CUDA line you should also see an OpenCL line for the Nvidia.
Every time MS does a driver update they usually clobber the Nvidia driver, so keep it handy so you can reinstall it next time.
Your GPU is cold because you don't have any GPU tasks for it to crunch :-0
You just need to get your BOINC client to ask for some GPU work - just like you showed in your very first log snip where the client was asking for both CPU and GPU work but only got CPU tasks. Your current log snip doesn't show a work request.
Also why do you need an app_config.xml? If you just want to be able to crunch more than one task concurrently, it's very easy to do by simply using the GPU utilization factor which is on your project preferences page. You should crunch at least one single task first just to prove everything is working correctly and to see how good the crunch time estimate is. Then change the factor (for FGRPB1G app - don't forget to save changes) to 0.5, and when a new task downloads, your GPU will switch to crunching two at a time. The crunch time will be longer but hopefully the time to finish two concurrently will be less than to crunch two consecutively and you will therefore see an improved output.
CPU tasks are designed to take quite a few hours - I've seen the staff mention > 12 hours for GW tasks. Since all of those you show are CPU tasks (if you expand the App column you will find the name of the CPU app for the gamma-ray search for the first four and the GW search for the remainder) it's not surprising to see those sort of times.
On a 'per core' basis, a high end system doesn't really crunch all that much faster than something like a lowly Pentium dual core from the same architectural family. The high end CPU just has more cores, perhaps running at a marginally better frequency. On top of that, you are essentially running two compute intensive tasks on a single physical core with your 8 core/16 thread processor so, whilst you will derive an output benefit, each thread will take quite a bit longer to crunch than if the task had sole access to the full core.
Where your system will really shine is by using your high end GPU. GPU tasks (only gamma-ray pulsar search at the moment - FGRPB1G), in terms of their work content, contain 5 times as much computation and derive 5 time as much credit 'reward'. However they will be completed in minutes rather than around 6.5 - 7 hours that your 4 FGRP5 tasks are going to take - approximately. Both these gamma-ray pulsar searches are necessary as they are looking for different things.
There are many ways to optimise your system once you get the searches you want running to your satisfaction. There is no 'one size fits all' recipe. Since input power may be expensive, and since heat produced is potentially damaging, there are a lot of factors to consider in working out the optimal conditions that you will be happy with. Some volunteers choose to cut back on, or even eliminate the CPU searches in order to cut power use and heat and take advantage of the greater output capability of the GPU. It's all a matter of personal choice.
As a followup to my previous reply, I just had a look at the details page for your computer and followed the link to the last time your computer contacted the scheduler. I was interested in seeing if there was any sign of a request for GPU tasks.
That last scheduler contact was for the purpose of reporting completed work, in fact the last of the four FGRP5 tasks you started with which are now all successfuly crunched and returned. However, if you have the FGRPB1G search enabled, there should have been a request for GPU work - and there wasn't. The scheduler log contained the lines:-
which means that neither CPU work nor GPU work was being requested (req 0.00 sec).
If you have reduced your work cache settings, or (more likely) if the completed tasks took longer than estimated, the no CPU work request is not surprising. However, with the GPU being properly recognised, there should have been a request for GPU work. The fact that there wasn't suggests that you don't have the gamma-ray pulsar search on GPUs (FGRPB1G) enabled?? You might like to check that. Just go to Account -> Preferences -> Project and make sure that "Use NVIDIA GPU" says "Yes" and (lower down under Applications) you have ticked the "Gamma-ray pulsar binary search #1 (GPU)". If you need to make changes, don't forget to "Save changes" right near the bottom of the page.
The other surprising entry in the scheduler log was that the scheduler sent you a batch of 12 "lost results". What this means is that some number of the tasks you had been allocated originally (at least 12) were no longer on your machine. They had gone 'missing in action' by some means. Whenever the scheduler detects this, it will send the missing stuff back to you, 12 tasks at a time, referring to them as 'lost results'. For that reason, you should never delete any BOINC or Project files at random. The scheduler knows what you should have and will simply replace anything found to be missing.
Can you think of why some of your tasks were missing? Tasks received are recorded in the state file (client_state.xml), the contents of which get reported to the scheduler when your client makes contact. If a number of <result> ...</result> entries in the state file were physically deleted on your computer (ie. edited out) that would be one way that would cause the scheduler to send you fresh copies of those tasks. It would be of interest to understand what caused those tasks to become 'missing'. If you need to get rid of excess tasks, the correct way is to select them on the tasks tab of BOINC Manager and click the abort button.
Gary, your support is very valuable. I've been checking and investigating, and I found my firewall being too suspicious. It blocked part of communication between BOINC and server. I fixed it and everything runs like a charm :) Thak you very much.
It you installed the driver
)
It you installed the driver from windows, Microsoft doesn't usually supply the OpenCL components. It competes with their DirectCompute offering.
You need to go to GeForce.com and download the driver directly from Nvidia. Once you've got it make sure you do a "clean install" to remove the MS supplied driver. Once you've done that and rebooted check your BOINC start-up messages. After the CUDA line you should also see an OpenCL line for the Nvidia.
Every time MS does a driver update they usually clobber the Nvidia driver, so keep it handy so you can reinstall it next time.
BOINC blog
AAAArrrrrrrgh!!!!!! MarkJ,
)
AAAArrrrrrrgh!!!!!! MarkJ, you made my day. I already have latest NVIDIA drivers installed.... but without "clean install". I did it. It works! Yay!
So... will someone share a good example of app_config.xml for Nvidia cards? :)
..but GPU still stays cool.
)
..but GPU still stays cool. No work done :\
26.05.2019 10:17:52 | | cc_config.xml not found - using defaults
26.05.2019 10:17:52 | | Starting BOINC client version 7.14.2 for windows_x86_64
26.05.2019 10:17:52 | | log flags: file_xfer, sched_ops, task
26.05.2019 10:17:52 | | Libraries: libcurl/7.47.1 OpenSSL/1.0.2g zlib/1.2.8
26.05.2019 10:17:52 | | Data directory: C:\ProgramData\BOINC
26.05.2019 10:17:52 | | Running under account szydas
26.05.2019 10:17:52 | | CUDA: NVIDIA GPU 0: GeForce RTX 2080 (driver version 430.64, CUDA version 10.2, compute capability 7.5, 4096MB, 3549MB available, 10068 GFLOPS peak)
26.05.2019 10:17:52 | | OpenCL: NVIDIA GPU 0: GeForce RTX 2080 (driver version 430.64, device version OpenCL 1.2 CUDA, 8192MB, 3549MB available, 10068 GFLOPS peak)
26.05.2019 10:17:52 | | Host name: stach
26.05.2019 10:17:52 | | Processor: 16 GenuineIntel Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz [Family 6 Model 158 Stepping 12]
26.05.2019 10:17:52 | | Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss htt tm pni ssse3 fma cx16 sse4_1 sse4_2 movebe popcnt aes f16c rdrandsyscall nx lm avx avx2 vmx smx tm2 pbe fsgsbase bmi1 hle smep bmi2
26.05.2019 10:17:52 | | OS: Microsoft Windows 10: Professional x64 Edition, (10.00.17763.00)
26.05.2019 10:17:52 | | Memory: 31.92 GB physical, 36.67 GB virtual
26.05.2019 10:17:52 | | Disk: 465.16 GB total, 160.59 GB free
26.05.2019 10:17:52 | | Local time is UTC +2 hours
26.05.2019 10:17:52 | | No WSL found.
26.05.2019 10:17:52 | Einstein@Home | Found app_config.xml
26.05.2019 10:17:52 | Einstein@Home | URL http://einstein.phys.uwm.edu/; Computer ID 12779640; resource share 100
26.05.2019 10:17:52 | Einstein@Home | General prefs: from Einstein@Home (last modified 25-May-2019 23:58:39)
26.05.2019 10:17:52 | Einstein@Home | Host location: none
26.05.2019 10:17:52 | Einstein@Home | General prefs: using your defaults
26.05.2019 10:17:52 | | Reading preferences override file
26.05.2019 10:17:52 | | Preferences:
26.05.2019 10:17:52 | | max memory usage when active: 16343.46 MB
26.05.2019 10:17:52 | | max memory usage when idle: 29418.23 MB
26.05.2019 10:17:52 | | max disk usage: 100.00 GB
26.05.2019 10:17:52 | | max CPUs used: 14
26.05.2019 10:17:52 | | (to change preferences, visit a project web site or select Preferences in the Manager)
26.05.2019 10:17:52 | | Setting up project and slot directories
26.05.2019 10:17:52 | | Checking active tasks
szydas wrote:..but GPU still
)
Your GPU is cold because you don't have any GPU tasks for it to crunch :-0
You just need to get your BOINC client to ask for some GPU work - just like you showed in your very first log snip where the client was asking for both CPU and GPU work but only got CPU tasks. Your current log snip doesn't show a work request.
Also why do you need an app_config.xml? If you just want to be able to crunch more than one task concurrently, it's very easy to do by simply using the GPU utilization factor which is on your project preferences page. You should crunch at least one single task first just to prove everything is working correctly and to see how good the crunch time estimate is. Then change the factor (for FGRPB1G app - don't forget to save changes) to 0.5, and when a new task downloads, your GPU will switch to crunching two at a time. The crunch time will be longer but hopefully the time to finish two concurrently will be less than to crunch two consecutively and you will therefore see an improved output.
Cheers,
Gary.
Ok... Just in case: are that
)
Ok... Just in case: are that usual processing times for (close to) high-end system? About 20% in almost 4 hours?
CPU tasks are designed to
)
CPU tasks are designed to take quite a few hours - I've seen the staff mention > 12 hours for GW tasks. Since all of those you show are CPU tasks (if you expand the App column you will find the name of the CPU app for the gamma-ray search for the first four and the GW search for the remainder) it's not surprising to see those sort of times.
On a 'per core' basis, a high end system doesn't really crunch all that much faster than something like a lowly Pentium dual core from the same architectural family. The high end CPU just has more cores, perhaps running at a marginally better frequency. On top of that, you are essentially running two compute intensive tasks on a single physical core with your 8 core/16 thread processor so, whilst you will derive an output benefit, each thread will take quite a bit longer to crunch than if the task had sole access to the full core.
Where your system will really shine is by using your high end GPU. GPU tasks (only gamma-ray pulsar search at the moment - FGRPB1G), in terms of their work content, contain 5 times as much computation and derive 5 time as much credit 'reward'. However they will be completed in minutes rather than around 6.5 - 7 hours that your 4 FGRP5 tasks are going to take - approximately. Both these gamma-ray pulsar searches are necessary as they are looking for different things.
There are many ways to optimise your system once you get the searches you want running to your satisfaction. There is no 'one size fits all' recipe. Since input power may be expensive, and since heat produced is potentially damaging, there are a lot of factors to consider in working out the optimal conditions that you will be happy with. Some volunteers choose to cut back on, or even eliminate the CPU searches in order to cut power use and heat and take advantage of the greater output capability of the GPU. It's all a matter of personal choice.
Cheers,
Gary.
As a followup to my previous
)
As a followup to my previous reply, I just had a look at the details page for your computer and followed the link to the last time your computer contacted the scheduler. I was interested in seeing if there was any sign of a request for GPU tasks.
That last scheduler contact was for the purpose of reporting completed work, in fact the last of the four FGRP5 tasks you started with which are now all successfuly crunched and returned. However, if you have the FGRPB1G search enabled, there should have been a request for GPU work - and there wasn't. The scheduler log contained the lines:-
which means that neither CPU work nor GPU work was being requested (req 0.00 sec).
If you have reduced your work cache settings, or (more likely) if the completed tasks took longer than estimated, the no CPU work request is not surprising. However, with the GPU being properly recognised, there should have been a request for GPU work. The fact that there wasn't suggests that you don't have the gamma-ray pulsar search on GPUs (FGRPB1G) enabled?? You might like to check that. Just go to Account -> Preferences -> Project and make sure that "Use NVIDIA GPU" says "Yes" and (lower down under Applications) you have ticked the "Gamma-ray pulsar binary search #1 (GPU)". If you need to make changes, don't forget to "Save changes" right near the bottom of the page.
The other surprising entry in the scheduler log was that the scheduler sent you a batch of 12 "lost results". What this means is that some number of the tasks you had been allocated originally (at least 12) were no longer on your machine. They had gone 'missing in action' by some means. Whenever the scheduler detects this, it will send the missing stuff back to you, 12 tasks at a time, referring to them as 'lost results'. For that reason, you should never delete any BOINC or Project files at random. The scheduler knows what you should have and will simply replace anything found to be missing.
Can you think of why some of your tasks were missing? Tasks received are recorded in the state file (client_state.xml), the contents of which get reported to the scheduler when your client makes contact. If a number of <result> ...</result> entries in the state file were physically deleted on your computer (ie. edited out) that would be one way that would cause the scheduler to send you fresh copies of those tasks. It would be of interest to understand what caused those tasks to become 'missing'. If you need to get rid of excess tasks, the correct way is to select them on the tasks tab of BOINC Manager and click the abort button.
Cheers,
Gary.
Gary, your support is very
)
Gary, your support is very valuable. I've been checking and investigating, and I found my firewall being too suspicious. It blocked part of communication between BOINC and server. I fixed it and everything runs like a charm :) Thak you very much.