After moving all this stuff into place, I ran ldd on clinfo to see what libs that app would be needing.
You need to keep an eye on which clinfo you are running.
iirc there will be distro supplied (old) version and a more up to date (in the AMD sense) from AMD. You prolly want to be running the AMD one, but it is interesting to compare.
The RPM install should fix all the library and other dependencies. I wonder if the PCLinuxOS package maintainers might be asked to maintain their distros to install the drivers correctly. That would have several benefits.
Quote:
So now onto BOINC. When the client starts, at least for V7.2.42 which I'm using, GPU detection depends on the client finding the OpenCL libs as /usr/lib64/libOpenCL.so. With the old fglrx driver, PCLOS installs everything under /usr/lib/fglrx-current/. I've always needed to add a symbolic link in /usr/lib64 pointing to fglrx-current/libOpenCL.so. I presumed I would need to do a similar thing for the new OpenCL stuff in /opt/amdgpu-pro/lib64. The contents of the .icd file that I'd installed in /etc above pointed to the OpenCL lib being libamdocl64.so so I just created the link libOpenCL.so -> libamdocl64.so.
All that hassle has been solved since BOINC 7.6.31 and even Ubuntu dishes that out from its (usually out of date) repos out at 16.04 LTS for nearly a year i think. 7.2.42 is nearly 3 years old, any reason for using it with a new build?
Anyways interesting to see how the results play out, the 460 for the money is quite a bang for the buck. Be interesting to see what Vega will do when it arrives (soon)
You need to keep an eye on which clinfo you are running.
I did check :-). Running which clinfo only returns /opt/amdgpu-pro/bin/clinfo.
AgentB wrote:
I wonder if the PCLinuxOS package maintainers might be asked to maintain their distros to install the drivers correctly. That would have several benefits.
Yes, I know. The guy who originally forked PCLinuxOS from Mandrake (Mandriva), many years ago, still does an incredible job of maintaining and advancing things, despite personal hardships. He has a small, dedicated group of helpers who always seem to have a lot on the go. At the moment, they are attempting to transition from KDE4 to KDE5 (or whatever its proper title is). Until the dust settles, I'd much rather not request stuff that I get the feeling would be regarded as 'currently unimportant', particularly when I can work around the issues on my own.
AgentB wrote:
All that hassle has been solved since BOINC 7.6.31 and even Ubuntu dishes that out from it's (usually out of date) repos out at 16.04 LTS for nearly a year i think. 7.2.42 is nearly 3 years old, any reason for using it with a new build?
What particular hassle are you referring to - does 7.6.31 detect opencl capability differently? I don't regard creating a symbolic link as any sort of hassle. There is no BOINC stuff, period, in the PCLOS repo. Perhaps 7 years ago there used to be, but it was removed because (I suspect) of a perception of overly frequent and alpha quality updates at the time. I had never used a repo version anyway - I just downloaded what I wanted from Berkeley, so it wasn't an issue for me.
I use 7.2.42 because it's the last 'available from Berkeley' version and it works OK for me. Before the power failure, I had around 90 machines all running this version. I don't know where to find a later version that I'd be completely sure I could trust. I'm always reluctant to 'fix non-existent problems' and for me I don't have any particular issue I know about that could be fixed with a version change. It's a big deal to change the version on 90 machines if I don't need to :-). Sticking a graphics card in in an already setup machine is hardly a new build :-).
AgentB wrote:
Anyways interesting to see how the results play out, the 460 for the money is quite a bang for the buck. Be interesting to see what Vega will do when it arrives (soon)
As luck would have it, I bought some of these in the first batch (~$USD120) as they were the cheapest at the time. They have a 6-pin power socket and a dual molex to 6-pin cable is supplied. My standard PSU is a 300W SeaSonic that does 270W @ 12V so I'm using one of those and the adapter cable to power the system.
The full list of hardware that draws power includes:-
Gigabyte GA-G31M-S2L motherboard.
Intel Q6600 CPU 2.4GHz.
2x2GB Kingston DDR2 800MHz RAM modules.
Seagate U6 series ST320410A 20GB IDE drive.
XFX RX 460 OC 2GB running at the 'as supplied' clocks.
I have made the wall power measurements as listed below. The PSU is a SeaSonic OEM unit and is about 10 years old. I've recently replaced swollen caps and re-oiled the fan. It's working well at the moment. As new, it was at least 80% efficient, probably around 82-83% at the 50% load point. I'm ordering some new 80+ gold rated units from SeaSonic just to have decent kit available for tests like these.
I'm using an el-cheapo killawatt style meter that plugs into a wall socket. I'm going to source something better shortly. It displays a reading every second which is fine if there is little variation in the power draw. With these FGRPB1G tasks there is tremendous short term fluctuation. The meter I'm using can't integrate over time to get a decent average so I've just recorded the limits of the observed swings.
I'll give 3 values, (i) the full observed range, (ii) a tighter range where the bulk of the values seem to fall, and (iii) a guesstimate of the probable mean of this tighter range. The observations were performed over a period of at least 2 mins each and were timed to avoid the higher fluctuations of task startup and task finishing events. Not very satisfactory, I know, but the best I can think of at the moment :-).
Details of the stage when power draw was measuredFull RangeMost Common RangeBest Guess Average
1. Machine running at idle - no user activity 71w 71w 71w
Before doing these measurements, the machine was running at the #3 stage. I had even considered running no CPU tasks at all. The above measurements tell me that's what I should do :-).
I bought 4 of the above model and all 4 are now running in systems. Yesterday, I saw an Asus RX 460 OC 2GB 'Dual' advertised locally for less than $USD100 equivalent. It has dual fans and doesn't require an external power connector. I couldn't resist so I bought another 4. Looks like a few more hosts coming out of retirement after all :-). I've already installed one with no issues and it's doing pretty much identical times to those in the above first batch. It's in a different motherboard (Asus P5KPL-AM/PS) with an E6500 Pentium dual core CPU - 2008 vintage. The host is also running a single CPU task. At some point I'll check the power draw. The board for this Asus GPU actually has a set of pads ready for a 6-pin socket. I hope that doesn't mean the device really should have some external power but someone decided to save a few cents by not installing the socket.
AgentB: I'm not sure where you wanted to link to but it was not working. I fixed it by linking to the BOINC dev forum. Please check if this was the intended target.
You shamed me into considering that it was probably about time to do something about upgrading to a more recent BOINC version. So yesterday, I did quickly browse the link you gave but didn't see any particular reference to OpenCL detection so immediately moved on to searches for instructions on how to build the BOINC client stuff locally. Armed with the available information, I picked a recently 'OS upgraded' machine with an RX 460 and installed git on it and cloned the BOINC source code. Initially I had no idea of what I was doing (I'm familiar with shell scripting but not 'proper' programming languages - and what the heck is this git stuff anyway :-). ) but I thought I'd see if I could muddle through it all. I have a fully updated mirror copy of the pclos repos so adding anything needed was quite a trivial exercise - once I realised I needed it (and what it was actually called) :-).
To cut a long story short, by last night I had a build that ran to completion and produced an output directory with all the 7.6.33 stuff complete with a shell archive of the entire package - just like I used to download from Berkeley. It was getting late so I decided not to try to run it until today. I ended up having to add zillions of -devel packages to the build machine in order to get configure not to complain about missing stuff.
The biggest bugbear was when there was a complaint that a certain lib was missing when synaptic clearly showed it as being installed. A classic example was libnotify. It took me quite a while to work out that it was actually complaining about the -devel package. So then I discovered there was no libnotify-devel showing in synaptic - what a bummer. So I started searching for an rpm on the internet only to find plenty for other distros and even one for pclos. Its name was lib64notify-devel and I'd been searching for libnotify-devel. Wasted a lot of time on that one :-).
So this morning, after a good night's sleep, I decided to test out my home grown 7.6.33 on a different machine, but still one with an RX 460. In case of complete disaster, I stopped the old client and cloned the entire BOINC tree on the test machine, before replacing the executables with the latest versions. I took the precaution of running each of these through ldd to make sure there were no missing libs. I also disconnected from the internet so if all went pear shaped, I could restore the old version as it was. Everything started up and continued just fine. Bit of an anti-climax really :-).
The new version has been running for a few hours now and there are quite a few validated tasks. After a quick inspection, there are no problems to show but the crunch time seems to be about 20-30s longer for some unknown reason (2220-2230s instead of 2190-2210s). Maybe it's just natural variation but it seems quite consistent.
So now I guess I need to play around with the 7.6.33 GUI and get the various menu changes/options figured out. I do have a possible use for the event log options. In my control script, I need to break up the sending of new tasks into how many were CPU tasks and how many were GPU tasks. Maybe I'll find something of use in the various tick box items controlling what goes in the event log. At the moment if there is a request for both CPU and GPU tasks, there doesn't seem to be an easy way to accurately split the total received into the two different categories.
Gary Roberts wrote:After
)
You need to keep an eye on which clinfo you are running.
iirc there will be distro supplied (old) version and a more up to date (in the AMD sense) from AMD. You prolly want to be running the AMD one, but it is interesting to compare.
The RPM install should fix all the library and other dependencies. I wonder if the PCLinuxOS package maintainers might be asked to maintain their distros to install the drivers correctly. That would have several benefits.
All that hassle has been solved since BOINC 7.6.31 and even Ubuntu dishes that out from its (usually out of date) repos out at 16.04 LTS for nearly a year i think. 7.2.42 is nearly 3 years old, any reason for using it with a new build?
Anyways interesting to see how the results play out, the 460 for the money is quite a bang for the buck. Be interesting to see what Vega will do when it arrives (soon)
AgentB wrote:You need to keep
)
I did check :-). Running which clinfo only returns /opt/amdgpu-pro/bin/clinfo.
Yes, I know. The guy who originally forked PCLinuxOS from Mandrake (Mandriva), many years ago, still does an incredible job of maintaining and advancing things, despite personal hardships. He has a small, dedicated group of helpers who always seem to have a lot on the go. At the moment, they are attempting to transition from KDE4 to KDE5 (or whatever its proper title is). Until the dust settles, I'd much rather not request stuff that I get the feeling would be regarded as 'currently unimportant', particularly when I can work around the issues on my own.
What particular hassle are you referring to - does 7.6.31 detect opencl capability differently? I don't regard creating a symbolic link as any sort of hassle. There is no BOINC stuff, period, in the PCLOS repo. Perhaps 7 years ago there used to be, but it was removed because (I suspect) of a perception of overly frequent and alpha quality updates at the time. I had never used a repo version anyway - I just downloaded what I wanted from Berkeley, so it wasn't an issue for me.
I use 7.2.42 because it's the last 'available from Berkeley' version and it works OK for me. Before the power failure, I had around 90 machines all running this version. I don't know where to find a later version that I'd be completely sure I could trust. I'm always reluctant to 'fix non-existent problems' and for me I don't have any particular issue I know about that could be fixed with a version change. It's a big deal to change the version on 90 machines if I don't need to :-). Sticking a graphics card in in an already setup machine is hardly a new build :-).
As luck would have it, I bought some of these in the first batch (~$USD120) as they were the cheapest at the time. They have a 6-pin power socket and a dual molex to 6-pin cable is supplied. My standard PSU is a 300W SeaSonic that does 270W @ 12V so I'm using one of those and the adapter cable to power the system.
The full list of hardware that draws power includes:-
I have made the wall power measurements as listed below. The PSU is a SeaSonic OEM unit and is about 10 years old. I've recently replaced swollen caps and re-oiled the fan. It's working well at the moment. As new, it was at least 80% efficient, probably around 82-83% at the 50% load point. I'm ordering some new 80+ gold rated units from SeaSonic just to have decent kit available for tests like these.
I'm using an el-cheapo killawatt style meter that plugs into a wall socket. I'm going to source something better shortly. It displays a reading every second which is fine if there is little variation in the power draw. With these FGRPB1G tasks there is tremendous short term fluctuation. The meter I'm using can't integrate over time to get a decent average so I've just recorded the limits of the observed swings.
I'll give 3 values, (i) the full observed range, (ii) a tighter range where the bulk of the values seem to fall, and (iii) a guesstimate of the probable mean of this tighter range. The observations were performed over a period of at least 2 mins each and were timed to avoid the higher fluctuations of task startup and task finishing events. Not very satisfactory, I know, but the best I can think of at the moment :-).
Details of the stage when power draw was measured Full Range Most Common Range Best Guess Average
1. Machine running at idle - no user activity 71w 71w 71w
2. BOINC running with 2GPU + 0CPU task mix 120 - 144w 138 - 142w ~140w
3. BOINC running with 2GPU + 1CPU task mix 126 - 171w 147 - 168w ~160w
4. BOINC running with 2GPU + 2CPU task mix 127 - 185w 160 - 177w ~170w
5. BOINC running with 2GPU + 3CPU task mix 154 - 190w 170 - 180w ~175w
Before doing these measurements, the machine was running at the #3 stage. I had even considered running no CPU tasks at all. The above measurements tell me that's what I should do :-).
I bought 4 of the above model and all 4 are now running in systems. Yesterday, I saw an Asus RX 460 OC 2GB 'Dual' advertised locally for less than $USD100 equivalent. It has dual fans and doesn't require an external power connector. I couldn't resist so I bought another 4. Looks like a few more hosts coming out of retirement after all :-). I've already installed one with no issues and it's doing pretty much identical times to those in the above first batch. It's in a different motherboard (Asus P5KPL-AM/PS) with an E6500 Pentium dual core CPU - 2008 vintage. The host is also running a single CPU task. At some point I'll check the power draw. The board for this Asus GPU actually has a set of pads ready for a 6-pin socket. I hope that doesn't mean the device really should have some external power but someone decided to save a few cents by not installing the socket.
Cheers,
Gary.
Gary Roberts wrote:What
)
Yes in the sense that it works as designed see Release Notes for BOINC 7.6
Thanks for the power figures, i was thinking about starting a GPU Model / Power at wall / Performance thread now that the new app is out of beta.
AgentB: I'm not sure where
)
AgentB: I'm not sure where you wanted to link to but it was not working. I fixed it by linking to the BOINC dev forum. Please check if this was the intended target.
Christian Beer wrote:Please
)
Thank you Christian, it was exactly that, or this https://boinc.berkeley.edu/wiki/Release_Notes_for_BOINC_7.6
AgentB wrote:Gary Roberts
)
You shamed me into considering that it was probably about time to do something about upgrading to a more recent BOINC version. So yesterday, I did quickly browse the link you gave but didn't see any particular reference to OpenCL detection so immediately moved on to searches for instructions on how to build the BOINC client stuff locally. Armed with the available information, I picked a recently 'OS upgraded' machine with an RX 460 and installed git on it and cloned the BOINC source code. Initially I had no idea of what I was doing (I'm familiar with shell scripting but not 'proper' programming languages - and what the heck is this git stuff anyway :-). ) but I thought I'd see if I could muddle through it all. I have a fully updated mirror copy of the pclos repos so adding anything needed was quite a trivial exercise - once I realised I needed it (and what it was actually called) :-).
To cut a long story short, by last night I had a build that ran to completion and produced an output directory with all the 7.6.33 stuff complete with a shell archive of the entire package - just like I used to download from Berkeley. It was getting late so I decided not to try to run it until today. I ended up having to add zillions of -devel packages to the build machine in order to get configure not to complain about missing stuff.
The biggest bugbear was when there was a complaint that a certain lib was missing when synaptic clearly showed it as being installed. A classic example was libnotify. It took me quite a while to work out that it was actually complaining about the -devel package. So then I discovered there was no libnotify-devel showing in synaptic - what a bummer. So I started searching for an rpm on the internet only to find plenty for other distros and even one for pclos. Its name was lib64notify-devel and I'd been searching for libnotify-devel. Wasted a lot of time on that one :-).
So this morning, after a good night's sleep, I decided to test out my home grown 7.6.33 on a different machine, but still one with an RX 460. In case of complete disaster, I stopped the old client and cloned the entire BOINC tree on the test machine, before replacing the executables with the latest versions. I took the precaution of running each of these through ldd to make sure there were no missing libs. I also disconnected from the internet so if all went pear shaped, I could restore the old version as it was. Everything started up and continued just fine. Bit of an anti-climax really :-).
The new version has been running for a few hours now and there are quite a few validated tasks. After a quick inspection, there are no problems to show but the crunch time seems to be about 20-30s longer for some unknown reason (2220-2230s instead of 2190-2210s). Maybe it's just natural variation but it seems quite consistent.
So now I guess I need to play around with the 7.6.33 GUI and get the various menu changes/options figured out. I do have a possible use for the event log options. In my control script, I need to break up the sending of new tasks into how many were CPU tasks and how many were GPU tasks. Maybe I'll find something of use in the various tick box items controlling what goes in the event log. At the moment if there is a request for both CPU and GPU tasks, there doesn't seem to be an easy way to accurately split the total received into the two different categories.
Cheers,
Gary.