Bitcoin Forum
March 29, 2024, 02:51:46 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 [38] 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »
  Print  
Author Topic: python OpenCL bitcoin miner  (Read 1238776 times)
Reto
Newbie
*
Offline Offline

Activity: 101
Merit: 0


View Profile
April 07, 2011, 10:21:14 PM
 #741

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.
1711723906
Hero Member
*
Offline Offline

Posts: 1711723906

View Profile Personal Message (Offline)

Ignore
1711723906
Reply with quote  #2

1711723906
Report to moderator
1711723906
Hero Member
*
Offline Offline

Posts: 1711723906

View Profile Personal Message (Offline)

Ignore
1711723906
Reply with quote  #2

1711723906
Report to moderator
1711723906
Hero Member
*
Offline Offline

Posts: 1711723906

View Profile Personal Message (Offline)

Ignore
1711723906
Reply with quote  #2

1711723906
Report to moderator
"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
cdhowie
Full Member
***
Offline Offline

Activity: 182
Merit: 107



View Profile WWW
April 07, 2011, 10:27:05 PM
 #742

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.

Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ

Thanks to ye, we have the final piece.

PGP key fingerprint: 2B7A B280 8B12 21CC 260A  DF65 6FCE 505A CF83 38F5

SerajewelKS @ #bitcoin-otc
Reto
Newbie
*
Offline Offline

Activity: 101
Merit: 0


View Profile
April 07, 2011, 10:44:20 PM
 #743

At the end or anywhere in the command?
cdhowie
Full Member
***
Offline Offline

Activity: 182
Merit: 107



View Profile WWW
April 07, 2011, 10:46:31 PM
 #744

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.  Smiley

Tips are always welcome and can be sent to 1CZ8QgBWZSV3nLLqRk2BD3B4qDbpWAEDCZ

Thanks to ye, we have the final piece.

PGP key fingerprint: 2B7A B280 8B12 21CC 260A  DF65 6FCE 505A CF83 38F5

SerajewelKS @ #bitcoin-otc
OVerLoRDI
Member
**
Offline Offline

Activity: 60
Merit: 10


View Profile
April 08, 2011, 04:16:03 AM
 #745

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
Legendary
*
Offline Offline

Activity: 3920
Merit: 2347


Eadem mutata resurgo


View Profile
April 11, 2011, 06:45:33 AM
 #746

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
Newbie
*
Offline Offline

Activity: 35
Merit: 0


View Profile
April 11, 2011, 10:22:49 AM
 #747

Hey guys,

I got my 5870 today.

Using the GUI miner by Kiv.

OSWin7 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
Full Member
***
Offline Offline

Activity: 154
Merit: 100


View Profile
April 11, 2011, 10:35:00 AM
 #748

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
Newbie
*
Offline Offline

Activity: 55
Merit: 0


View Profile
April 11, 2011, 04:06:50 PM
Last edit: April 11, 2011, 04:18:39 PM by FnuGk
 #749


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
Member
**
Offline Offline

Activity: 104
Merit: 10


View Profile
April 11, 2011, 06:43:25 PM
 #750

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 (OP)
Full Member
***
Offline Offline

Activity: 171
Merit: 127


View Profile
April 12, 2011, 05:17:35 AM
 #751


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
Newbie
*
Offline Offline

Activity: 8
Merit: 0


View Profile
April 12, 2011, 06:54:34 AM
 #752

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 (OP)
Full Member
***
Offline Offline

Activity: 171
Merit: 127


View Profile
April 12, 2011, 04:49:48 PM
 #753

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).

Quote
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.

Quote
            
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
Sr. Member
****
Offline Offline

Activity: 350
Merit: 250



View Profile
April 12, 2011, 05:44:37 PM
 #754

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
Full Member
***
Offline Offline

Activity: 124
Merit: 100


View Profile
April 13, 2011, 05:15:16 PM
 #755

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
Member
**
Offline Offline

Activity: 104
Merit: 10


View Profile
April 13, 2011, 07:16:36 PM
 #756

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.

Quote
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 :-)

Quote
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
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
April 14, 2011, 12:44:02 AM
 #757

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
Legendary
*
Offline Offline

Activity: 3920
Merit: 2347


Eadem mutata resurgo


View Profile
April 21, 2011, 09:28:53 AM
 #758

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.

Quote
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 :-)

Quote
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
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
April 21, 2011, 05:15:47 PM
 #759

does anyone have the best settings for a 4850 or are the stock settings the best?
LobsterMan
Member
**
Offline Offline

Activity: 73
Merit: 10


View Profile
April 22, 2011, 03:17:29 AM
 #760

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."

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 [38] 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!