Posted 1 Jun 2020 by
RFGuy_KCCO
Thank you very much for the idea !
I just gave it a try.
- 1 WU per GPU: 12-13 seconds, GPU Load: 95%.
- 2 WUs per GPU: 18-19 seconds, GPU Load: 100%.
I'm going to leave it running to see if it doesn't make mistakes...
So the RTX 2080 Ti GPU can produce even more !
To do this, you have to enter these parameters in an app_config.xml :
<app_config> <app> <name>TF</name> <gpu_versions> <gpu_usage>0.5</gpu_usage> <cpu_usage>0.5</cpu_usage> </gpu_versions> </app> </app_config>
You don't even need to allocate that much CPU to the WUs, at least when using an Nvidia GPU. My 2080's under both Windows and Linux use virtually zero CPU cycles when running these WUs. I allocate only .25 CPU per WU, but you could go as low as .1 if you wanted to. I have as a test (I always test multiple configs when running a new project to find the best settings - I am an engineer by trade) and noticed no difference in completion times. Seems these WUs (again, at least on Nvidia GPUs) do all of their computations on the GPU.
Posted 1 Jun 2020 by
RFGuy_KCCO
The limit is now 50, this could be enough for a short downtime of doing a db backup.
Thank you!
Posted 1 Jun 2020 by
RFGuy_KCCO
You can trick the server by saying you have x amount of GPU’s or CPU’s. You are too naive. If we had 2700 GPU how many wus would we all be doing per day? Make the calculations.
And exactly what is the purpose of doing so? Why not just accept the amount that the server send out?
Doing the last request would actually make it possible to calculate the real ressources we have - now in stead of a very huge production we only have a very huge cue of work waiting to be processed.
Maybe a setting on the server could/should be made to render that possibility IMPOSSIBLE - is that possible Reb?
A note on my third question is that the server has proven reliable enough to sustain the users with enough work even if they have only 20 workunits cued per host.
While I don't personally do it (I keep all of my computers visible and what you see there is 100% accurate), some crunchers do this in order to have more work in queue in case of a site outage. Another reason some do it because they have limited internet connection times, so they connect when they are able and get as much work as they need to continue crunching until the next time they can connect. Those who participate in the various team competitions (Formula BOINC, BOINC Pentathlon, etc.) do it for bunkering purposes. I'm sure there are other reasons, as well.
In all honesty, you really should consider upping the limit from 20 to a higher value because those of us with fast GPU's burn through 20 WU's very quickly. My 2080's and 2080 Supers running at 135W power limit are currently completing the latest WU's in ~31 seconds, while running 2 per GPU. That means I finish 20 WU's in just over 5 minutes. Maybe up the limit to 100, at least?
Posted 31 May 2020 by
RFGuy_KCCO
I’m fine with whatever size WU’s you choose to give us. My 2080’s don’t mind if they are large WU’s or small, they will just chew them up and spit them out either way.
Posted 28 Apr 2020 by
RFGuy_KCCO
Was there ever any progress made in getting this to run on each GPU in multi-GPU systems? Sorry if I missed a post about it.
Posted 4 Apr 2020 by
RFGuy_KCCO
After checking with other projects I will increase the credits for all new batches by a factor of 3.3
Awesome! Thank you!
Posted 4 Apr 2020 by
RFGuy_KCCO
There will be a new batch 77-78bit needed by GIMPs:
- runtime 16,5h (@RX5500 XT)
- 49500 credits
- deadline 8d (+1d grace_period)
- 10k WUs
16+ hours per WU? If that is correct, you're going to have to give more than 49,500 points per WU. Not worth running it at those rates, unless someone just loves this project.
Posted 31 Mar 2020 by
RFGuy_KCCO
On one of my systems I have a HD7950 (Dev 0) and a Vega 64 (Dev 1). If I include the following in the options section of my cc_config.xml file:
<exclude_gpu> <url>http://srbase.my-firewall.org/sr5/</url> <type>ATI</type> <device_num>0</device_num> <app>GPU72</app> </exclude_gpu>
That should tell it to ignore my 7950 (Dev 0) and run on my Vega 64. However, that is not the case. It still runs on the 2st device no matter what. The status column in BOINC manager says it's running on Device 1 like the cc_config.xml tells it to, but according to GPU utilization in both GPU-Z and HWiNFO it is still running on 1st device.
EDIT: So by default nature of the app, it will always use the 1st device no matter what it is told in cc_config or app_config it seems? At least on AMD GPUs. NVIDIA is a different story I think?
I'm successfully using this in my cc_config to exclude the second GPU in all of my two-GPU systems, so that one doesn't go to waste when running GPU72. I am running another project on the second GPU in those rigs.
Posted 25 Dec 2014 by
RFGuy_KCCO
part 1/2
- n=100-150k / 150-200k (2)
- runtime 7min-34min (AVX @4GHz)
- 100-125k = 35 credits
- 125-150k = 67 credits
- 150-175k = 96 credits
- 175-200k = 150 credits
- deadline 10 hours
Why are the deadlines so short? It makes every WU high priority when they run on my machines, preempting other work. Please make longer deadlines, or I will have to drop out of supporting this project.
I need the results back as fast as possible. Iam running 2 projects at the same time and I cant see any high priority with BOINC 7.4.36.
I understand. I just run quite a few projects and having brand new SRBase WU's constantly preempting WU's from other projects is frustrating. Not a deal breaker, though, as I do love these mathematics projects.
Thanks for the tip on BOINC 7.4.36. I will DL that now and see if it improves the preemptions. I am currently running 7.4.27.
Posted 23 Dec 2014 by
RFGuy_KCCO
part 1/2
- n=100-150k / 150-200k (2)
- runtime 7min-34min (AVX @4GHz)
- 100-125k = 35 credits
- 125-150k = 67 credits
- 150-175k = 96 credits
- 175-200k = 150 credits
- deadline 10 hours
Why are the deadlines so short? It makes every WU high priority when they run on my machines, preempting other work. Please make longer deadlines, or I will have to drop out of supporting this project.