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

[kano]

Is there a possibility to stop a ICA/ZTX worker/thread ?

I'd like to "Disable" ICA2 i.e. and let the others running.. like with GPU's

No.

Is it planned to be possible some day?

As this way I can very easy identify a particular FPGA Board and debug it further/reflash it and so on..

However, if you use the API command 'pgadisable|N' yes you can do it via the API
(and 'pgaenable|N')

see API-REAME about enabling privileged access to cgminer via the API

[1714821584]

1714821584

[1714821584]

1714821584

[1714821584]

1714821584

[kano]

If you can switch pools and switching causes the one switched to, to move in the order to the top you just have to start at lowest priority then switch to increasingly higher priorities. At least I thought you could switch in the API.

Yeah, I'm just saying it would be nice if it was a bit easier. Like have an entry box for priorities and an entry box for adding a pool on the fly.

$readonly = false;
$poolinputs = true;

As per the API-README at the end about miner.php

Also see API-REAME about enabling privileged access to cgminer via the API
(since changing cgminer is privileged access)

[AxelMi]

In the night all my cgminers on win32 died all at the same time.

[-ck]

In the night all my cgminers on win32 died all at the same time.

I believed you the first time. What I don't have, as yet, is an explanation or anything in particular to debug since I can't reproduce it yet.

Maybe if you run one instance in debug mode (-D -T) you can see what the last thing is that is logged.

[AxelMi]

In the night all my cgminers on win32 died all at the same time.

I believed you the first time. What I don't have, as yet, is an explanation or anything in particular to debug since I can't reproduce it yet.

Maybe if you run one instance in debug mode (-D -T) you can see what the last thing is that is logged.

For finding the error i am running one instance with -fix-protocol.
I had the idea maybe the Exception comes when the DSL-Router makes a reconnect and stratum looses his tcp connection.
Logging is also enabled now.

[mdude77]

I'm getting very high CPU usage on Win7 using ver 2.7.7. Basically 1 core is almost always near 100%. Anyone else with the same issue?

Usually this is intensity related.  Anything higher than 9 will spike CPU usage.

M

[Vbs]

I was running cgminer 2.5.0 till today, as the latest versions had a performance hit on my 5850's (win x64, SDK 2.5 on Cat 12.1), since the last phatk update (~400MH/s to ~320MH/s).

Since I had some free time today I went to check what had changed from phatk120223 to phatk120823 and found what was causing me that performance hit. Commenting the problematic lines fixed it:

Code:

//#if defined(OCL1)
	#define SETFOUND(Xnonce) output[output[FOUND]++] = Xnonce
//#else
//	#define SETFOUND(Xnonce) output[atomic_add(&output[FOUND], 1)] = Xnonce
//#endif

I still find it strange how the atomic_add could be responsible for that much of a mhash hit, since it will only be called on found nonces.

(Running 2.8.3 now, will keep monitoring performance for any issues)

[ralree]

Just updated to 2.8.3.  I have to say I really don't like the new precision on numeric output:

GPU 0:  73.0C 2900RPM | 604.2M/661.2Mh/s | A:3 R:0 HW:0 U: 7.03/m I: 9
GPU 1:  74.0C 2912RPM | 595.1M/659.3Mh/s | A:5 R:0 HW:0 U:11.72/m I: 9
GPU 2:  74.0C 2922RPM | 611.8M/658   Mh/s | A:10 R:0 HW:0 U:23.44/m I: 9

Could you put a .0 on there instead of all that blank space?  It's a minor thing, but I like it better that way.

[Krak]

$readonly = false;
$poolinputs = true;

As per the API-README at the end about miner.php

Also see API-REAME about enabling privileged access to cgminer via the API
(since changing cgminer is privileged access)

Wow, that's really cool. Thanks.

[os2sam]

Cgminer now displays the actual share difficulty target it hit as well as the current pool difficulty like so:

Code:

 [2012-10-12 21:00:31] Accepted 2687d42a Diff 6/3 GPU 1 pool 2
 [2012-10-12 21:00:41] Accepted 00f98044 Diff 262/3 GPU 3 pool 2
 [2012-10-12 21:00:45] Accepted 3840818b Diff 4/3 GPU 2 pool 2
 [2012-10-12 21:00:55] Accepted 35777786 Diff 4/3 GPU 1 pool 2

I'm not understanding this.  Aren't these difficulty numbers multipliers of current difficulty?  How/why would a miner be working on a higher difficulty than the pool is requesting?

[Krak]

I'm not understanding this.  Aren't these difficulty numbers multipliers of current difficulty?  How/why would a miner be working on a higher difficulty than the pool is requesting?

It has to be able to hit a higher difficulty or else you'd never find a block.

[amigaman]

