python OpenCL bitcoin miner

[Reto]

I tried the search function, but I didn't get any results, so gonna ask my question.

Can I cap the processing power this can use? I'd like to be able to limit it to 50% or so power so I can still get decent gaming performance.

[cdhowie]

I tried the search function, but I didn't get any results, so gonna ask my question.

Can I cap the processing power this can use? I'd like to be able to limit it to 50% or so power so I can still get decent gaming performance.

You shouldn't have to if you use -f.  Try adding -f 120 to the command line and play a game.  The game framerate will be just slightly degraded; I don't usually notice a difference.  If you have dual monitors and put the miner on the one you don't use for gaming, you'll notice that the hashrate will drop dramatically while you play.  Basically it will be using the extra GPU cycles that the game is idle during.

[Reto]

At the end or anywhere in the command?

[cdhowie]

At the end or anywhere in the command?

Anywhere, so long as you don't separate another switch and its argument.  The end is a good place to put it if you want to be sure. 

[OVerLoRDI]

I removed one of my video cards for a bit and noticed the poclbm was not using 100% of a cpu core any more.  The second I added back in my 2nd card cpu usage jumped up to 1 full core pure instance of poclbm.  Apparently the high gpu usage is tied to dual card setups.

Although, the problem is not seen on Windows XP.  I have a miner running XP, that has dual 5870s, and poclbm doesn't eat cpu there.  It may only be a Windows 7 issue.

Maybe this can help track it down. 

[marcus_of_augustus]

I removed one of my video cards for a bit and noticed the poclbm was not using 100% of a cpu core any more.  The second I added back in my 2nd card cpu usage jumped up to 1 full core pure instance of poclbm.  Apparently the high gpu usage is tied to dual card setups.

Although, the problem is not seen on Windows XP.  I have a miner running XP, that has dual 5870s, and poclbm doesn't eat cpu there.  It may only be a Windows 7 issue.

Maybe this can help track it down. 

On Linux Ubuntu 10.10, I think it maybe a bit more complicated than this ... I've noticed that when you run a graphical tool to monitor CPU/Mem usage (whilst miners are running) then the CPU usage skyrockets. If you use the command line tool

$top

the CPU usage stays low around 3-5%, and it is mostly on Xorg that is using the CPU. In  fact, I think if you run any process that has graphics GUI or other then Xorg goes nuts, it must be competing with poclbm for the GPU, even when you give it a -f 30 ....

A slightly related anomaly I noticed one time, after loggin in on boot-up I set all miners off and they were getting ~2MHash more than they normally do for about 10-15 seconds, but then something happened and they dropped back to normal speeds ... so i suspect Xorg hadn't woke up and stuck its nose in yet ... so to test the theory i rebooted and ran fgl_glxgears immediately on logging in. Similar behaviour, for 10-15 seconds I was getting 3000+ fps and then it stopped and throttled back to < 1000 fps ... so something (Xorg most likely)  is definitely jumping in and throttling poclbm and fglrx from running at optimum ... unfortunately it also eats CPU as it does it. Managing GPGPU processing with Xorg is a kludgy idea, can't believe this is the best AMD can come up with.

[phenom]

Hey guys,

I got my 5870 today.

Using the GUI miner by Kiv.

OS	Win7 x64
Cat	11.3
SDK	v2.4
Mem	900 Mhz

I'm pulling in 330 Mhash/s on average at the moment. Tends to bounce around from 328-336.

It's been going for about an hour and the temperature reading from the catalyst control center is 74c, activity 98%, fan speed 70%.

I'm using the following flags : -v -w128

Looking from the hardware comparison table I should be able to pull out some more, possibly up to 350. Do you think those kinds of results are only possible on a dedicated box running Linux? I'm not sure whether to downgrade the SDK to 2.1/2.2 to test it though. Also heard people were having problems with the GUI miner on 2.1, thoughts?

[rezin777]

Do you think those kinds of results are only possible on a dedicated box running Linux?

No.

As for the rest of your post, I don't know.

[FnuGk]

how do i run it on mac?

This is what I had to do.

Download and install Xcode

Install MacPorts from: http://www.macports.org/install.php

