OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[Internet151]

Just ran into a serious bug with cgminer tonight. I noticed when you only mine at one pool, and it goes down temporarily the miner will open over 4,000 connections (with a TCP timeout of 120 set on my router!) to attempt to reconnect.

Having multiple machines doing this just brought my router to its knees and it couldn't do shit until I unplugged all my rigs and waited for cgminer to close itself, which is another bug that occurs if internet access is temporarily lost.

This happened in Windows 7 SP1 32-bit with cgminer 1.5.1.

[1714489765]

1714489765

[1714489765]

1714489765

[1714489765]

1714489765

[tysat]

I was looking through the code, but I'm a little tired right now and can't figure out if this would be an easy change or not...

I want to set it so that it will do a pool rotation, but start it over at the beginning when a new block is detected via LP.

[dlasher]

I tried cgminer on a couple of my boxes last night and woke up to find 3/4 GPU marked as DEAD on one and 2/4 DEAD on another. Trying to restart the DEAD GPU doesnt seem to do anything on either machine (restarting the ones still running did seem to restart them OK). Both boxes have been running for weeks using poclbm without errors. Running the 1.5.3 binary on Ubuntu (3xHD5870 and HD6310).

Anyone else seeing problems with DEAD GPU that won't recover unless cgminer is restarted?

BB.

Restart dead GPUs does not work for me too. Win7 64bit, Catalyst 11.7

Me too. LinuxCoin beta final

In my testing, under Fedora14, SDK2.4, restart GPU works in 100% of my 5xxx series cards, and 0% of my 6xxx series cards.

[EskimoBob]

I was looking through the code, but I'm a little tired right now and can't figure out if this would be an easy change or not...

I want to set it so that it will do a pool rotation, but start it over at the beginning when a new block is detected via LP.

+1
But this is not that easy. You probably need to add a way to pull in JSON stats from pools and let the miner make decisions based on that information.

[boss cat]

I tried cgminer on a couple of my boxes last night and woke up to find 3/4 GPU marked as DEAD on one and 2/4 DEAD on another. Trying to restart the DEAD GPU doesnt seem to do anything on either machine (restarting the ones still running did seem to restart them OK). Both boxes have been running for weeks using poclbm without errors. Running the 1.5.3 binary on Ubuntu (3xHD5870 and HD6310).

Anyone else seeing problems with DEAD GPU that won't recover unless cgminer is restarted?

BB.

Restart dead GPUs does not work for me too. Win7 64bit, Catalyst 11.7

Me too. LinuxCoin beta final

In my testing, under Fedora14, SDK2.4, restart GPU works in 100% of my 5xxx series cards, and 0% of my 6xxx series cards.

Not for me. It won't restart either gpu on my 5970.

[cirz8]

I tried cgminer on a couple of my boxes last night and woke up to find 3/4 GPU marked as DEAD on one and 2/4 DEAD on another. Trying to restart the DEAD GPU doesnt seem to do anything on either machine (restarting the ones still running did seem to restart them OK). Both boxes have been running for weeks using poclbm without errors. Running the 1.5.3 binary on Ubuntu (3xHD5870 and HD6310).

Anyone else seeing problems with DEAD GPU that won't recover unless cgminer is restarted?

BB.

Restart dead GPUs does not work for me too. Win7 64bit, Catalyst 11.7

Me too. LinuxCoin beta final

In my testing, under Fedora14, SDK2.4, restart GPU works in 100% of my 5xxx series cards, and 0% of my 6xxx series cards.

restart GPU works even if the GPU is hung due to things like overheat-lockup? 

I simply have a monitoring script that checks for serious lockups and coldreboots the rig if it is triggered, not pretty, but all GPU are at least up and mining again within a minute.
Will probably add that corespeed controlled by temperature levels script(it down clocks the core if temperature gets too high) I saw in some thread on the forum a few days ago.

Summertime is a bitch when it comes to mining   

[d3m0n1q_733rz]

