Topic: Ubuntu Natty Narwhal 11.04 Mining Guide / HOWTO - page 4. (Read 281459 times)

Hi,

I am getting the following error. I tried the suggestion in the forums, but nothing works so far. Any push in the right direction is appreciated

Uninitialised file found, configuring.
PowerXpress error: Cannot stat '/usr/lib/fglrx/switchlibGL': No such file or directory
Failed to initialize libglx for discrete GPU
Using /etc/X11/xorg.conf
Saving back-up to /etc/X11/xorg.conf.fglrx-4



Here is the output of lspci -v
http://pastebin.com/wmwbgDhx

Great guide, used to set up 2 miner with 8 GPU : flawless ! Keep in mind NOT to update when prompted by Ubuntu (I tried, it failed to set up everything right).

Tipped

Thanks Inaba

I rebooted and the same thing happens, only shows the cpu

And did you reboot and does it work now?

ohhh, yeah it says, uninitialised file found, configuring,
using /etc/X11/xorg.conf

aticonfig --initial -f --adapter=all does not display any information about your CPU or GPU so I'm not sure how you'd get that information from that command.  Try doing it again.

Fairy nuff. From a point of view where the machine may be repurposed as a general purpose computer, I agree with you 100%. Your argument works perfectly in all such cases.

And perhaps I should be a little more circumspect about what I'm going to do with these miner hack-boxes once the 'next big thing' (FPGAs, ASICs, perhaps) turns up and I don't need 5 graphics cards racked out on a home-made wooden frame, with some random free old machine providing the 'system controller'.

The thing is that you don't need more than a basic 32-bit install to run a Bitcoin mining rig. If the rig is specialised (no drives, too many GPUs, etc.) then you're going to rebuild it anyway if you return it to 'general computing' use... at which point you'll probably re-install the OS - you can put 64-bit on then.

My point of view is a one-stop easy solution that does everything for a mining setup... it appears to be a bit quicker than most of the 64-bit setups on the same card, but the differences aren't statistically significant.

I will try to find time to try it out though. Same box, same Linux install process, same miner setup process... but the 64-bit ISO of Ubuntu natty instead. I'm downloading it now

When i ran the command cicada posted, it still only displayed my cpu

Did you follow the instructions cicada posted?  It sounds like the drivers are not being initialized in your xorg.conf file.

I'm running 4 gpus, and have a dual monitor setup. Does anybody have any other suggestions to for my problem?


Could it be an OpenCL problem? I have it installed, but it doesn't seem to working.

thanks

If your X server is running, and you've got all your cards initialized ( aticonfig --initial -f --adapter=all as root to fix these if not ), you probably forgot to set DISPLAY=:0

Try:

#>  DISPLAY=:0 poclbm.py

and see if it lists your GPUs.

Have you enabled Overdrive on ALL devices? i.e. (aticonfig --od-enable --adapter=all)

It's easy to forget and leave off the --adapter=all option, which will apply the changes to the default device only...

That said, 500 seems rather low for the default?

does anybody know what my problem is?
I followed all those directions, and when i try to open poclbm.py only my cpu is shown ([0])
i can run the other commands and see the fan rate of all 4 gpu's but can't open them in poclbm.

thanks,
jbanna

The "you" in the above quote was a collective you, not a personal you.  Perhaps I could have been a bit more clear on that front.



It's pretty unlikely that you're going to find a system board that has PCI-e slots that will not run a 64 bit CPU.  It's far more likely you'll find a 32 bit only CPU, and in the case of AMD chips, it's unlikely you'll find even that.  Intel chips it's a little more likely.  64 bit has been around and been the standard in chips since 2000 or so with the introduction of the Athlon 64.  Intel was a couple years behind on that front, but started shipping 64 bit chips in the mid 2000's.  If you're scavaging hardware from earlier than that, it's unlikely to have more than one or possibly two PCI-e slots.  The number of people that absolutely MUST run a 32 bit install is exceptionally small and catering to the lowest common denominator is counter productive and does a disservice to everyone else.