Install the dependences for poclbm. This step may take a long time while it downloads and compiles stuff:

sudo port install py26-pyopencl

Download the sources for m0mchil-poclbm, from https://github.com/m0mchil/poclbm

then open a terminal and extract it, and give it a try.

mkdir Bitcoin
cd Bitcoin
tar zxvf ~/Downloads/m0mchil-poclbm-b981138.tar
cd m0mchil-poclbm-b981138/
python2.6 poclbm.py -d 0 -o yourfavoriteminer -p 8332 -u user@example.com --pass=something

Be aware, that for what ever reason, OS X is FAR slower for mining than Linux or Windows. I run this on a Mac Pro with a pair of ATI Radeon HD 5770s. In OS X I get about 65Mhash/s on one and 95Mhash/s on the other. I installed  Ubuntu 10.10 and boot into it through Bootcamp. There I get 170Mhash/s on each card, over 2x the performance.

thanks.

using poclbm gives me about 3400 khash/s (4500 with -f 15 -w 64) while using diablominer i get 5500khash/s
this is on a 2010 mbp with a GeForce 320m

[mtrlt]

I think I've found a bug in poclbm. If I'm right, it goes like this:

The OpenCL part is supposed to calculate the 8 first bytes of the hash. The 4 first bytes are calculated fine, but the next ones are not, so they end up being essentially random numbers. In specific situations, it could lead to the miner ignoring a valid block.

In the python code:
BitcoinMiner.py:161

Code:

				if h[7] != 0:
					self.failure('Verification failed, check hardware!')
				else:

This part checks that the first 4 bytes are indeed zeros. I added another check.

Like this:

Code:

				if h[7] != 0:
					self.failure('Verification failed, check hardware!')
				elif h[6] > 0x80000000:
					self.failure('Verification 2 failed, check hardware or the algorithm! :-P')
				else:

Then I made another change.

BitcoinMiner.py:273

Code:

			self.miner.search(	queue, (globalThreads, ), (self.worksize, ),
								state[0], state[1], state[2], state[3], state[4], state[5], state[6], state[7],
								state2[1], state2[2], state2[3], state2[5], state2[6], state2[7],
								pack('I', uint32(0xFFFF0000)), pack('I', 0),  #<-- here's the target
								pack('I', base),
								f[0], f[1], f[2], f[3], f[4], f[5], f[6], f[7],
								output_buf)

I saw the target given to OpenCL is hardcoded. I changed 0xFFFF0000 to 0x80000000. That should cause the OpenCL part to return nonces that result in hashes having the first 8 bytes lower than 0x0000000080000000, right?

Turns out it doesn't. When I ran poclbm, I got the "Verification 2 failed" message in a few minutes.

For some reason, there is commented-out code in BitcoinMiner.cl that modifies G, which should be the bytes 4-7 of the resulting hash in the end.

BitcoinMiner.cl:299

Code:

	//W13 = W13 + (rotr(W14, 7) ^ rotr(W14, 18) ^ (W14 >> 3U)) + W6 + (rotr(W11, 17) ^ rotr(W11, 19) ^ (W11 >> 10U)); 
	//C = C + (rotr(H, 6) ^ rotr(H, 11) ^ rotr(H, 25)) + (B ^ (H & (A ^ B))) + K[61] + W13; G = G + C;

	//G+=0x1f83d9abU;

Uncommenting them didn't fix the problem, though.

Why is this a problem, then? If the bytes 4-7 of the real hash are below the current target, but the OpenCL program calculates that they're over the hard-coded value of 0xFFFF0000, it would lead to a valid block being ignored, and no BTC for you.

Proposed fix: As the bytes 0-3 are calculated correctly and the target given to OpenCL is hardcoded anyway, I'd drop the target being sent to OpenCL altogether and have it just report nonces that lead to hashes for which the first 4 bytes are zero.

[m0mchil]

I'm using the following flags : -v -w128

Looking from the hardware comparison table I should be able to pull out some more, possibly up to 350. Do you think those kinds of results are only possible on a dedicated box running Linux? I'm not sure whether to downgrade the SDK to 2.1/2.2 to test it though. Also heard people were having problems with the GUI miner on 2.1, thoughts?