I was just thinking, how about instead of restarting on lockups, we work to throttle the work load once the temp. reaches a preset value?  Most of these cores have an internal temperature sensor.  We just have to monitor it and throttle back to let it cool so as to let it continue mining.  However, it would be a good idea to let the user know when the temperature is being reached so as to allow for user intervention to fix the cooling issue that it is having.

[miscreanity]

The problem I've noticed is that there are occasional lock-ups even with the temperature steady. My 69xx cards won't start again even if cgminer is restarted. They don't respond to anything and require a cold boot.

[tigereye]

I apologize for repeating the question but it's been about 6 pages and it appears to have been overlooked.

I'm getting the following error when trying to run the latest version of cgminer (compiled from git checkout) on linuxcoin.

Code:

[2011-08-09 23:57:10] Error: Getting program info CL_PROGRAM_BINARY_SIZES. (clGetPlatformInfo)
[2011-08-09 23:57:10] Failed to init GPU thread 0
[2011-08-09 23:57:15] Error: Getting program info CL_PROGRAM_BINARY_SIZES. (clGetPlatformInfo)
[2011-08-09 23:57:15] Failed to init GPU thread 0

When trying to get it to compile I had to first APT-GET a few packages including pkg-config, libcurl4-gnutls-dev, curl, libncurses5-dev and autoconf.

But I managed to get it to compile successfully with the following:

Code:

./autogen.sh
./configure
./make

Unfortunately, after it compiled I get the above error.
After configuring, it reports that OpenCL is enabled. When I do "./cgminer --ndevs" it properly reports my number of GPUs.

Has anyone else run into this problem on their machines?
It works perfectly on another linuxcoin install, but not on this one rig...but I don't know what separates this rig from the others. I must have missed installing some package? or other prerequisite?

Thanks for any help you can provide!

[Endeavour79]

I tried cgminer on a couple of my boxes last night and woke up to find 3/4 GPU marked as DEAD on one and 2/4 DEAD on another. Trying to restart the DEAD GPU doesnt seem to do anything on either machine (restarting the ones still running did seem to restart them OK). Both boxes have been running for weeks using poclbm without errors. Running the 1.5.3 binary on Ubuntu (3xHD5870 and HD6310).

Anyone else seeing problems with DEAD GPU that won't recover unless cgminer is restarted?

BB.

Restart dead GPUs does not work for me too. Win7 64bit, Catalyst 11.7

Me too. LinuxCoin beta final

In my testing, under Fedora14, SDK2.4, restart GPU works in 100% of my 5xxx series cards, and 0% of my 6xxx series cards.

Not for me. It won't restart either gpu on my 5970.

Does not work in Win 7 x64 on HD69xx and HD58xx for me.

[kano]

...

Another possibility: did you do the following :

Code:

cd /; tar zxpvf /opt/AMD-APP-SDK-v2.4-lnx64/icd-registration.tgz

Without the above, things are very likely to behave according to
what you describe.

...

Yes that's in the README file but some people (I did the very first time also) accidentally skip it.

[-ck]

Since Con is away...

I thought I'd take a try at integrating some of the recent changes in both phatk kernel threads. (here and here)
I've also changed the method used to specify various #defines for the kernels by simply specifying the defines as build options for clBuildProgram() instead of editing the .cl text on the fly. (so much simpler!)

Compared to the current kernel in cgminer 1.5.3, this does benefit from reduced ALU OPs, although not as much as either of the other phatk kernels:

1.5.3:
VLIW4: 1699 ALU OPs
VLIW5: 1376 ALU OPs

Mine:
VLIW4: 1694 ALU OPs
VLIW5: 1368 ALU OPs

My changes are here at github, but it's all in one big ugly commit, and not broken out by the individual changes, so i don't feel comfortable in the slightest offering a pull request to CK for it.

Don't be scared. You're doing good work. I'll play with your changes and see if they break anything

[ah42]

Don't be scared. You're doing good work. I'll play with your changes and see if they break anything