This is an argument that is dragged out and beat to death ad infinitum and has been thoroughly debunked far better than I could do it.  Feel free to Google it.  The bottom line, though, is that the theoretical additional power usage from using 64 bit words to transport 32 bit data is so infinitesimally small as to be virtually immeasurable except by very sophisticated equipment.  For the purposes of the macro world and more specifically for the extreeeeemly high current draw of these machines when mining, the difference would not even show up in a statistical margin of error on all but the most precise measurements.  By all means, if you wish to save a small fraction of a watt per month on your power bill, install the 32 bit version... but you'll use up more power than you save over the life of your equipment downloading either ISO.


I am not aware of a meaningful size difference between any 64 bit or 32 bit install.  If there is in fact a size difference in a given distro, it has everything to do with what's included in the distro and not whether it's 32 bit or 64 bit.  But the root of your question is why do it?  I've already given you several reasons.  Another reason is that what do you do when someone releases a 64 bit miner or other application that you wish to run?  You'll have to reinstall... in the meantime, those with a 64 bit installation can run both 32 bit and 64 applications.


I see your point and I find it to be somewhat lacking for reasons already stated.  If for no other reason than the one I just stated above.  You can do everything that you need to do now and in the future on a 64 bit install; the same can't be said for a 32 bit install.  There is no downside to installing 64 bit, therefore installing a 32 bit OS is artificially limiting for absolutely no reason.


Again, you save more power by underclocking your CPU than you will save over the lifetime of your equipment by installing a 32 bit OS in favor of a 64 bit OS... and if the time comes down the road that you decide to repurpose your machine and need a 64 bit, you'll use up much, much more power than you saved just reinstalling the OS.

Whoa there, had a bad day?

I've been running Linux since 1993. Normally it's a good idea not to claim people are idiots until you know a little more about their experience and technical ability... the 'technophobe' jibe made me laugh... 13 years running a tech company, perhaps you need to realise that bitcoin mining also has a business element - profit is highly dependent on power consumption and only the GPUs matter... I don't want a pissing contest so let's leave the snarks there, eh?

However it's good to learn something every day. I've been using OS X on my GUI boxes since Apple released it, leaving Linux for the servers. And with OS X, the installer builds a 64-bit or 32-bit system automatically depending on what hardware you have. I presumed that the latest download of Ubuntu would do exactly that... I was wrong. Two different ISOs, one for each architecture. Fairy nuff, you've taught me something there, which makes a bunch of my comments meaningless.


BUT... If you're building multiple mining boxes, and are scavenging hardware, then the ONLY real thing that matters is the number of PCIe slots on the logic board, the GPUs you're using, and the quality of your PSU. Hence having ONE system build that works on all is efficient. This is why I recommend the 32-bit platform. Obviously, an old board I picked up for nothing isn't likely to run 64-bit. Otherwise, you need two Ubuntu ISOs and two sets of scripts to build a miner.

Also, power concerns are important. Performance of mining is all in the GPUs - processor and system RAM performance is irrelevant. Hence you get *absolutely zero* gain from using 64-bit code anywhere. My thinking is that the doubling of size of all code in 64-bit implementations could increase power consumption of the bits that *don't matter* - the CPU and system RAM. I presume you have a broad knowledge of CPU microarchitecture, specifically how x86-64 operates when switched into 32-bit mode? If running 32-bit code on a 64-bit CPU required emulation or execution in a separate core (as per the old Itanium) then I'd agree completely with you. But at least with x86-64, this is not the case, and 32-bit code can be run using *less of the CPU die* than in full 64-bit mode. Remember that x86-64 has many more registers, for one - the fewer transistors actually *used* corresponds to a reduction in power consumption by the CPU. I'd like to see some hard stats to validate my theory though... perhaps I'll download the 64-bit Ubuntu and do exactly that...


Look - don't take this personally - I'm saying that bitcoin mining is the sort of job that could be efficiently done on an Atom Netbook if it had enough PCIe slots! The rest of the system doesn't matter. So why increase the size of the OS, the size of the apps, the amount of data moved around, etc. with 64-bit implementations?

I simply stick with the right tool for the job. Unless you're using your miner for something else, there's no need to have anything other than a basic 32-bit build which will work on all boxes you decide to start mining on. Simple as that. I don't consider 'time to move on' or 'keeping up with technology' a valid reason. A mining machine is a dedicated unit where all the work is done on the GPUs. The rest of the system is simply management, control and networking. Can you see my point here?