You can try with lower -f, i.e. under 20. Or you can overclock your GPU (core, memory doesn't affect performance) a little. I don't think downgrading to 2.2 will bring much more.

[cdonges]

jgarzik: I tested this against vanilla client to be sure blocks are actually accepted. On ATI 4350 it makes ~5800 khash/s.

Did you have to do anything special for it to work with a 4350?  I can't get mine to work after installing the latest AMD drivers the sdk says there is no compliant opendsk video card.

[m0mchil]

I think I've found a bug in poclbm. If I'm right, it goes like this:

The OpenCL part is supposed to calculate the 8 first bytes of the hash.

No. The kernel computes correctly only the 4 first bytes. It's confusing, because there is a code in BitcoinMiner.cl BelowOrEquals() which checks 8 bytes - this produces better assembler for some reason, at least in my setup. It can be replaced with 'if (H == 0)' (but it was slower). That's exactly why the targets are hard coded to difficulty of 1 (00000000 FFFF0000).

The 4 first bytes are calculated fine, but the next ones are not, so they end up being essentially random numbers. In specific situations, it could lead to the miner ignoring a valid block.

Actually you are right, but in a different way - because of this I should use hard coded kernel target of 00000000 FFFFFFFF in order to not lose 1 thousandth of a percent of all valid difficulty=1 candidates. I'll do this with the next release.

            

Code:

elif h[6] > 0x80000000:

...

I saw the target given to OpenCL is hardcoded. I changed 0xFFFF0000 to 0x80000000. That should cause the OpenCL part to return nonces that result in hashes having the first 8 bytes lower than 0x0000000080000000, right?

Why you check for 'lower' with a 'greater than' operator? Where did the '0x80000000' came from?

Anyway, thank you for your comments, they are always welcome.

[Dobrodav]

If you run your miner on dedicated rig, than -f 0 flag is handy. That wll really lag you display, but will run miner on full power.

[sniper_sniperson]

Can someone give me advice how to stable this miner on 5970, MSI afterburned to 875MHz core | 695MHz memory? MHashes/s are way too low - approx. 530, they must be around 640-650. Current extra flags are -v -w128.
I'm using 11.4 the early preview version under Windows 7 x64 because every other driver gives me a bsod

[mtrlt]

No. The kernel computes correctly only the 4 first bytes. It's confusing, because there is a code in BitcoinMiner.cl BelowOrEquals() which checks 8 bytes - this produces better assembler for some reason, at least in my setup. It can be replaced with 'if (H == 0)' (but it was slower). That's exactly why the targets are hard coded to difficulty of 1 (00000000 FFFF0000).

If you mean that this:

Code:

#ifdef VECTORS
	if (belowOrEquals(H.x, targetH, G.x, targetG))
	{
		output[OUTPUT_SIZE] = output[nonce.x & OUTPUT_MASK] = nonce.x;
	}
	else if (belowOrEquals(H.y, targetH, G.y, targetG))
	{
		output[OUTPUT_SIZE] = output[nonce.y & OUTPUT_MASK] = nonce.y;
	}
#else
	if (belowOrEquals(H, targetH, G, targetG))
	{
		output[OUTPUT_SIZE] = output[nonce & OUTPUT_MASK] = nonce;
	}
#endif
}

is faster than this:

Code:

#ifdef VECTORS
	if (H.x == 0)
	{
		output[OUTPUT_SIZE] = output[nonce.x & OUTPUT_MASK] = nonce.x;
	}
	else if (H.y == 0)
	{
		output[OUTPUT_SIZE] = output[nonce.y & OUTPUT_MASK] = nonce.y;
	}
#else
	if (H == 0)
	{
		output[OUTPUT_SIZE] = output[nonce & OUTPUT_MASK] = nonce;
	}
#endif

then I got very different results in my tests on Windows 7 x64 & HD5850.

With belowEquals I get ~270Mhps
With the H == 0 version I get ~275Mhps

That's a 1.8% speed increase.

Actually you are right, but in a different way - because of this I should use hard coded kernel target of 00000000 FFFFFFFF in order to not lose 1 thousandth of a percent of all valid difficulty=1 candidates. I'll do this with the next release.

