I still think it is too early to declare a tie for 1.52 vs 1.57 app runtimes. Not enough results yet in my opinion. However, it is not the case with the runtimes of the SETI and MW tasks run alongside the Einstein 1.52 tasks. My SETI and MW tasks sped up. Got back to their norms.
Luckily I don't have to manually configure how the tasks run. I have been running my three projects long enough with their resource shares that they have normalized. I only end up with a single Einstein task running at a time on both of my cards on both systems. I am back to normally finishing the BRP6 tasks within the two cycles of 70 minute share rotations. This was not the case with the 1.57 app. Almost every one ended up taking 3 cycles of share rotation to finish, thus my daily output dropped on both systems. It looks like my RAC is heading back up.
Keith, the runtimes your PCs are achieving with 1.52 don't look any better than 1.57. There's certainly a large variation in runtime, so it's difficult to judge performance by eye. Did something else change along with the new app?
MrS
I have switched from Binary Radio Pulsar Search (Parkes PMPS XT) v1.52 (BRP6-cuda32-nv301) to Binary Radio Pulsar Search (Parkes PMPS XT) v1.57 (BRP6-Beta-cuda55) and gained near 20% in run time: my average of run time for five v1.57 WU is 10:12 h and for v1.52 WU is 12:30 h. WUs are crunched one at a time while no CPU work is being done on a laptop with the following specs.
Quote:
CPU type GenuineIntel
Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz [Family 6 Model 60 Stepping 3]
Number of processors 8
Coprocessors NVIDIA GeForce GT 740M (2048MB) driver: 35330, INTEL Intel(R) HD Graphics 4600 (1425MB)
Operating System Microsoft Windows 8.1
Core x64 Edition, (06.03.9600.00)
BOINC client version 7.4.42
Memory 4007.96 MB
Cache 256 KB
Hi Folks,
I've discovered why my run times seemed to be increasing over time.
About the time that BRP6 1.57 arrived I made a config error in Boinc:-(
I'd set cpu usage on local settings to '0' ie unlimited.. big mistake!
When considering what alterations had been made beside the use of 1.57
I remembered altering the local configs, so I looked and changed cpu usage back to 80% and lo and behold times started to decrease..
Since the cores used is set to 2, it had seemed like a good idea to allow
100% cpu usage.. All that did was slow everything down it seems.
Anyway cpu is back to 80 again and times are getting back to what I'd expected for tasks
This is a bit off topic but related. I couldn't find an appropriate thread and didn't feel I should to open a new one for this question.
With the increase in performance we've seen for Kepler and Maxwell cards in BRP6 with CUDA55, is there a plan to release a similarly updated CUDA app for BRP4G as well?
This is a bit off topic but related. I couldn't find an appropriate thread and didn't feel I should to open a new one for this question.
With the increase in performance we've seen for Kepler and Maxwell cards in BRP6 with CUDA55, is there a plan to release a similarly updated CUDA app for BRP4G as well?
Thanks.
Erm.. BRP4G 1.52 ?? beta but it's still an updated app.
However not CUDA 55:-)
BTW whats the problem with CUDA 6 & 7? Anyone?
This is a bit off topic but related. I couldn't find an appropriate thread and didn't feel I should to open a new one for this question.
With the increase in performance we've seen for Kepler and Maxwell cards in BRP6 with CUDA55, is there a plan to release a similarly updated CUDA app for BRP4G as well?
Thanks.
Erm.. BRP4G 1.52 ?? beta but it's still an updated app.
However not CUDA 55:-)
BTW whats the problem with CUDA 6 & 7? Anyone?
Cheers,
Yes, the BRP4G 1.52 Beta is working nicely for me, but it is CUDA32 and I was just wondering if we might see a CUDA55 app if there is any benefit over the current beta app.
I was also curious about why CUDA55 as opposed to more recent CUDA versions. Perhaps there is just nothing in CUDA 6+ that E@H can take advantage of?
Again, I apologize for this being a bit off-topic.
Below are the results I have seen with the beta CUDA 5.5 Linux application in a format similar to what was used in the BRP6 RESULTS ONLY thread in the Cruncher's Corner message board.
[pre]
CPU: Intel 3930K @ 4.0 GHz
Cores/Threads: 6 / 6
Motherboard: ASUS Rampage IV Formula
PCIe slot PCIe 3.0 x16 (3.0 enabled using modprobe nvidia NVreg_EnablePCIeGen3=1)
1st GPU: EVGA 780 Ti SC ACX
2nd GPU: -
3rd GPU: -
RAM: 4 x 4GB DDR3
Concurrency: 2 @ 0.2 CPUs + 0.5 GPUs
CPU Tasks: 4 x FGRP4
Free CPU cores: ~ 2
OS: Linux 3.12.31
Driver: NVIDIA 352.30
BOINC Version: 7.4.42 64bit
Mean Times - secs Elapsed time Stats CPU time Stats
----------------- --------------------- ------------------- Sample
Search Elapsed CPU part Std Devn Variance Std Devn Variance Size Notes / Comments
====== ======= ======== ======== ======== ======== ======== ====== ================
BRP6 3,771 496 178 31,605 20 408 114 v1.54 CUDA 5.5 application, samples validated
[/pre]
====####====
COMMENTS
* There have been no invalid results yet.
* Estimated RAC based on average GPU elapsed time and concurrency is ~201,623.
* GPU Fan speed manually set to 80%.
I was also curious about why CUDA55 as opposed to more recent CUDA versions. Perhaps there is just nothing in CUDA 6+ that E@H can take advantage of?
I think that's it. And Einstein has historically supported a large user base with a huge variety of systems. Moving to a newer CUDA version would cut some people out who are limited to older drivers for some reason. One could combat this by deploying multiple app versions for different CUDA versions, but this creates more work during building & validation. So it's always a trade-off and the choice has been CUDA 5.5 as a "golden standard" this time. It doesn't exclude too many crunchers but provides a significant gain over CUDA 3.2.
I still think it is too early
)
I still think it is too early to declare a tie for 1.52 vs 1.57 app runtimes. Not enough results yet in my opinion. However, it is not the case with the runtimes of the SETI and MW tasks run alongside the Einstein 1.52 tasks. My SETI and MW tasks sped up. Got back to their norms.
Luckily I don't have to
)
Luckily I don't have to manually configure how the tasks run. I have been running my three projects long enough with their resource shares that they have normalized. I only end up with a single Einstein task running at a time on both of my cards on both systems. I am back to normally finishing the BRP6 tasks within the two cycles of 70 minute share rotations. This was not the case with the 1.57 app. Almost every one ended up taking 3 cycles of share rotation to finish, thus my daily output dropped on both systems. It looks like my RAC is heading back up.
RE: Keith, the runtimes
)
I have switched from Binary Radio Pulsar Search (Parkes PMPS XT) v1.52 (BRP6-cuda32-nv301) to Binary Radio Pulsar Search (Parkes PMPS XT) v1.57 (BRP6-Beta-cuda55) and gained near 20% in run time: my average of run time for five v1.57 WU is 10:12 h and for v1.52 WU is 12:30 h. WUs are crunched one at a time while no CPU work is being done on a laptop with the following specs.
I do not see an improvement
)
I do not see an improvement in run time from 1.52 to 1.57 on my laptop.
This seems to be in line with this comment.
Hi Folks, I've discovered why
)
Hi Folks,
I've discovered why my run times seemed to be increasing over time.
About the time that BRP6 1.57 arrived I made a config error in Boinc:-(
I'd set cpu usage on local settings to '0' ie unlimited.. big mistake!
When considering what alterations had been made beside the use of 1.57
I remembered altering the local configs, so I looked and changed cpu usage back to 80% and lo and behold times started to decrease..
Since the cores used is set to 2, it had seemed like a good idea to allow
100% cpu usage.. All that did was slow everything down it seems.
Anyway cpu is back to 80 again and times are getting back to what I'd expected for tasks
Cheers
Cliff,
Been there, Done that, Still no damm T Shirt.
This is a bit off topic but
)
This is a bit off topic but related. I couldn't find an appropriate thread and didn't feel I should to open a new one for this question.
With the increase in performance we've seen for Kepler and Maxwell cards in BRP6 with CUDA55, is there a plan to release a similarly updated CUDA app for BRP4G as well?
Thanks.
Hi Matt, RE: This is a
)
Hi Matt,
Erm.. BRP4G 1.52 ?? beta but it's still an updated app.
However not CUDA 55:-)
BTW whats the problem with CUDA 6 & 7? Anyone?
Cheers,
Cliff,
Been there, Done that, Still no damm T Shirt.
RE: Hi Matt,RE: This is a
)
Yes, the BRP4G 1.52 Beta is working nicely for me, but it is CUDA32 and I was just wondering if we might see a CUDA55 app if there is any benefit over the current beta app.
I was also curious about why CUDA55 as opposed to more recent CUDA versions. Perhaps there is just nothing in CUDA 6+ that E@H can take advantage of?
Again, I apologize for this being a bit off-topic.
Below are the results I have
)
Below are the results I have seen with the beta CUDA 5.5 Linux application in a format similar to what was used in the BRP6 RESULTS ONLY thread in the Cruncher's Corner message board.
[pre]
CPU: Intel 3930K @ 4.0 GHz
Cores/Threads: 6 / 6
Motherboard: ASUS Rampage IV Formula
PCIe slot PCIe 3.0 x16 (3.0 enabled using modprobe nvidia NVreg_EnablePCIeGen3=1)
1st GPU: EVGA 780 Ti SC ACX
2nd GPU: -
3rd GPU: -
RAM: 4 x 4GB DDR3
Concurrency: 2 @ 0.2 CPUs + 0.5 GPUs
CPU Tasks: 4 x FGRP4
Free CPU cores: ~ 2
OS: Linux 3.12.31
Driver: NVIDIA 352.30
BOINC Version: 7.4.42 64bit
Mean Times - secs Elapsed time Stats CPU time Stats
----------------- --------------------- ------------------- Sample
Search Elapsed CPU part Std Devn Variance Std Devn Variance Size Notes / Comments
====== ======= ======== ======== ======== ======== ======== ====== ================
BRP6 3,771 496 178 31,605 20 408 114 v1.54 CUDA 5.5 application, samples validated
[/pre]
====####====
COMMENTS
* Estimated RAC based on average GPU elapsed time and concurrency is ~201,623.
* GPU Fan speed manually set to 80%.
RE: I was also curious
)
I think that's it. And Einstein has historically supported a large user base with a huge variety of systems. Moving to a newer CUDA version would cut some people out who are limited to older drivers for some reason. One could combat this by deploying multiple app versions for different CUDA versions, but this creates more work during building & validation. So it's always a trade-off and the choice has been CUDA 5.5 as a "golden standard" this time. It doesn't exclude too many crunchers but provides a significant gain over CUDA 3.2.
MrS
Scanning for our furry friends since Jan 2002