This post is the most interesting and do you know why? The GPU code is UNCHANGED between 2.7.6 and 2.8.3. The only thing that is different is the stratum code. Now why would that make your GPUs SICK now when they didn't previously? Because with the stratum code, the device is busier than ever. There is no possible way to keep the device as busy as doing it in the c code internally in cgminer. So your devices are no longer getting any rest between work.

EDIT: This is precisely why stratum was developed by the way; in order to be able to keep much higher hashrate devices busy. If you want to test this theory, use version 2.8.3 and connect to the proxy in http mode by using --fix-protocol.

That is quite interesting, i must admit.
My GPUs are mostly at 99% load, i have the CCC open all the time, but must admit i don't look all the time.
Is it that the load drops sometimes for a short period and that makes the GPU cool or recover so it can look like lasting longer, and on stratum it is on 99% load 24h a day?

Also, i have a request:
Is it possible to show the fan percentage with the rpm's? I use CCC to monitor fan percentage, because that is my measure when and if  my computers need to be air condititoned.
As long as fan percentage is below my set max of 55% i declare them sufficient and do not reduce engine clock. (But on the other hand it seems i need to to have stratum work?)

[Luke-Jr]

Just updated to 2.8.3.  I have to say I really don't like the new precision on numeric output:

GPU 0:  73.0C 2900RPM | 604.2M/661.2Mh/s | A:3 R:0 HW:0 U: 7.03/m I: 9
GPU 1:  74.0C 2912RPM | 595.1M/659.3Mh/s | A:5 R:0 HW:0 U:11.72/m I: 9
GPU 2:  74.0C 2922RPM | 611.8M/658   Mh/s | A:10 R:0 HW:0 U:23.44/m I: 9

Could you put a .0 on there instead of all that blank space?  It's a minor thing, but I like it better that way.

You might prefer BFGMiner's format:

Code:

BFL 0:  68.3C         | 877.2/868.3/865.6Mh/s | A:14233 R:164 HW:  28 U:12.09/m
BFL 1:  68.3C         | 1.477/1.468/1.465Gh/s | A:28533 R:164 HW:  28 U:24.18/m

Cgminer now displays the actual share difficulty target it hit as well as the current pool difficulty like so:

Code:

 [2012-10-12 21:00:31] Accepted 2687d42a Diff 6/3 GPU 1 pool 2
 [2012-10-12 21:00:41] Accepted 00f98044 Diff 262/3 GPU 3 pool 2
 [2012-10-12 21:00:45] Accepted 3840818b Diff 4/3 GPU 2 pool 2
 [2012-10-12 21:00:55] Accepted 35777786 Diff 4/3 GPU 1 pool 2

I'm not understanding this.  Aren't these difficulty numbers multipliers of current difficulty?  How/why would a miner be working on a higher difficulty than the pool is requesting?

Miners are trying to find hashes that meet a minimum of the current difficulty. So if your hash only hit difficulty 1, it is not good enough for a difficulty 3 pool. If your hash hits the Bitcoin difficulty, you found a block.

[-ck]

This post is the most interesting and do you know why? The GPU code is UNCHANGED between 2.7.6 and 2.8.3. The only thing that is different is the stratum code. Now why would that make your GPUs SICK now when they didn't previously? Because with the stratum code, the device is busier than ever. There is no possible way to keep the device as busy as doing it in the c code internally in cgminer. So your devices are no longer getting any rest between work.

EDIT: This is precisely why stratum was developed by the way; in order to be able to keep much higher hashrate devices busy. If you want to test this theory, use version 2.8.3 and connect to the proxy in http mode by using --fix-protocol.

That is quite interesting, i must admit.
My GPUs are mostly at 99% load, i have the CCC open all the time, but must admit i don't look all the time.
Is it that the load drops sometimes for a short period and that makes the GPU cool or recover so it can look like lasting longer, and on stratum it is on 99% load 24h a day?

Also, i have a request:
Is it possible to show the fan percentage with the rpm's? I use CCC to monitor fan percentage, because that is my measure when and if  my computers need to be air condititoned.
As long as fan percentage is below my set max of 55% i declare them sufficient and do not reduce engine clock. (But on the other hand it seems i need to to have stratum work?)

Yes but it is only absolutely tiny amounts of time the load drops and may not even visible in the reported GPU load which isn't an accurate measure anyway.

I only show fan percentage when fan RPM is not available for that particular device. The reason? The fan percentage is just the value you have told the device to run... it could happily say 55% and the fan may have stopped spinning for some reason which is inherently dangerous. The fan speed rpm is a monitor, it is not a setting.

[-ck]

I was running cgminer 2.5.0 till today, as the latest versions had a performance hit on my 5850's (win x64, SDK 2.5 on Cat 12.1), since the last phatk update (~400MH/s to ~320MH/s).