Welcome back!
It's not so much about being scared; More that I didn't do a bunch of little commits and comment the specific changes. I would have liked to have done that...at least so they could be submitted as separate changesets/patches for you to look at.

I *have* done that for the next couple commits

[-ck]

I have incorporated his changes into the main git tree now.

[d3m0n1q_733rz]

Random question about the SHA-256 hash so I know if I can maybe make a small change to speed up hashing in cgminer:
I've noticed the 8 trailing 0's at the end of the hashes.  Why do these 0's occur and are they computed/always going to be 0's no matter what?  If there will always be those 8 trailing 0's regardless of what block number we're at, it could be possible to simply keep them a constant in the code if we haven't already and speed up hashing by a slight margin.

[Diapolo]

Current 110810 kernel on git has 1368 ALU OPs for 58XX and 1696 for 69XX, that's neither phatk 2.2 nor my latest result (which is 1364 / 1688), but a bit faster than the last official CGMINER kernel. I mailed my latest version to Con for review .

The added __attribute__((vec_type_hint(u))) is unknown to the compiler and throws a warning, but IS mentioned in the OpenCL 1.1 manual ... strange.

Dia

[-ck]

ALUs are not the only way to judge performance.

[Diapolo]

ALUs are not the only way to judge performance.

Correct, that's what I wrote in the Phatk thread, too. We also have to look at other factors, I only wanted to point out, that current git seems like a new hybrid version, whose performance is not clear .

Dia

[Diapolo]

ALUs are not the only way to judge performance.

Agreed: actual wall time MH/s is.

However, in this specific instance the two seem to be strongly correlated (which
isn't much of a surprise: execution units on GPU aren't anywhere as smart as
those on CPU).

Point in case: Diapolo's diagnostic turns out to be correct, I ran a parallel experiment
this morning between phoenix+phatk 2.2 and the latest git tree cgminer
(9df379ecc793b6266853 with phatk110810.cl).

Bottom line: cgminer is slower by ~3Mh/s per GPU core.

Also ... I started to look at how to integrate the phatk 2.2 into cgminer, but it's a
real headache: the original phatk code has been re-indented and changed all over
the place.

What would really be helpful is to somehow be able to drop in the latest phatk kernel
into cgminer without having to change it much. Barring that, having some sort of
script that can convert a pristine phatk kernel into a cgminer-compatible version
would be neat.

I will quote myself from the Phatk-thread !

The last kernel releases show, that it is a bit of trial and error to find THE perfect kernel for a specific setup. Phaetus and I try to use the KernelAnalyzer and our Setups as a first measurement, if a new Kernel got "faster". But there are many different factors that come into play like OS, driver, SDK, miner-software and so on.

I would suggest that we should try to create a kernel which is based on the same kernel-parameters for phatk and phatk-Diapolo so that the users are free to chose which kernel is used. One thing is CGMINER kernel uses the switch VECTORS2, where Phoenix used only VECTORS (which I changed to VECTORS2 in my last kernel releases). It doesn't even matter to use the same variable names in the kernel (in fact they are different sometimes) as long as the main miner software passes the awaited values in a defined sequence to the kernel.

Dia

[Diapolo]

I would suggest that we should try to create a kernel which is based on the same kernel-parameters for phatk and phatk-Diapolo so that the users are free to chose which kernel is used. One thing is CGMINER kernel uses the switch VECTORS2, where Phoenix used only VECTORS (which I changed to VECTORS2 in my last kernel releases). It doesn't even matter to use the same variable names in the kernel (in fact they are different sometimes) as long as the main miner software passes the awaited values in a defined sequence to the kernel.

It must be way too early in the day, but this last sentence just confused
me utterly for the second time (read it first in your original post)

I'll try again ^^! There is no need for the kernels to be equal inside (variable names and so on), but the parameters both kernels use (like base, PreVal0 and so on) and which are passed from the main miner software need to be the same in order to be compatible (use phatk, phatk-diapolo or whatever). Better now ?

Dia