It's amazing what you find when searching for something else!
24 Dec 2017 5:01:06 UTC
Topic 212142
(moderation:
I have a large number of AMD 'Southern Islands' (specifically Pitcairn) series GPUs. These include older HD7850 and newer R7 370 variants. There are a number of different 'brands' - MSI, Gigabyte, Sapphire, Powercolor. Under Linux, the simplest option for me has been to stay with the now obsolete fglrx proprietary driver since these cards are not yet catered for by what has replaced fglrx. Apart from one 'issue' this really hasn't bothered me as I just maintain a rather old installation (2014) without updating, so that it remains compatible with fglrx.
Periodically, I will spend time googling around for any signs that there will be viable support under the new 'amdgpu' driver model. I was running such a search about a week ago using the search term "amdgpu southern islands opencl support" and up popped this link with the rather intriguing title, "Gain massive GPU performance for Southern Islands AMD GPUs on Linux by removing DPM quirks in the kernel".
The 'issue' I mentioned in the first paragraph was that the particular Gigabyte model of R7 370 that I was using, performed quite a bit worse than all the other brands/models of Pitcairn series GPUs. No matter what host they were installed in, they were about 15-20% slower than any of the other cards in that series. On paper, they should all perform about the same and I could find no obvious reason for the discrepancy.
So when I saw that title and then read the article (several times) I immediately wondered if that was the cause of my slow Gigabyte cards. My first thought was to download kernel source and start looking for the tweaks documented in the article. I've never needed to rebuild kernels before so I wondered if I might be lucky enough to find a more recent (already built) kernel where the 'restrictions' causing the slowdown had already been removed.
I keep a full local copy of my distro's repository and I've been in the habit of cloning it every six months for the purpose of acting like a 'wayback machine'. As luck would have it, I have clone copies every May and December from 2013 onwards. The version I've been using for all Pitcairn hosts is 27 May 2014. I was able to find that fglrx was still present in the repos up to May 2016 but was gone by December 2016. So I decided to see what would happen if I upgraded one on the 'Gigabyte' hosts from May 2014 to May 2016. One of the things I like about PCLinuxOS is that it is a 'rolling release' and you should be able to just update to whatever point you want and get exactly the same as you would by doing a new install from a brand new .iso as of that later date.
I have 9 of these Gigabyte cards in 8 machines and all have now been updated to May 2016. Even though the hardware covers quite a range, all of the machines were updated without problems. Part of the update was a newer version of the fglrx driver. Also, the kernel went from 3.12.16 to 4.4.11. I noted that 4.4.x are LTS kernels (long term support) and I wondered if later versions in that series might be more likely to have the GPU performance fixes incorporated. In the December 2016 clone, the kernel was up to 4.4.27 so I decided to upgrade to that particular kernel.
To cut a long story short, all of the Gigabyte cards have much improved performance, so much so that instead of being 15-20% behind, they look like being a few % 'in front'. I wondered if the final version of fglrx might have been responsible for that. Out of curiosity, I decided to try the exact same upgrade on one of the MSI HD7850s that had always performed quite well with the 2014 setup. It is now showing around a 4% improvement as well so I guess I'll be upgrading a bunch of other machines as well :-). Just as well I like 'fiddling' :-).
Cheers,
Gary.
So if someone were go looking
)
So if someone were go looking for the version you are using what would be the name and version number of it? I know it's PCLinuxOS but don't readily see a Dec 2016 release but can always Google it if I have a name or version number.
mikey wrote:So if someone
)
The beauty of the rolling release model that PCLOS uses is that you can install any version you have available and then bring it right up-to-date automatically with a few clicks in the GUI synaptic package manager. However, that's not what I'm doing. My specific requirement is to maintain the now (for quite a while) deprecated proprietary fglrx driver because there is no suitable (for me) alternative that gives me the same performance on my Pitcairn series GPUs.
I have started with an iso released in April 2014 and updated just to 27 May 2014. I have stayed there because it works with the performance I expected, apart from the more recent purchases of Gigabyte R7 370 cards which suffer a 15-20% performance reduction from what existed at that particular time. I've now discovered that I can get full performance from those Gigabyte cards by doing the upgrade to a later date that I mentioned.
To be very clear about what was responsible for the original Gigabyte problem, it was that older kernels had code that reduced both core clock and memory clock for cards with specific identities. My model just happened to be one of those. I had two options to fix the problem. I could have downloaded the kernel source and looked for the lines of code as documented in the linked article about the problem. With the offending lines commented out, I could have rebuilt the kernel. I'd never done that before so I wondered if there might be a way without a new learning curve :-). My instinct said that people much smarter than me would have spotted this problem a long time ago and would have fixed it already in later kernel versions. It was well worth a try to see if that had already happened and as it turns out, my instinct was correct.
Unless you want to run Linux/fglrx on a specific brand/model of AMD Southern Islands GPU, the specific base iso and update point I happen to be using is not something you need to concern yourself about.
If you want to try PCLOS, I'd be very willing to help but you'd need to tell me exactly what hardware you'd be using so I could tell you what would work the best. Chances are, it would just be the latest version with the particular DE that suits you best - readily available in many places. That way you can 'install once and update forever' to always have the very latest version.
Because I have around 90 disparate machines, I don't trust that the 'latest and greatest' will always be the best for my purposes. It would be far too onerous to update every machine on a regular basis. I keep a local mirror copy of the official repository. I update that with an automatic script about every 2 weeks. In May and December each year, I clone the repo using a name that has the date attached. Without this sort of infrastructure in place, you can't easily duplicate what I described in the previous message.
There probably wasn't an iso released in December 2016 (although there could have been - I don't know). As I mentioned, the original base iso I used was released in April 2014. If you have the updates to get to where you want to end up, you can start wherever you like. The official repo and its mirrors will always update you to 'right now'. If you want the ability to update to some earlier time, and you want to do it automatically, you need the infrastructure I've been describing. It is possible (although very tedious) to do it manually if the number of packages involved is relatively small.
There is a site that seems to maintain just about everything (including all versions of RPM packages) that's ever been released. The link I've given is basically the starting point at the top of the tree. Under the live-cd directory, you'll be able to find all isos that have ever been released. Under the apt/pclinux/64bit branch, you'll be able to find all previous versions of RPM packages. I actually found this site while researching my answer to your question. I browsed the RPM packages with fglrx as part of their name and found 57 different versions covering a wide time range. This has probably been of much more use to me than it has to you - for which I thank you :-).
If you tell me what you really want to do and what you want to do it with, I'm willing to try to help you get there.
Cheers,
Gary.
I just had a look at one of
)
I just had a look at one of the machines that has been using the Gigabyte R7 370 GPUs. It has an i5 3570K processor and dual GPUs. I have a virtually identical machine that has older dual HD7850 GPUs that has previously been killing it performance wise. The 7850s produced a RAC of around 520K compared to around 440-450K for the Gigabyte cards.
Here is a screenshot of what those Gigabytes are now doing as a result of the kernel/fglrx upgrade. It's pretty obvious just when that upgrade occurred. To say this is very pleasing is quite an understatement :-).
-
Cheers,
Gary.
Gary Roberts wrote:mikey
)
WOW!! That's alot of info...THANK YOU VERY MUCH!!!
I'm currently downloading a July 2016 version as I too have some of the same gpu's you have except mine are now mostly the 7970 models as I have given alot of my older models to fellow teammates of mine, I just sent two 5870's before Christmas to a guy. I DO still have some more though and it would be nice to see them running again, even if just see that they still work.
One of my problems is that the new bios's don't see the older cards but Linux does but with Linux deprecating the ability to use them built in I'm having problems. I've tried several 'how to's' but not being a Linux guy has hampered my ability to figure things out so far. Since you said PCLinux still has it in there I thought I would give it a try and see how it works. I know the older Ubuntu versions do too, and I have those but hey I'm a computer guy and like 'playing' with my pc's.
Another problem I have is that some of my older pc's don't readily support Win10 and as it moves forward I will be forced to put another OS on them to keep them crunching. They were used in a business before I got them cheap, off of Ebay, but they do cpu units like crazy with their dual quad core Xeon cpu's in them that have Hyper-Threading built into them. I get them for under $200 delivered and all they need is a hard drive, OS and a gpu and they are up and running in no time. I have often started with a non crunching gpu and then upgraded later, right now they all have 750Ti's in them, but I'm going to try a 760 in the next few days. The power supplies are HUGE at over 800 watts so that's not a problem.
Let me try and see what happens and after the New Year I will get back to you with my progress, it won't be RIGHT after the New Year as my calendar is filling up fast so my 'playing' days are being limited. Getting old means more appts for everything and they all take time, so even though I'm retired my free time is often split into a few hours at a time during the day. I like to give myself a day to 'play' when I do a new OS to get it setup, otherwise I miss too many things like forgetting to set the screen saver to never and the pc to not ask for a password on boot-up etc. Everything needs time to run and crunch so I can see that it uses the screensaver or whatever. I've tried lists and they get too long and messy to read as they get changed as the programs I like change over time.
Again thank you VERY MUCH as you ave given me a great starting point to begin my PCLinux adventure.
mikey
You're most welcome! Just a
)
You're most welcome!
Just a few words of caution - don't be in a hurry and please, please ask if you're not 100% certain about something.
I do have a couple of Tahiti GPUs and they need exactly the same fglrx setup as the Pitcairns. I'm pretty sure 5870s would be the same although I've never owned any 5xxx or 6xxx GPUs.
The July 2016 iso you mention would probably be named 'pclinuxos64-mate-2016.07.iso', correct? I know that fglrx was removed from the repo between May and October that year so there's a risk that it may not be suitable for installing fglrx. The main reason fglrx was completely removed (apart from being unsupported in the future) was to allow xorg to be updated from 1.17.x to 1.18.x. fglrx is completely incompatibe with anything above 1.17 so if 1.18 is in the July iso you wont be able to use it for crunching. There was a March iso called 'pclinuxos64-kde-2016.03.iso' (or a May Mate iso if you prefer) that should be safer to use.
Whilst the DE itself is not important, the standard tools that come with particular DEs are. One of the reasons I stay exclusively with KDE is the wide range of KDE specific GUI tools that you get. The two most important tools (for me) are a file manager and a text editor. With KDE those are 'dolphin' and 'kwrite' which are very easy to get comfortable with and loaded with useful features to make life easy. Because I grew up using Unix back in the 70s, I also use 'vi' quite a lot for system config files where I just want to quickly tweak a parameter or two. If you've never come across 'vi' (or 'vim') before, you really don't want to know about it :-). It was a first class tool back in the 70s and I still love the much more modern equivalent. But it's still definitely not WYSIWYG :-).
If you really want to use Mate as a DE because you're already comfortable with its look and feel and with the editor and file manager that come with Mate, that's entirely up to you. I've never looked at Mate so don't know the particular tools available. With either a KDE or Mate iso of that vintage, it will most likely NOT come with fglrx pre-installed. Because of AMD's reputation for lateness in providing drivers that work properly, the PCLOS Devs adopt the attitude that they will always include the current nvidia stuff and let the users access proprietary AMD stuff (ie fglrx) when available through the repo. Sometimes there has been a suitable version, sometimes not. This has never been a problem for me as I had a standard old version that worked fine. Now that I've found where to get all the fglrx versions, it shouldn't be too much of a problem for you either.
If you install any version of the OS at all, you will see advice to update immediately. PLEASE DON'T!!!! If you do, your updated system WILL be incompatible with fglrx and you will have to reinstall. You should be able to use Windows tools to burn the iso to either optical media or a USB drive/stick. Once you boot to a live session, if the boot medium is optical, I would strongly suggest making a bootable live usb. I would suggest a 16GB pen drive to give you lots of space for other stuff. A fast booting live medium is an indispensable tool. I'll find a suitable guide on how best to do this if you need help. There are lots of them around but they do vary in quality. PCLOS has its own very nice tool for making multi-version live USBs and for adding new versions to it whenever you want. However you need an installed system to use that tool and it's specific to PCLOS.
When you get time in the new year, let me know the basic details of what you will be running on, disk-wise. An older, smaller disk (20G - 200G) would be more than suited to the job. I would suggest that you not try to run other systems (particularly Windows) on the same drive. Even though the installer can handle partitioning, I like to pre-partition, pre-label, do a full read/write check for bad blocks, and set up ext4 filesystems on the partitions to be used for PCLOS. I've always found grub legacy using dos/mbr partitioning to be very suited to a small, older disk in a pure crunching box. These days grub2 is default for PCLOS but older isos will default to grub legacy. I'm going to stay with what works extremely well for me for as long as possible. I have yet to even start experimenting with grub2 and UEFI issues.
As an example of why I choose to stay with what I know works well, a small story. When I was updating one of the 8 hosts that had Gigabyte R7 370 GPUs, I had done the ~800 packages upgrade from 14-05-26 to 16-05-27 on a particular machine and was in the process of rebooting to get all the new libs in place for the last stage - the kernel upgrade. During the reboot, the machine kept crashing with a black screen while trying to start X. I repeated attempting to boot with exactly the same results each time. Using a bit of logic (the upgrade process itself always worked) I guessed that something must be corrupt on the disk - maybe a bad block.
I have a 1TB live USB with about 8 different PCLOS versions available so I booted one of those. I used rsync from the live environment to make a clone copy of the system partition on the suspected problem hard drive, onto space available on the live USB drive. During the process, rsync very kindly told me the precise file that it couldn't copy because it couldn't read that particular disk sector. So I grabbed one of my stockpile of pre-prepared old drives, hooked it up as well and then used rsync from the live environment to image both the root partition and the home partition from the failing hard drive onto the replacement drive with just that one file missing. I copied that file from another already upgraded system and put it on the replacement drive.
At that point, I just needed to do three things. I needed to put a boot loader on the replacement disk - trivial to do with grub legacy. I needed to edit the grub configuration file '/boot/grub/menu.lst' to inform the bootloader that the partition IDs were different for the new disk. It's just a matter of replacing the old 36 char UUID strings with the new values for both the root and swap partitions. The third thing was to do a similar set of changes in /etc/fstab so that the new partitions could be found and mounted during the boot process.
Needless to say, with fingers crossed and with some trepidation, I tried to boot the replacement disk. It booted up just as expected and I finished the upgrade by installing the new kernel and putting the machine back to crunching. There's no way I could have got out of that jam so easily with the much more complicated grub2 arrangements.
Cheers,
Gary.
Gary Roberts wrote:You're
)
No I got the KDE one, but will go back and get an older one so I don't have to install twice, THANKS!!
I use dvd's as I bought a few hundred for another use back in the day and they are just taking up space, I have an external dvd writer that spins faster than it can load, even when I use an SSD drive, so it works for me.
I have several 120gb ssd extra drives since Win10 is a hog and is outgrowing them.
WOW that's cool, I'm not anywhere near that level of even knowing what to do to fix that, let alone try it! I would have just reloaded and moved on, your fix was probably ALOT faster!!!
Okay I got the May2016 one
)
Okay I got the Mate May2016 one installed, it's VERY quick as an install on a 120GB SSD drive. It FOUND my 7970 gpu with no problems...WOO HOO!!! But in the Synaptic package manager there is no Boinc, I'm guessing it's the sites that don't have it. I downloaded it as an *.sh file but forgot how to install it, I have it written down but the football game came on so am back to using an Nvidia 1060 under Ubuntu for right now in the machine.
My main question is does PClinux-OS auto update and if so how do I stop it? It found a TON of updates but I didn't click anything as I didn't want it to update me to where I would have to reload it again.
A second question, minor one, is how do I set it to auto login after a restart? I'm only asking because I'm here and haven't checked the net yet.
Thanks for all your help so far, it's much easier to use as a Windows guy then I thought it would be, I've dabbled in Linux before but never got to the point of being comfortable with it.
mikey
mikey wrote:Okay I got the
)
Good for you -- way to go!!
The PCLOS Dev team is quite small so they avoid things like BOINC where an alternative is available. They used to have it but they dropped it at a time when there were point releases of dubious quality coming out every second day. I never used a packaged version when it was in the repo - the berkeley .sh files are just fine. These files are called 'shell archives'. They are designed to be run by the shell (bash) and will create a directory containing the contents of the archive. Here are my suggestions for an 'easy to use' system for running BOINC.
Some background first. Systems like Ubuntu, etc, design BOINC to live in a special place (/var/lib/boinc) and to be 'owned' by a special user:group which is boinc:boinc. Bollocks to all that!! This is going to be MY crunching box so I want it to be owned by ME!! :-) Solves a lot of permissions issues later on when you want to fiddle with things. I want things to be as simple as possible. I don't want stuff 'hidden' under a special user.
First thing for you to master is your file manager (FM) - I think it's 'caja' or something like that in Mate. Mine is dolphin in KDE. I've never used Mate or caja. When I first launch the FM (dolphin) I open the 'settings' option and tweak a couple of things. I want dual 'side by side' panes in the display so I can easily drag and drop stuff from one directory to another, with both visible. Each pane will have a location bar at the top. I configure it to show the full path in the location bar so I always know exactly where I am. There's also an option to make the path 'editable'. If you're deep in the file system somewhere, editing the path to change location might be easier than clicking up-arrow several times and then navigating down a new branch. I assume caja will have similar functionality. I can't emphasise strongly enough, "explore your file manager and become expert in using it - it will make your life a lot easier".
When you open the FM, both panes should show something like '/home/mikey' - your home directory, assuming you used 'mikey' as your user name. You will see a number of standard directories already created for you. The ones I keep are 'Desktop', 'Downloads', 'Documents' and 'tmp'. You can delete the remainder - they should all be empty anyway. If I download something I automatically choose 'Downloads' as the destination. If I create notes or other text files, guess where they go :-). I create (or rename 'Videos' rather than delete it) a new folder 'BOINC' in my home directory. In the second pane I go into Downloads where the shell archive should be seen if that's where I downloaded it to. If you right click on the shell archive, and select 'properties' at the bottom of the context menu, you get some info about the file. Select 'permissions' tab and make sure you own the file and a box 'is executable' is ticked. You won't be able to extract the contents unless the file is executable. While you are on the 'permissions' tab, play around with the control you get under the 'Advanced permissions' link.
Please realise, what I'm describing above may be dolphin specific to some extent. You may need to adjust if caja is a bit different.
Assuming you have a shell archive that is executable, you just need to open a terminal session (you'll find one under the start button somewhere) and at the prompt that shows up at the top left hand corner of the window, type the following commands after the prompt, which should be something like "[mikey@localhost ~]$"
What you are doing is changing directory to where the shell archive is stored and then executing it. Here are the assumptions. You only have the one file with the long complicated name 'boinc_7.2.42_x86_64-pc-linux-gnu.sh' in your Downloads directory so you will use the shell feature of using the tab key to get the shell to complete the full filename so you don't have to type it all yourself. Even b<tab> would have worked! :-). You need the './' in front of the filename to override a security feature - you are not allowed to execute a random file in some random directory, just by typing its name, in case it is malicious. If you give the full path, it is assumed you know what you are doing :-). The './' means "in the current directory find a file named exactly what comes after the slash and execute it". './' is actually a short cut for '/home/mikey/Downloads/' seeing as you are in the Downloads directory already.
The result of this will be a new sub-dir called BOINC in the downloads directory, if I remember correctly. It's a looooong time since I've actually done this for real :-). This will contain bits you need and bits you don't need. When you get to this stage, let me know :-).
There is no auto updating. You have to decide to update and issue the necessary commands (just clicks really) when you want to do it. You will always see notifications about updates (and lots of them because you are the best part of 2 years behind) but you MUST NOT update. To preserve fglrx, you must stay exactly where you are. You can turn off notifications if they annoy you.
This is not a problem for a crunching box. The good thing is that (usually) when a new iso is made available, it tends to be done at a point when everything is at an equilibrium - no new/experimental stuff that might be buggy.
One of the nice things about PCLOS is the PCC (PCLinuxOS Control Center). There is an icon for it down near the start button. The tooltip is "Configure Your Computer". If you open it (you need to supply the root password) there is a menu along the left hand side. The bottom one is 'boot'. Click it and select "Set up Autologin ..." on the next page. Be careful in here because you are doing things as root ... :-). There are lots of things that are configurable using PCC but you need experience and care or you can do some damage.
I'm really glad you're enjoying the ride so far :-).
Cheers,
Gary.
In anticipation of what might
)
In anticipation of what might be your next steps, here are some suggestions for you to think about. When you get comfortable with running BOINC on Linux, you may decide to do so on more than one machine. It's good to plan for that eventuality right from the outset as well. It's much less of a task for each subsequent machine if you plan ahead.
To run BOINC, you are going to need a couple of packages that normally come from the repo. You won't want the current versions of these. In fact there are no current versions of fglrx. The best would be to use versions that were current as of the date of the ISO, May 2016. You will be able to find these on that archive website ftp.sjtu.edu.cn. You should be able to find all the packages on this page. It's a huge page, lots of different versions of packages so search in your browser and select carefully. (I've taken pity on you and provided links later :-) ).
Before downloading the fglrx stuff, you need to check if any of the packages are already installed - I suspect not. To do that, open the Synaptic package manager. Note there are 5 'convenience' icons across the top - 'Reload', 'Mark All Upgrades', 'Apply', 'Properties' and 'Search'. You never ever ever ever want to touch 'Reload'. If you run that function, you will get the state of the repo as at right now, and you certainly don't want that :-). As freshly installed, synaptic knows exactly what is on your system right now but it has no clue about what has happened since May 2016 and you want to keep it that way. You will be manually installing everything you need and synaptic will know about that too. But that's all you want it to know about.
As you look at the open synaptic main window, note the narrow panel down the left and the two wider panes, one above the other, to the right that occupy most of the space. All these are adjustable in size. Below the left hand panel, there are 4 control buttons, Sections, Status, Search, Custom. If you cycle through those 4, there are different displays in the panel above. Have a play around and get familiar with what they do. If you select Status -> All, you will see everything synaptic knows about, listed in the top right hand pane. If you select Status -> Installed, you will see just the subset that is actually installed. Note the colour coding used (green) to show what is installed. Click the search icon on the top row (right hand end) and a dialog box will open. Put fglrx as the search string and click the down arrow and select 'Name' for where to look. If fglrx is already installed, you will see dark green boxes next to each component name. My guess is you wont find any components installed and certainly not the OpenCL libs.
Below is a list of the packages you will need with links to them as I found them on the website.
Hopefully, that should be the lot - as long as at least the same basic stuff is in the Mate edition as in the KDE version. I'm hopeful that I got everything right with the above links. Just check that all the fglrx packages have the same version, namely 15.201.1151-2pclos2016.x86_64. While getting those links, I noticed there was a rebuild where the version (15.201.1151) is the same but it's now called 3pclos rather than 2pclos. That rebuild came in June 2016 which is why it's not in any of my clone repo copies. It hadn't arrived by 27 May and was gone by the time of the next clone copy. I think you should use the 2pclos build because that's what I'm using and I haven't had any issues with it.
The two WxWidgets packages are needed to run BOINC Manager. Version 2.8 is the correct version for BOINC 7.2.42. If you eventually want to use 7.6.x or later, you will need version 3.0 or above of WxWidgets.
At some point you will need to download the above 6. Create a sub-dir called 'Packages' in 'Downloads' and put them in there for the moment. It's pretty straight forward to apply those packages to your system from there when the time comes. It's an easy manual method and I'll provide proper instructions.
In fact, if you want to make things really easy for yourself for ongoing maintenance, and if you have a spare external USB hard disk of at least 100GB capacity, (or are prepared to buy such a beast), I'll write you some instructions on how to build yourself a swiss army knife bootable repair environment that I find indispensable for all sorts of ongoing chores. I use a 1TB drive (my first one was 160GB years ago) and it houses a number of different installable live systems as well as all the clone copies of the repo and all of the BOINC templates that allow me to setup machines very quickly and avoid all the downloads of apps and data when a machine first starts.
It also allows me to completely change the ID of a machine very quickly. It's something I used recently to get machines back working immediately under a new ID while I tried to work out why they couldn't report completed work or download new work under the old ID. When the issue was fixed, the old ID was restored the tasks in limbo were reported and everything returned to normal.
Cheers,
Gary.
WOW you've given me a couple
)
WOW you've given me a couple of days of stuff to do, it's finally getting up near 50F today after being near the freezing mark for the past several days and I have some outside chores and cleanup to do too. By the end of the week it could be near 70F and that's above normal for me here in southern NC. It also means though my a/c system has to be turned back on again to keep my pc's running cool.
Thank you very much I will get busy on it and get back to you, oh an yes I used the login name mikey. :-)
mikey