None of us *want* the CPU, northbridge and integrated peripherals (other than networking...) consuming more power than absolutely necessary. Using a 32-bit implementation reduces the amount of data the OS throws around. I also underclock the CPUs for exactly the same reason. Using a 32-bit build gives a generic 'miner' install that will work on any cheap, old board you throw at it.

If you can't see the validity of this argument, and prefer to sling insults, don't bother replying.

Yup did that, did it again just to make sure, and the clock still won't go above 500.

Huh the clock on the slower card is running at 500, even though I had set it to 800 earlier.  Thanks I feel stupid for not checking that...  Any idea as to why that one would be running slower, I tried to change it to 800 but it stays at 500, I increased the other one to 840 the max aticonfig would let me.

And your clock setting on the cards?  (aticonfig --odgc --adapter=all)

So I'm somewhat confused on your post.  What steps would you remove?

The rest of your post talks about 32bit and 64 bit, but doesn't come to any conclusions.  There are instructions for installing 32 bit and 64 bit flavors of the libraries you need.  If you are not smart enough to figure out that you need 64 bit libraries for 64 bit installs and 32 bit libraries for 32 bit installs it's likely you aren't really destined to run Linux anyway. The Ubuntu installer won't arbitrarily install a 64 bit or a 32 bit install since you need to explicitly download either the 32 bit or 64 bit ISO.


I'm not sure what this has to do with installing Ubuntu.


It will not give a performance boost.  There is absolutely no compelling reason to install the 32 bit version of Ubuntu unless you need to for an explicit reason (a 32 bit cpu or other application that only runs in 32 bit for example).  It's time to move on and sticking with 32 bit is like clinging to Windows 95.  There's no reason for it and it offers absolutely nothing as far as advantages go and you are only limiting yourself going forward. It's backwards thinking to install a 32 bit OS in this day and age.


Why would you even attempt this?

A simple method is to ALWAYS choose a 64 bit install unless there is a compelling, specific reason not to.  Being a Luddite or technophobe is not a compelling reason and only serves to harm not only yourself but also everyone else, since your statistics will be rolled into the statistics at large, making the move to 64 bit take longer than necessary because you are too scared to move on.  Stick with 32 bit if you want to, but don't expect people to support you, your decisions, hardware or software going forward.  You are on your own.

All my miners use Ubuntu 11.04 natty and my setup procedure is less complicated than this - but similar so I won't post another Linux miner build guide as I'd just be whoring for attention Yours is just fine

However it may be helpful to make it damn clear to everyone that the environment variables set, and the headers and libraries passed into pyopencl when you're compiling it, MUST be the correct architecture for the actual OS you've installed.

Many people have 64-bit CPUs but end up installing a 32-bit version of Ubuntu. Obviously, linking to 64-bit libraries when running a 32-bit system will either not work at all, or introduce a performance penalty.

IMO, I've found that using the standard default installation procedure, and then assuming a 32-bit system - hence using 32-bit libraries and environment variables - results in performance that is very satisfactory.

My card performance is in the top quartile of the Mining Comparison Guide for all cards that I've got running (except the 5670, which I put in as a joke, and ended up stable at 103 Mh/s which blows all the other examples out of the water, heh).


In terms of hardware, I've got a core 2 duo (which is a 64-bit CPU), an i3 (again, 64-bit CPU) and some Pentium Dual-Core thing in a 775 socket (no idea, being a Mac bloke and we never used these CPUs in Macs). If the standard Ubuntu 11.04 natty install actually installed me a 64-bit Linux... then using the 32-bit libraries and headers may give a small performance boost. Less data needs to be shifted around, though since the VAST majority of the work is done inside the GPU cores, where the word length is fixed and the kernel the same regardless of your OS, perhaps OS bit-ness is a red herring.

Regardless, running 64-bit on 32-bit systems sounds problematic. Since the 32-bit instructions work on all my machines, and my machines may even be 64-bit... a simple method is ALWAYS to choose the 32-bit libraries. They work.