Testing results from my W10, 4790k (@4.4ghz), GTX1080 (2ghz gpu, 10ghz ram) system. As I commented above, I'm not sure why the reported CPU load varied the way it did; but suspect the amount of CPU I was using for everything else may have been a factor.
1x 725s 413k/day 76% CPU load
2x 973s 615k/day 94% CPU load
3x 1378s 651k/day 87% CPU load
4x 1884s 635k/day 89% CPU load
Running the 3rd task is still worthwhile; although will need monitoring as the app is optimized since it wouldn't take much of an increase in GPU utilization to make 2x earn just as much as 3x.
On the plus side between the speedup in this app version and the restoration of 3465 credit per WU this is the first time E@H's GPU apps have been reasonably competitive with other high paying apps.
My most recent daily credit earned was ~900k, with current credit/task numbers suggesting it should stabilize around 1.1 to 1.2m/day. In comparison when I ran out of BRP tasks in late December and went to my various backup projects (primarily PrimeGrid and Collatz; with Milkyway, GPUGrid and Asteroids rounding the total out) I peaked at 1.4m.
On the minus side, I've had to intervene a lot more with this app to keep it running my GPU at full load. For whatever reason the scheduler would periodically decide to run a single GPU app and 7 CPU apps; and the only way I could force it to stop was to cap the number of CPU tasks via app.config. Currently I'm at 4 GW and 1 FRGP task (based on my approximate current work cache); but to simplify the maintenance of the system I'm probably going to set both to 5 locally and turn off one app on the server.
For whatever reason the scheduler would periodically decide to run a single GPU app and 7 CPU apps; and the only way I could force it to stop was to cap the number of CPU tasks via app.config. Currently I'm at 4 GW and 1 FRGP task (based on my approximate current work cache); but to simplify the maintenance of the system I'm probably going to set both to 5 locally and turn off one app on the server.
Hi Dan,
I found a trick with the app_config. If you put the cpu usage for the FRGP app to below 1 cpu core each, they will always run and just 'steal' the core anyways. They don't seem to listen.
So for your optimal 3 tasks, 0.3cpu & 0.3 gpu should do the trick.
Quote:
Running the 3rd task is still worthwhile
Strange how you got different results then I did...on paper we have almost identical systems.
For whatever reason the scheduler would periodically decide to run a single GPU app and 7 CPU apps; and the only way I could force it to stop was to cap the number of CPU tasks via app.config. Currently I'm at 4 GW and 1 FRGP task (based on my approximate current work cache); but to simplify the maintenance of the system I'm probably going to set both to 5 locally and turn off one app on the server.
Hi Dan,
I found a trick with the app_config. If you put the cpu usage for the FRGP app to below 1 cpu core each, they will always run and just 'steal' the core anyways. They don't seem to listen.
So for your optimal 3 tasks, 0.3cpu & 0.3 gpu should do the trick.
I just tried that and ended up with 8 CPU tasks and 3 GPU tasks fighting over my 8 available cores. As soon as one of the GPU tasks completed it was 8 and 2. All the extra context switches slow all your apps down and lower your throughput below that from only having the right number; and as a second anti-bonus it quickly restored the schedulers love for running CPU tasks at the expense of keeping my GPU fed.
wes. wrote:
Quote:
Running the 3rd task is still worthwhile
Strange how you got different results then I did...on paper we have almost identical systems.
Your 970 showed a 5.7% bump in credit from running 3x vs 2, my 1080 got a 5.8% bump; and if your cards total output is less than mine 5.3 more GPU tasks/day is an extra 18k credit which is a lot more than the core can do running CPU tasks. Did you have a second test run that didn't show anything from the 3rd task elsewhere in the thread? I was looking at:
I just tried that and ended up with 8 CPU tasks and 3 GPU tasks fighting over my 8 available cores. As soon as one of the GPU tasks completed it was 8 and 2.
Strange. Seems to work perfectly on mine. Sorry it didn't help.
I just tried that and ended up with 8 CPU tasks and 3 GPU tasks fighting over my 8 available cores. As soon as one of the GPU tasks completed it was 8 and 2.
Strange. Seems to work perfectly on mine. Sorry it didn't help.
Of course, if you were to spend a little more you could get something like an RX 480 - a lot cheaper in your country than in mine. I saw an RX 480 on newegg for just 160 bucks after rebate.
Just bought one...Will post timings...It's all your fault Gary.
Not to rain on anyone's parade but Gary totally ignored the machine at positions 2,3,4....
Wes wrote:
Of course this could all change next app or even when the RAC finalizes. But at this time, the RX 480's are 1.86 times better at crunching einstein (point per $) than GTX 1070's.
Both of you need to cool down a bit. This is NOT (at least it shouldn't be) a dogfight between the two camps. We should celebrate the fact that competition is alive and well and this is producing great outcomes for people who want to crunch. If you think about my original comments, they were all about how relatively cheap it is for the average person to have a decent crunching machine if they want to. It started when I simply said to Magic that for less than 100 bucks he could get a GPU that would 'fix' his low RAC woes :-).
Anyone wanting to use the top hosts stats to argue some particular point should realise how flawed such an argument could be. You should at least go to the trouble of working out the average crunch time for a significant number of tasks and from that average (and how many are being done concurrently) work out a theoretical daily production. That would counteract factors such as not running for 100% of the time or RAC not yet stabilised. To get the likely 'concurrency' being used (on the assumption of 100% running time and a RAC close to stability and negligible CPU credits) I use this formula:-
concurrency = RAC X av. crunch secs / secs per day / credit per task
It would be tempting to say the concurrency is 4 - x2 per GPU - but the way RAC has been rising (800K to 900K in the last day or so) it's highly likely that it has to be the next even number above 4, ie. 6 which is x3 per GPU. I agree with Zalster that the RAC is likely to end up around 1.2M or more.
Theoretical RAC = 86400 X 6 X 3465 / 1350 = 1.33M
All this is very interesting but not particularly relevant to what I'm trying to say. I don't care at all what people decide to buy. Both NVIDIA and AMD will have appealing offerings that will suit a particular budget. My entire point was nothing to do with particular rankings of particular hosts so it's quite rich to assert that I'm ignoring certain hosts. I chose a particular machine, not because it was #8 (or any particular position for that matter) but simply because of the ease (divide a number by 2) in giving a hint of what might be achievable for 160 bucks for a single GPU (plus perhaps a PSU upgrade if necessary).
There are lots of volunteers out there using older machines with integrated or low range discrete GPUs that can only really do CPU tasks at the moment. Many of these hosts would be in the 2008 - 2012 age range (quite suited to an upgrade) and making only a few K credits per day. By spending 90 bucks, it's possible to get to 200+K per day or by spending a bit more, 600K. Of course, it's the extra hardware cost plus the additional cost of electricity but I think this sort of an upgrade would be quite affordable for lots of people.
The day is rapidly coming when all apps at this project are likely to have efficient GPU versions. Increasingly, there will likely be a trend to not crunch at all on the CPU. Even now, the CPU doesn't really matter. The output of an efficient GPU is relatively unaffected by the quality of the CPU/motherboard powering it. You can actually lower the running costs and improve the output per watt by not using the CPU to crunch.
Gary said: Even now, the CPU doesn't really matter. The output of an efficient GPU is relatively unaffected by the quality of the CPU/motherboard powering it.
Case in point. https://einsteinathome.org/host/12255955
196k rac and climbing with an E5400 CPU, almost as old as Gary is...just kidding of course.
From my own experiments adjusting app_config file CPU usage for GPU apps only limits how many CPU threads are left for other CPU only tasks. Previously I would make it low so I wouldn't lose a CPU thread. That was previous E@H apps, Collatz, MW, and Asteroids. For these new E@H OpenCL tasks I lose GPU utilization unless I reduce the #of CPUs used in Boinc Manager to leave one completely free. IE on my 3770k there are 3 CPU tasks running and 2 WUs on the 1070 and 970. Splitting it 4 and 4 would drop the 1070s GPU util even with the exe limited to certain cores with Process Lasso. I might try to separate them even more to see if I can still run 4 CPU tasks. Previously the GPU exe files would just take any CPU that was needed even with 8x CPU tasks running. I was just running 6x Asteroids tasks at 99-100% per GPU. That wait loop in OpenCL on NV cards is vicious.
As far as GPU tasks (I have been gone a few days so I just read replies to something I said) I have ONLY ran Einstein tasks and have no idea what any other projects do or run with GPU tasks.
As far as what the former BRP tasks when I say pure GPU that means I only needed ONE free CPU core and if I wanted to could run all cores doing other tasks that are CPU only and those are the Cern VB tasks that I have been running for 6 years.
These can not be run that way.
Before I could run GPU X2 on all my GPU cards and then run the Cern VB tasks on 3 of the 4 CPU cores and leave only ONE free.
With these just on that one SC'd 660Ti I have to use all 4 cores to run GPU X2 here to get them finished in 2 hours.
So when running the Cern tasks and these GPU tasks I needed to load them with the GPU tasks and not check all 7 pc's every day to balance them with the Cern VB tasks before.......now they can't run at the same time so these I have to run while the others are suspended and switch back and forth just with the one.
I tried the OC's 560Ti and since it is in a 3-core phenom they were taking closer to 8 hours to run X2 with a free core.
Didn't even try the 650Ti's or the 550Ti's I have since it is obvious what will happen and they run ALL cores with the Cern VB tasks and I am not going to replace those cards just to get new ones since they aren't old worn out cards and when it comes down to it those CPU's will not run that much longer since they have been around since Windows 7 was new......already spent plenty doing this including the power bill.
Updated 4 of them to Windows 10 did clean installs of 7 on two of them and one is staying with XP Pro until it ever decides to quit and it has ran 24/7 since November 2001 (to prove a point)
I didn't get over 300 million credits here for free or by not knowing how this works.
And they are all the longest running and top of the stats page at Cern so 24/7 for this long is great but replacing it all is not something I want to do..........I was just wishing it was like the previous GPU versions here which were also beta.
If it comes to spending a bunch of money to ever replace my 7 computers it will be with a new version HDTV to replace my 82in DLP and lots of other things I could use here at home since I am not a youngster and never had a pc to play games so I will let you all take care of buying new cards and MB's and CPU's.......and I could use a new riding mower since my lawn is 3 acres and I want it to be easier not harder every year
Testing results from my W10,
)
Testing results from my W10, 4790k (@4.4ghz), GTX1080 (2ghz gpu, 10ghz ram) system. As I commented above, I'm not sure why the reported CPU load varied the way it did; but suspect the amount of CPU I was using for everything else may have been a factor.
Running the 3rd task is still worthwhile; although will need monitoring as the app is optimized since it wouldn't take much of an increase in GPU utilization to make 2x earn just as much as 3x.
On the plus side between the speedup in this app version and the restoration of 3465 credit per WU this is the first time E@H's GPU apps have been reasonably competitive with other high paying apps.
My most recent daily credit earned was ~900k, with current credit/task numbers suggesting it should stabilize around 1.1 to 1.2m/day. In comparison when I ran out of BRP tasks in late December and went to my various backup projects (primarily PrimeGrid and Collatz; with Milkyway, GPUGrid and Asteroids rounding the total out) I peaked at 1.4m.
On the minus side, I've had to intervene a lot more with this app to keep it running my GPU at full load. For whatever reason the scheduler would periodically decide to run a single GPU app and 7 CPU apps; and the only way I could force it to stop was to cap the number of CPU tasks via app.config. Currently I'm at 4 GW and 1 FRGP task (based on my approximate current work cache); but to simplify the maintenance of the system I'm probably going to set both to 5 locally and turn off one app on the server.
DanNeely wrote: For whatever
)
Hi Dan,
I found a trick with the app_config. If you put the cpu usage for the FRGP app to below 1 cpu core each, they will always run and just 'steal' the core anyways. They don't seem to listen.
So for your optimal 3 tasks, 0.3cpu & 0.3 gpu should do the trick.
Strange how you got different results then I did...on paper we have almost identical systems.
wes. wrote:DanNeely
)
I just tried that and ended up with 8 CPU tasks and 3 GPU tasks fighting over my 8 available cores. As soon as one of the GPU tasks completed it was 8 and 2. All the extra context switches slow all your apps down and lower your throughput below that from only having the right number; and as a second anti-bonus it quickly restored the schedulers love for running CPU tasks at the expense of keeping my GPU fed.
Your 970 showed a 5.7% bump in credit from running 3x vs 2, my 1080 got a 5.8% bump; and if your cards total output is less than mine 5.3 more GPU tasks/day is an extra 18k credit which is a lot more than the core can do running CPU tasks. Did you have a second test run that didn't show anything from the 3rd task elsewhere in the thread? I was looking at:
https://einsteinathome.org/goto/comment/154444
Quote:I just tried that and
)
Strange. Seems to work perfectly on mine. Sorry it didn't help.
Scroll down after clicking that link?
wes. wrote:Quote: I just
)
Scrolling down below your 970 result with 3 being marginally better than 2 I get a post of yours that has nothing to do with GPU efficiency, and one about your buying a Radeon 480.
Zalster wrote:wes. wrote:Gary
)
Both of you need to cool down a bit. This is NOT (at least it shouldn't be) a dogfight between the two camps. We should celebrate the fact that competition is alive and well and this is producing great outcomes for people who want to crunch. If you think about my original comments, they were all about how relatively cheap it is for the average person to have a decent crunching machine if they want to. It started when I simply said to Magic that for less than 100 bucks he could get a GPU that would 'fix' his low RAC woes :-).
Anyone wanting to use the top hosts stats to argue some particular point should realise how flawed such an argument could be. You should at least go to the trouble of working out the average crunch time for a significant number of tasks and from that average (and how many are being done concurrently) work out a theoretical daily production. That would counteract factors such as not running for 100% of the time or RAC not yet stabilised. To get the likely 'concurrency' being used (on the assumption of 100% running time and a RAC close to stability and negligible CPU credits) I use this formula:-
concurrency = RAC X av. crunch secs / secs per day / credit per taskSo for the #8 host this becomes
concurrency = 905,000 X 1,350 / 86,400 / 3,465 = 4.08It would be tempting to say the concurrency is 4 - x2 per GPU - but the way RAC has been rising (800K to 900K in the last day or so) it's highly likely that it has to be the next even number above 4, ie. 6 which is x3 per GPU. I agree with Zalster that the RAC is likely to end up around 1.2M or more.
Theoretical RAC = 86400 X 6 X 3465 / 1350 = 1.33MAll this is very interesting but not particularly relevant to what I'm trying to say. I don't care at all what people decide to buy. Both NVIDIA and AMD will have appealing offerings that will suit a particular budget. My entire point was nothing to do with particular rankings of particular hosts so it's quite rich to assert that I'm ignoring certain hosts. I chose a particular machine, not because it was #8 (or any particular position for that matter) but simply because of the ease (divide a number by 2) in giving a hint of what might be achievable for 160 bucks for a single GPU (plus perhaps a PSU upgrade if necessary).
There are lots of volunteers out there using older machines with integrated or low range discrete GPUs that can only really do CPU tasks at the moment. Many of these hosts would be in the 2008 - 2012 age range (quite suited to an upgrade) and making only a few K credits per day. By spending 90 bucks, it's possible to get to 200+K per day or by spending a bit more, 600K. Of course, it's the extra hardware cost plus the additional cost of electricity but I think this sort of an upgrade would be quite affordable for lots of people.
The day is rapidly coming when all apps at this project are likely to have efficient GPU versions. Increasingly, there will likely be a trend to not crunch at all on the CPU. Even now, the CPU doesn't really matter. The output of an efficient GPU is relatively unaffected by the quality of the CPU/motherboard powering it. You can actually lower the running costs and improve the output per watt by not using the CPU to crunch.
Cheers,
Gary.
Gary said: Even now, the CPU
)
Gary said: Even now, the CPU doesn't really matter. The output of an efficient GPU is relatively unaffected by the quality of the CPU/motherboard powering it.
Case in point. https://einsteinathome.org/host/12255955
196k rac and climbing with an E5400 CPU, almost as old as Gary is...just kidding of course.
From my own experiments
)
From my own experiments adjusting app_config file CPU usage for GPU apps only limits how many CPU threads are left for other CPU only tasks. Previously I would make it low so I wouldn't lose a CPU thread. That was previous E@H apps, Collatz, MW, and Asteroids. For these new E@H OpenCL tasks I lose GPU utilization unless I reduce the #of CPUs used in Boinc Manager to leave one completely free. IE on my 3770k there are 3 CPU tasks running and 2 WUs on the 1070 and 970. Splitting it 4 and 4 would drop the 1070s GPU util even with the exe limited to certain cores with Process Lasso. I might try to separate them even more to see if I can still run 4 CPU tasks. Previously the GPU exe files would just take any CPU that was needed even with 8x CPU tasks running. I was just running 6x Asteroids tasks at 99-100% per GPU. That wait loop in OpenCL on NV cards is vicious.
As far as GPU tasks (I have
)
As far as GPU tasks (I have been gone a few days so I just read replies to something I said) I have ONLY ran Einstein tasks and have no idea what any other projects do or run with GPU tasks.
As far as what the former BRP tasks when I say pure GPU that means I only needed ONE free CPU core and if I wanted to could run all cores doing other tasks that are CPU only and those are the Cern VB tasks that I have been running for 6 years.
These can not be run that way.
Before I could run GPU X2 on all my GPU cards and then run the Cern VB tasks on 3 of the 4 CPU cores and leave only ONE free.
With these just on that one SC'd 660Ti I have to use all 4 cores to run GPU X2 here to get them finished in 2 hours.
So when running the Cern tasks and these GPU tasks I needed to load them with the GPU tasks and not check all 7 pc's every day to balance them with the Cern VB tasks before.......now they can't run at the same time so these I have to run while the others are suspended and switch back and forth just with the one.
I tried the OC's 560Ti and since it is in a 3-core phenom they were taking closer to 8 hours to run X2 with a free core.
Didn't even try the 650Ti's or the 550Ti's I have since it is obvious what will happen and they run ALL cores with the Cern VB tasks and I am not going to replace those cards just to get new ones since they aren't old worn out cards and when it comes down to it those CPU's will not run that much longer since they have been around since Windows 7 was new......already spent plenty doing this including the power bill.
Updated 4 of them to Windows 10 did clean installs of 7 on two of them and one is staying with XP Pro until it ever decides to quit and it has ran 24/7 since November 2001 (to prove a point)
I didn't get over 300 million credits here for free or by not knowing how this works.
And they are all the longest running and top of the stats page at Cern so 24/7 for this long is great but replacing it all is not something I want to do..........I was just wishing it was like the previous GPU versions here which were also beta.
If it comes to spending a bunch of money to ever replace my 7 computers it will be with a new version HDTV to replace my 82in DLP and lots of other things I could use here at home since I am not a youngster and never had a pc to play games so I will let you all take care of buying new cards and MB's and CPU's.......and I could use a new riding mower since my lawn is 3 acres and I want it to be easier not harder every year
I keep reading these threads
)
I keep reading these threads in the hope of seeing the announcement of of a cuda app for this gamma ray thing but no joy.