Since I had some free time today I went to check what had changed from phatk120223 to phatk120823 and found what was causing me that performance hit. Commenting the problematic lines fixed it:

Code:

//#if defined(OCL1)
	#define SETFOUND(Xnonce) output[output[FOUND]++] = Xnonce
//#else
//	#define SETFOUND(Xnonce) output[atomic_add(&output[FOUND], 1)] = Xnonce
//#endif

I still find it strange how the atomic_add could be responsible for that much of a mhash hit, since it will only be called on found nonces.

(Running 2.8.3 now, will keep monitoring performance for any issues)

Yes that is interesting. I'm guessing you have underclocked your memory exceptionally low, as that was found to be an issue with use of atomic ops. Some people found a bump of 15 in memory was enough to correct it. Lack of atomic functions there could lead to HW errors and loss of shares. It's a tradeoff either way. The change was put in there to make sure no shares were lost, which can happen with the old opencl code (though it's only a very small number that would be lost).

[ice_chill]

Sorry if this has been asked many times, but why is one version stable, and another version is simply latest, what does it take to get a version to be stable.
I ask because 2.8.3 is crashing about every 3 days.

[-ck]

Sorry if this has been asked many times, but why is one version stable, and another version is simply latest, what does it take to get a version to be stable.
I ask because 2.8.3 is crashing about every 3 days.

I think you answered your own question... I will only call 2.8.x stable once it is stable everywhere. I'm trying hard to find the remaining bug(s) in 2.8.3, and it appears to only be affecting windows users, but the bug is eluding me.

[-ck]

Just updated to 2.8.3.  I have to say I really don't like the new precision on numeric output:

GPU 0:  73.0C 2900RPM | 604.2M/661.2Mh/s | A:3 R:0 HW:0 U: 7.03/m I: 9
GPU 1:  74.0C 2912RPM | 595.1M/659.3Mh/s | A:5 R:0 HW:0 U:11.72/m I: 9
GPU 2:  74.0C 2922RPM | 611.8M/658   Mh/s | A:10 R:0 HW:0 U:23.44/m I: 9

Could you put a .0 on there instead of all that blank space?  It's a minor thing, but I like it better that way.

This is a side effect of trying to find a generic format that is aligned on the screen and fits values from 0 to 18,446,744,073,709,551,616 in a generic way, while still maintaining adequate precision for the relative rate for that device. It is not entirely straight forward and what to do about zeroes is not ever going to be to everyone's satisfaction. 001.0 or 01.00 or 1.000 ?  

By the way, that massive value would show up as 18.45EH/s with that current scheme, so that it could show up aligned on the same screen as something with 0.001 H/s.

[jasinlee]

Current code

Code:

./cgminer --scrypt -o http://ltc.kattare.com:9332 -u jasinlee.1 -p 1 -g 1 --thread-concurrency 8000 -I 18 -w 256 --auto-fan

I Assume this probably has to do something with it.

Code:

 [2012-10-14 21:35:49] Failed to init GPU thread 0, disabling device 0
 [2012-10-14 21:35:49] Restarting the GPU from the menu will not fix this.
 [2012-10-14 21:35:49] Try restarting cgminer.
Press enter to continue:

 [2012-10-14 21:36:09] Your scrypt settings come to 524288000
 [2012-10-14 21:36:09] Error -61: clCreateBuffer (padbuffer8), decrease CT or i
ncrease LG
 [2012-10-14 21:36:09] Failed to init GPU thread 7, disabling device 7

Oh,

use --thread-concurrency 7168 or 5632.  that's cgminer sucking because of ocl memory consumption problems.

Any ideas you could give us on this ? Tried so many things already and its just not quite working.

[Vbs]

Yes that is interesting. I'm guessing you have underclocked your memory exceptionally low, as that was found to be an issue with use of atomic ops. Some people found a bump of 15 in memory was enough to correct it. Lack of atomic functions there could lead to HW errors and loss of shares. It's a tradeoff either way. The change was put in there to make sure no shares were lost, which can happen with the old opencl code (though it's only a very small number that would be lost).

Ah, ok! Thanks for the info. Yep, I'm at 150MHz mem clock. It's to prevent the case of simultaneous nonce finds on different vectors to overwrite the result on the same address, right?

I prefer the tradeoff tbh, I did the math a while ago on the probability of that happening (P=1/(2^32)*1/(2^32)=1/(2^64). On a 1GH/s card, that will happen on average once every ~585 years)

I'm still using that optimization tradeoff I posted for more than a year now!

Code:

#elif defined VECTORS2
	uint result = W[117].x ? 0u:W[3].x;
             result = W[117].y ? result:W[3].y;
	if (result)
	     SETFOUND(result);