I'd just stop the target from being sent to the GPU and do that H==0 thing. I see no logical reason that it would be slower. There might be illogical reasons, though :-)

Why you check for 'lower' with a 'greater than' operator? Where did the '0x80000000' came from?

I guess I didn't explain that part that well. I chose 0x80000000 to make it easy to determine if bytes 4-7 were actually calculated correctly. I edited BitcoinMiner.cl to only accept hashes below 0x80000000. In the Python code, "> 0x80000000" (should've been >= though) is checking if that part of the hash is over 0x80000000 and warns the user if it is, i.e. if the GPU calculated the hash wrong. But none of that matters since it wasn't even supposed to calculate bytes 4-7 right.

[Nameroc]

Hello,

A pool I'm trying to connect to requires a higher TIMEOUT than the 5 set in BitcoinMiner.py. Would it be possible to make that into a parameter so I can avoid having to recompile it? I attempted it anyway but I just don't have the time to install and configure all the required prereqs.

Thanks,

Nameroc

[marcus_of_augustus]

No. The kernel computes correctly only the 4 first bytes. It's confusing, because there is a code in BitcoinMiner.cl BelowOrEquals() which checks 8 bytes - this produces better assembler for some reason, at least in my setup. It can be replaced with 'if (H == 0)' (but it was slower). That's exactly why the targets are hard coded to difficulty of 1 (00000000 FFFF0000).

If you mean that this:

Code:

#ifdef VECTORS
	if (belowOrEquals(H.x, targetH, G.x, targetG))
	{
		output[OUTPUT_SIZE] = output[nonce.x & OUTPUT_MASK] = nonce.x;
	}
	else if (belowOrEquals(H.y, targetH, G.y, targetG))
	{
		output[OUTPUT_SIZE] = output[nonce.y & OUTPUT_MASK] = nonce.y;
	}
#else
	if (belowOrEquals(H, targetH, G, targetG))
	{
		output[OUTPUT_SIZE] = output[nonce & OUTPUT_MASK] = nonce;
	}
#endif
}

is faster than this:

Code:

#ifdef VECTORS
	if (H.x == 0)
	{
		output[OUTPUT_SIZE] = output[nonce.x & OUTPUT_MASK] = nonce.x;
	}
	else if (H.y == 0)
	{
		output[OUTPUT_SIZE] = output[nonce.y & OUTPUT_MASK] = nonce.y;
	}
#else
	if (H == 0)
	{
		output[OUTPUT_SIZE] = output[nonce & OUTPUT_MASK] = nonce;
	}
#endif

then I got very different results in my tests on Windows 7 x64 & HD5850.

With belowEquals I get ~270Mhps
With the H == 0 version I get ~275Mhps

That's a 1.8% speed increase.

Actually you are right, but in a different way - because of this I should use hard coded kernel target of 00000000 FFFFFFFF in order to not lose 1 thousandth of a percent of all valid difficulty=1 candidates. I'll do this with the next release.

I'd just stop the target from being sent to the GPU and do that H==0 thing. I see no logical reason that it would be slower. There might be illogical reasons, though :-)

Why you check for 'lower' with a 'greater than' operator? Where did the '0x80000000' came from?

I guess I didn't explain that part that well. I chose 0x80000000 to make it easy to determine if bytes 4-7 were actually calculated correctly. I edited BitcoinMiner.cl to only accept hashes below 0x80000000. In the Python code, "> 0x80000000" (should've been >= though) is checking if that part of the hash is over 0x80000000 and warns the user if it is, i.e. if the GPU calculated the hash wrong. But none of that matters since it wasn't even supposed to calculate bytes 4-7 right.

mOmchill,

Is this H==0 mod. going to go into official version of poclbm miner on github  ?

Cheers.

[bitcoineater]

does anyone have the best settings for a 4850 or are the stock settings the best?

[LobsterMan]

I just installed the 270.61 nvidia drivers, and it seems to make the drivers crash each time I exit poclbm by clicking the x, if I ctrl-c they seem to exit fine most of the time. Nothing serious yet, but I keep getting these in my system event log:

"Display driver nvlddmkm stopped responding and has successfully recovered."