[The PSU is/was a CoolerMaster RS-460-PSAR-J3. The motherboard is a GIGABYTE, circa 2009, with an AMD Phenom II X4 CPU, but at the moment the MB model number is covered by the GPU's, which I don't want to take out for the umpteenth time. (I thought I had that model number written down somewhere....). The GPUs are a RX 460 1024SP (OEM pulled new from a HP system) and a RX 570 (used, XFX RS, Black Edition).
Under Win7 that same system configuration was pulling 370W (~340W with both GPUs underclocked), so seeing it pull 400W just before it blew makes me think that the extra draw was a symptom of the PSU giving itself last rites. The resting state draw of the Lubuntu system (no E@H running) was 110W.
Thanks. Umm... that specific CoolerMaster model was obviously strugling with that total load. That would've been the case even if that PSU was brand new.. A review back from 2010... https://www.hardwaresecrets.com/cooler-master-elite-power-460-w-power-supply-review/9/ ... says "Cooler Master Elite Power 460 W is simply an Elite Power 400 W with a new label." and "Another example of false advertisement is the manufacturer listing over current protection (OCP) as a feature available on this power supply: inside the unit the space labeled “OCP control board” is empty."
Load test results on that review showed... at 392.8 W that PSU was still delivering power within ATX12V specifications, but when it was given a little more (419.8W) it jumped out of the accepted noise and ripple tolerances. That was for a brand new PSU in 2010. If yours was almost 10 years old its performance was probably worse already. If you saw there was around 400W load happening then the quality of the output power was most likely quite awful for the whole system (naturally the cards and motherboard have their own power regulators, luckily).
That specific RX 460 and RX 570 combination (with only one 6-pin PCIe connector) could introduce some stress for an old motherboard as theoretically it needs to deliver max 120W through the PCIe slots. This could depend very much on the original quality of the motherboard though.
I think that some load wattage differences between Windows and Linux might be a result of the clock speeds (cpu threads, bus) behaving possibly in a different way under similar loads. But I don't know.... I'm just an amateur guessing if that difference (370 / 400 W) could come purely from that. It could well be that the PSU had internally crawled far from the normal specs and was already self-destructing at that point, like you said.
But anyway, that occasion is gone already and it's nice to hear you are going forward. Positive feelings and I hope that system with some kind of setup will be crunching soon again! Cheers
Gary, Richie, Mikey, and Dan; Thank you much for all the great info. I had picked up an EVGA 430W 80+, but those points y'all raised got me to reconsider, so I'm going trade it for the EVGA 650W 80+ Gold that was sitting on the shelf next to it. (Yes Gary, I went the cheapskate route; good call!)
Between undervolting, underclocking, or power limiting, I hope to get my Linux host running <350W with better E@H task productivity. That now-dead PSU I had always ran hot and loud. I'm really looking forward to a cooler, quieter host, assuming everything is still in working order. Thanks again. Onward!
Ideas are not fixed, nor should they be; we live in model-dependent reality.
I suppose you successfully installed AMD OpenCL on it!
Yes! I installed the AMD Ubuntu drivers easy-peasy by clicking on the install script, then, not sure whether OpenCL had installed (the AMD install notes made me think they hadn't), I used AMD's terminal codes and got AMD OpenCL installed no problem.
Can you tell me where you found that please? I would love to use an AMD gpu sitting on my shelf but haven't figured that out yet.
It doesn't seem to matter the exact GPU model, because the drivers work fine for my RX 460, but you do need to enter some model to get to the driver page.
From the Ubuntu x86 64-bit section you download the Ubuntu 18.04.1 driver tar.gz file (the AMDGPU graphics stack). On that web page the link for installation instructions link is: https://amdgpu-install.readthedocs.io/en/latest/
I didn't read the instructions at first (typical!) and instead just poked around in the unzipped folder and clicked on what turned out to be the installer script (can't remember the exact file name), and off it went.
After that was done, I then read the installation instructions (of course!) and on the "Using the amdgpu-install Script" page saw an option for installing OpenCL. So I did like they said and from within the AMD graphics stack directory used the terminal to:
$ ./amdgpu-install -y --opencl=legacy
When I initially (blindly) double clicked on the amdgpu installer I think I invoked the amdpgu-install script, not the amdgpu-pro-install script. If so, then I must have installed the All-Open stack, which included Mesa OpenGL and Mesa multimedia, but not OpenCL, hence my separate installation of OpenCL. From AMD's instructions, invoking the amdgpu-pro script installs the Pro Stack, which includes Pro OpenGL, Pro OpenCL, and Pro Vulcan (Pro OpenCL supports Vega 10 and later). I guess those are all AMD proprietary drivers? Several web discussions I had read seem to have a dim view of AMDGPU-Pro, so maybe using AMD's All-Open stack is the trick.
After I had my RX 570 running E@H, I installed my RX 460 in that host, but couldn't get it to be recognized by the system; it had no video output and initially the system wouldn't even boot with the display plugged in to the RX 460. So I plugged the display back into the 570 and checked that the 460 was seen by the system using $ clinfo (it was). System-side the 460 seemed healthy, but it wasn't running E@H tasks. That problem was solved when I remembered (duh) to set cc_config.xml for the use_all_gpus option (thanks to someone's old post on E@H discussions to jog my memory!). Both GPUs were then running tasks just fine until my PSU blew up. *sigh*
Like MOUNTKIDD said early on in this thread, everything worked out of the box, well, except for no video output from the second GPU, but that isn't something I'm going to fret over.
Ideas are not fixed, nor should they be; we live in model-dependent reality.
Thanks for the detailed instructions. I don't know anything about AMD but I try to help in the forums on video card issues whether Nvidia and AMD. The missing OpenCL component for both Nvidia and AMD seems to come up all the time. I am bookmarking your post and saving it for future reference for any replies or help I send on to AMD users.
My guide is in the second page of that forum, that guide (or something similar if someone improves it!) should be sticked or something like that.
It is definitely not an obvious thing, especially since if you mess with the installation you can end up replacing the open source AMDGPU drivers wich comes with the kernel and are better for gaming. OpenCL is a separate thing.
My guide is in the second page of that forum, that guide (or something similar if someone improves it!) should be sticked or something like that.
It is definitely not an obvious thing, especially since if you mess with the installation you can end up replacing the open source AMDGPU drivers which comes with the kernel and are better for gaming. OpenCL is a separate thing.
Can you tell me where you found that please? I would love to use an AMD gpu sitting on my shelf but haven't figured that out yet.
I did this from (L)Ubuntu 18.04
Like MOUNTKIDD said early on in this thread, everything worked out of the box, well, except for no video output from the second GPU, but that isn't something I'm going to fret over.
I use the Linux Nvidia application to power limit my RTX 2080 and GTX 1080Ti to 200 watts .... in my overclocking script for those cards. There might be something similar for AMD. I would bet even money that there is over in the crypto mining forums as AMD cards are popular there and I know they limit the power levels for Nvidia cards. So expect they did the same for AMD.
Yes, I've found that the miners like to use something called ohgodatool to set ADM memory and clock voltages, fan speeds, and power limits. I picked up the C files from github, https://github.com/kilo17/OhGodATool, but cannot get it to compile properly, likely due to my ignorance of the basics. I mean it seems to compile, but when I try to run it, I get a "command not found" error. Learning....curve....so....steep....
Ideas are not fixed, nor should they be; we live in model-dependent reality.
If what you just built is called 'ohgodatool' and you are still in the directory where you just built it, then you can easily launch it with the command './ohgodatool'. You got a "command not found" error because the command is in a directory (your build directory, wherever you built it) that is not part of your 'currently allowed set of directories where executables live' AKA 'your path' (as specified by the $PATH environment variable). To see all the directories that make up $PATH, use the command "echo $PATH" (without the quotes) :-).
By putting './' in front of the name, you are (temporarily) adding the current directory (as signified by the dot) to the list of 'allowed' directories that are specified by $PATH. If you end up keeping the app for future use, you could create a 'bin' directory in your home directory and put the app there. /home/<user>/bin may already be part of your $PATH. If not you can easily add it. That way the app could always be found no matter what directory you are in when you decide to launch it.
cecht wrote:[The PSU is/was a
)
Thanks. Umm... that specific CoolerMaster model was obviously strugling with that total load. That would've been the case even if that PSU was brand new.. A review back from 2010... https://www.hardwaresecrets.com/cooler-master-elite-power-460-w-power-supply-review/9/ ... says "Cooler Master Elite Power 460 W is simply an Elite Power 400 W with a new label." and "Another example of false advertisement is the manufacturer listing over current protection (OCP) as a feature available on this power supply: inside the unit the space labeled “OCP control board” is empty."
Load test results on that review showed... at 392.8 W that PSU was still delivering power within ATX12V specifications, but when it was given a little more (419.8W) it jumped out of the accepted noise and ripple tolerances. That was for a brand new PSU in 2010. If yours was almost 10 years old its performance was probably worse already. If you saw there was around 400W load happening then the quality of the output power was most likely quite awful for the whole system (naturally the cards and motherboard have their own power regulators, luckily).
That specific RX 460 and RX 570 combination (with only one 6-pin PCIe connector) could introduce some stress for an old motherboard as theoretically it needs to deliver max 120W through the PCIe slots. This could depend very much on the original quality of the motherboard though.
I think that some load wattage differences between Windows and Linux might be a result of the clock speeds (cpu threads, bus) behaving possibly in a different way under similar loads. But I don't know.... I'm just an amateur guessing if that difference (370 / 400 W) could come purely from that. It could well be that the PSU had internally crawled far from the normal specs and was already self-destructing at that point, like you said.
But anyway, that occasion is gone already and it's nice to hear you are going forward. Positive feelings and I hope that system with some kind of setup will be crunching soon again! Cheers
Gary, Richie, Mikey, and Dan;
)
Gary, Richie, Mikey, and Dan; Thank you much for all the great info. I had picked up an EVGA 430W 80+, but those points y'all raised got me to reconsider, so I'm going trade it for the EVGA 650W 80+ Gold that was sitting on the shelf next to it. (Yes Gary, I went the cheapskate route; good call!)
Between undervolting, underclocking, or power limiting, I hope to get my Linux host running <350W with better E@H task productivity. That now-dead PSU I had always ran hot and loud. I'm really looking forward to a cooler, quieter host, assuming everything is still in working order. Thanks again. Onward!
Ideas are not fixed, nor should they be; we live in model-dependent reality.
cecht wrote:Millenium wrote:I
)
Can you tell me where you found that please? I would love to use an AMD gpu sitting on my shelf but haven't figured that out yet.
MIKEY wrote:Can you tell me
)
I did this from (L)Ubuntu 18.04
From the AMD drivers download page,
https://www.amd.com/en/support
I entered my GPU model (RX 570) and got to here:
https://www.amd.com/en/support/graphics/radeon-500-series/radeon-rx-500-series/radeon-rx-570
It doesn't seem to matter the exact GPU model, because the drivers work fine for my RX 460, but you do need to enter some model to get to the driver page.
From the Ubuntu x86 64-bit section you download the Ubuntu 18.04.1 driver tar.gz file (the AMDGPU graphics stack). On that web page the link for installation instructions link is:
https://amdgpu-install.readthedocs.io/en/latest/
I didn't read the instructions at first (typical!) and instead just poked around in the unzipped folder and clicked on what turned out to be the installer script (can't remember the exact file name), and off it went.
After that was done, I then read the installation instructions (of course!) and on the "Using the amdgpu-install Script" page saw an option for installing OpenCL. So I did like they said and from within the AMD graphics stack directory used the terminal to:
$ ./amdgpu-install -y --opencl=legacy
When I initially (blindly) double clicked on the amdgpu installer I think I invoked the amdpgu-install script, not the amdgpu-pro-install script. If so, then I must have installed the All-Open stack, which included Mesa OpenGL and Mesa multimedia, but not OpenCL, hence my separate installation of OpenCL. From AMD's instructions, invoking the amdgpu-pro script installs the Pro Stack, which includes Pro OpenGL, Pro OpenCL, and Pro Vulcan (Pro OpenCL supports Vega 10 and later). I guess those are all AMD proprietary drivers? Several web discussions I had read seem to have a dim view of AMDGPU-Pro, so maybe using AMD's All-Open stack is the trick.
After I had my RX 570 running E@H, I installed my RX 460 in that host, but couldn't get it to be recognized by the system; it had no video output and initially the system wouldn't even boot with the display plugged in to the RX 460. So I plugged the display back into the 570 and checked that the 460 was seen by the system using $ clinfo (it was). System-side the 460 seemed healthy, but it wasn't running E@H tasks. That problem was solved when I remembered (duh) to set cc_config.xml for the use_all_gpus option (thanks to someone's old post on E@H discussions to jog my memory!). Both GPUs were then running tasks just fine until my PSU blew up. *sigh*
Like MOUNTKIDD said early on in this thread, everything worked out of the box, well, except for no video output from the second GPU, but that isn't something I'm going to fret over.
Ideas are not fixed, nor should they be; we live in model-dependent reality.
Thanks for the detailed
)
Thanks for the detailed instructions. I don't know anything about AMD but I try to help in the forums on video card issues whether Nvidia and AMD. The missing OpenCL component for both Nvidia and AMD seems to come up all the time. I am bookmarking your post and saving it for future reference for any replies or help I send on to AMD users.
Thanks.
My guide is in the second
)
My guide is in the second page of that forum, that guide (or something similar if someone improves it!) should be sticked or something like that.
It is definitely not an obvious thing, especially since if you mess with the installation you can end up replacing the open source AMDGPU drivers wich comes with the kernel and are better for gaming. OpenCL is a separate thing.
https://einsteinathome.org/it-it/content/quick-guide-how-install-opencl-amd-gpus-linux-kubuntu-1804-and-similar-distro
Millenium wrote:My guide is
)
Nice. Yes, that's a good reference source to stick. Looks like I reinvented the wheel and got lucky!
Ideas are not fixed, nor should they be; we live in model-dependent reality.
cecht wrote:MIKEY wrote:Can
)
Thank you very much I will try it today!!
Keith Myers wrote:I use the
)
Yes, I've found that the miners like to use something called ohgodatool to set ADM memory and clock voltages, fan speeds, and power limits. I picked up the C files from github, https://github.com/kilo17/OhGodATool, but cannot get it to compile properly, likely due to my ignorance of the basics. I mean it seems to compile, but when I try to run it, I get a "command not found" error. Learning....curve....so....steep....
Ideas are not fixed, nor should they be; we live in model-dependent reality.
If what you just built is
)
If what you just built is called 'ohgodatool' and you are still in the directory where you just built it, then you can easily launch it with the command './ohgodatool'. You got a "command not found" error because the command is in a directory (your build directory, wherever you built it) that is not part of your 'currently allowed set of directories where executables live' AKA 'your path' (as specified by the $PATH environment variable). To see all the directories that make up $PATH, use the command "echo $PATH" (without the quotes) :-).
By putting './' in front of the name, you are (temporarily) adding the current directory (as signified by the dot) to the list of 'allowed' directories that are specified by $PATH. If you end up keeping the app for future use, you could create a 'bin' directory in your home directory and put the app there. /home/<user>/bin may already be part of your $PATH. If not you can easily add it. That way the app could always be found no matter what directory you are in when you decide to launch it.
Cheers,
Gary.