Topic: python OpenCL bitcoin miner - page 49. (Read 1239039 times)
Sorry guys, I screwed it with the update to SVN 170. There is a bug in getwork patch that makes poclbm useless with more than a single instance. Until this is fixed anyone using more than one instance should use previous version of the patch (against SVN 166). Win32 binary bitcoin-getwork-svn166-win32.7z
Well, this is not good. I will take a look to figure it out.
I was generating some blocks today on a 5970 and I noticed that both instances of the the miner claimed to have found the same block (see attached image) The main bitcoin client only counts them once (as it should.) Does anyone know what is happening? I am running with default settings and -f 30.
ok, thanks,
so it's nothing to worry about, no big deal anyway, GTX already found a new one,
she's lucky lately.
so it's nothing to worry about, no big deal anyway, GTX already found a new one,
she's lucky lately.
The block won't show up. This happens when the network discovered block just after last request for work by the miner. This is the drawback of the pull manner in which getwork... works. The probability for this to happen is 1/60 with ask rate of 10 seconds and 1/120 with ask rate of 5 seconds. It will be better if work is provided in 'push' manner, but I didn't want to complicate the client with separate server thread.
...about deleting the block chain, and having the client re download it to see if it adds that block....
i just tried not a completely new, but <80.000blocks chain and re-downloading,the block is still missing.
yeah, i also noticed that some blocks need some time to show up,
i already restarted bitcoin, hoping it might materialize somehow,
but it didn't.
first time i noticed this, hopefully the last too.
i already restarted bitcoin, hoping it might materialize somehow,
but it didn't.
first time i noticed this, hopefully the last too.
here's another unusual behaviour, a lost block.
the GTX-miner found 2blocks, both show the proof-of-work found...generated 50.00 in the debug.log,
but it seems only one of them made it into my wallet.
the GTX-miner found 2blocks, both show the proof-of-work found...generated 50.00 in the debug.log,
but it seems only one of them made it into my wallet.
i usually start 'em all using addnode, these getblock-lags just happened quite often lately, so i tried using the connect-switch,
here's a screeny* of 2 nodes seem to be connected to forwarded-node, both show only 1 connection, the higher blockcount is, the lower isn't, it sometimes even tells me, drops to 0connections for a sec, then back to 1, but still doesnt get any new blocks.
same happens when both are addnode'd and showing 8connections, connections drop below 8 and no more blocks are downloaded, mining doesnt stop though, lots of wasted energy, at least it's green.
* from front to back
- GPU mining to (addnode'd) remote node (not on screen)
- HD-miner-node -connect= (idle)
- a random node -connect= (idle, running in VM)
about half an hour after the shot was taken, the random node still hasnt loaded any blocks,
it's not that it's always the VM that lags blocks though, sometimes it's the other way around.
here's a screeny* of 2 nodes seem to be connected to forwarded-node, both show only 1 connection, the higher blockcount is, the lower isn't, it sometimes even tells me, drops to 0connections for a sec, then back to 1, but still doesnt get any new blocks.
same happens when both are addnode'd and showing 8connections, connections drop below 8 and no more blocks are downloaded, mining doesnt stop though, lots of wasted energy, at least it's green.
* from front to back
- GPU mining to (addnode'd) remote node (not on screen)
- HD-miner-node -connect=
- a random node -connect=
about half an hour after the shot was taken, the random node still hasnt loaded any blocks,
it's not that it's always the VM that lags blocks though, sometimes it's the other way around.
while running standalone, non-forwarded, it's 8connections
while addnode'd, it's 8connections,
while connect'ed to forwarded node, it's only one.
what also might help is just running on different (but forwarded) ports,
as mentioned before silly me isn't able to compile/patch, so i'm not able to try yet.
while addnode'd, it's 8connections,
while connect'ed to forwarded node, it's only one.
what also might help is just running on different (but forwarded) ports,
as mentioned before silly me isn't able to compile/patch, so i'm not able to try yet.
i noticed some strange disconnections lately,
everything seems alright, but it somehow hangs and doesnt get new blocks,
happens while
connected un-forwarded (showing 8connections),
-connect= (showing 1connection),
-addnode= (showing 8connections),
forwarded-node has 50<80connections and seems to always have all blocks, other nodes sometimes just don't get them, no matter how i connect them.
not sure yet what's causing this, a feature to force getblock or somethin' would be handy sometimes.
but this made me try to set up both OpenCL miners to run on one node.
starting the (former GTX-only) node with -rcpallowip, connection and mining works fine,
eatin' a few Mhashes though.
while running the (remote) HD-miner at defaults (askrate=5), the (local) GTX-miner slows down from ~45M to ~43M average, setting (remote) askrate=10 helped here, still a noticable but <1M loss,
the HD-miner also goes down ~2%, from 300 to 294.
tested on 100MBit, maybe there's <2% loss on gigabit networks, i'll try as soon as i find someone to pay for some switches and cards.
happy crunching
and if anyone knows of, or finds a solution to that spooky non-forwarded-node-disconnects, let me know, thanks.
everything seems alright, but it somehow hangs and doesnt get new blocks,
happens while
connected un-forwarded (showing 8connections),
-connect=
-addnode=
forwarded-node has 50<80connections and seems to always have all blocks, other nodes sometimes just don't get them, no matter how i connect them.
not sure yet what's causing this, a feature to force getblock or somethin' would be handy sometimes.
but this made me try to set up both OpenCL miners to run on one node.
starting the (former GTX-only) node with -rcpallowip, connection and mining works fine,
eatin' a few Mhashes though.
while running the (remote) HD-miner at defaults (askrate=5), the (local) GTX-miner slows down from ~45M to ~43M average, setting (remote) askrate=10 helped here, still a noticable but <1M loss,
the HD-miner also goes down ~2%, from 300 to 294.
tested on 100MBit, maybe there's <2% loss on gigabit networks, i'll try as soon as i find someone to pay for some switches and cards.
happy crunching
and if anyone knows of, or finds a solution to that spooky non-forwarded-node-disconnects, let me know, thanks.
Can anyone post a walkthrough on how to install this (and any dependencies) on Ubuntu? Or post a Linux binary? I have a Tesla I'm dying to try out.
yeah, that's why i didn't use it
and i havent been compiling any miners myself (tried a few times but had no luck so far installing all required components on x64), so grabbing code x from y to patch z wouldn't help me much.
i'm just a user anyway, not a coder (php-scripter for fun, but that's it),
one could say i represent the masses (at least those that are interested in how it works), that's why i'm so happy that there's a few nice people to realease binaries.
playing around with frames just gives me a ~1-2% increase, not really worth mentioning and for the cost of a very low responding desktop.
@m0mchil: you should really put your btc-address either into the initial post of this thread, or your sig, kinda hard to find already and will get even worse over time.
... I removed usage of vectors. So the '-w 128' is not relevant anymore. Of course you can grab the vectors version from git and use it like before. It is really difficult to optimize for all possible devices. Current version is kind of best for all.
and i havent been compiling any miners myself (tried a few times but had no luck so far installing all required components on x64), so grabbing code x from y to patch z wouldn't help me much.
i'm just a user anyway, not a coder (php-scripter for fun, but that's it),
one could say i represent the masses (at least those that are interested in how it works), that's why i'm so happy that there's a few nice people to realease binaries.
playing around with frames just gives me a ~1-2% increase, not really worth mentioning and for the cost of a very low responding desktop.
@m0mchil: you should really put your btc-address either into the initial post of this thread, or your sig, kinda hard to find already and will get even worse over time.
Hey Bitlex !
I'm happy to see that everything's going well on your side =) I'm presently at 650-660mhash/s with my radeon 5970
Setting : 900mhz/1000 memory clock/ vcore to 1.15v / Temps : 78c, with 100% fan on. I use this command :
--user=***** --pass=***** -f 35 -w 128
You should try to add the -f 35 -w 128 and see how many % you gain. I gained around 20-30mhash with that.
Malouin
I'm happy to see that everything's going well on your side =) I'm presently at 650-660mhash/s with my radeon 5970
Setting : 900mhz/1000 memory clock/ vcore to 1.15v / Temps : 78c, with 100% fan on. I use this command :
--user=***** --pass=***** -f 35 -w 128
You should try to add the -f 35 -w 128 and see how many % you gain. I gained around 20-30mhash with that.
Malouin
nah, i wouldn't say that,
the bitcoin-randomizer-node only runs at ~800khash/s on a single core and still generates blocks every now and then,
i even got miners running on an intel-Atom and PIII-1GHz that just get ~250khash/s.
you just need some more luck, any single hash could be the one we'r all looking for.
if your running a GPU-miner anyway though, there's at least on midclass-ati-cards no real need to run CPUs, they'll consume more power than needed to get what you want. give your gfx-core another 1-2% speed and your done, this'll take ~5W+ instead of >50W+ for CPUs@full throttle.
if your thinking about, or going to build a new miner-machine, i agree,
don't bother with CPUs, nor with nvidia.
careful though if you buy new stuff, dont get one of those shiny new HD6850/70, or you'll be dissapointed.
the bitcoin-randomizer-node only runs at ~800khash/s on a single core and still generates blocks every now and then,
i even got miners running on an intel-Atom and PIII-1GHz that just get ~250khash/s.
you just need some more luck, any single hash could be the one we'r all looking for.
if your running a GPU-miner anyway though, there's at least on midclass-ati-cards no real need to run CPUs, they'll consume more power than needed to get what you want. give your gfx-core another 1-2% speed and your done, this'll take ~5W+ instead of >50W+ for CPUs@full throttle.
if your thinking about, or going to build a new miner-machine, i agree,
don't bother with CPUs, nor with nvidia.
careful though if you buy new stuff, dont get one of those shiny new HD6850/70, or you'll be dissapointed.
Well, I recently stopped mining on my CPUs. Really no reason for that anymore it seems =)
mornin' miners, up for another update?
here we go...
short version:
HD5850 300.000 khash/s @ 925MHz
long version:
i did some more testings and tweaks and finally reached my goal,
to break the 300M-barrier while keeping below 70°C (setting higher voltages would not only consume more energy, as a result it'll also create noise which i really don't like).
while Catalysts (and others) tests fail at clocksets above 910MHz, the pocl-miner doesnt care much about it, it runs fine up to 935MHz, more and the miner starts to get laggy and just starting the GPU Caps Viewer crashes the system (not if it's already running).
to stay safe i set it to 925MHz, which still gives hangups and failures in tests, Fallout:New Vegas doesn't even start, stuff like that,
but the miner runs fine, stable and averages at above 300Mhash/s.
i think i'll keep it like that and just set it to defaults to kill Mr.House and save (or rule?) the world, that old guy kinda scares me.
however, the ordinary screenshot this time is also a nice comparison of both of my OpenCL-capable Cards, funny that both of 'em found a block within 1hour.
to the left (via vnc) we see a GTX260@685MHz at work, mining 45.000 khash/s on win7x64,
to the right her greatness HD5850@925MHz, mining 300.000 khash/s on xp64.
not to mention that theres still 5x2-3GHz CPUs left on those 2 machines that don't do anything right now, but hey, i'd get what, ~1000 khash/s per core? on the HD-miner that's <1%! and it'll also create more heat and noise and will need more energy too,
i'd rather tweak the card/s a little more.
but i think i'm done now and more than happy, hell i'm thrilled by those results, never thought the card would go that far.
what do you think?
how's your machine/s working?
tell us about it, we wanna know, well at least i do.
have a great day.
here we go...
short version:
HD5850 300.000 khash/s @ 925MHz
long version:
i did some more testings and tweaks and finally reached my goal,
to break the 300M-barrier while keeping below 70°C (setting higher voltages would not only consume more energy, as a result it'll also create noise which i really don't like).
while Catalysts (and others) tests fail at clocksets above 910MHz, the pocl-miner doesnt care much about it, it runs fine up to 935MHz, more and the miner starts to get laggy and just starting the GPU Caps Viewer crashes the system (not if it's already running).
to stay safe i set it to 925MHz, which still gives hangups and failures in tests, Fallout:New Vegas doesn't even start, stuff like that,
but the miner runs fine, stable and averages at above 300Mhash/s.
i think i'll keep it like that and just set it to defaults to kill Mr.House and save (or rule?) the world, that old guy kinda scares me.
however, the ordinary screenshot this time is also a nice comparison of both of my OpenCL-capable Cards, funny that both of 'em found a block within 1hour.
to the left (via vnc) we see a GTX260@685MHz at work, mining 45.000 khash/s on win7x64,
to the right her greatness HD5850@925MHz, mining 300.000 khash/s on xp64.
not to mention that theres still 5x2-3GHz CPUs left on those 2 machines that don't do anything right now, but hey, i'd get what, ~1000 khash/s per core? on the HD-miner that's <1%! and it'll also create more heat and noise and will need more energy too,
i'd rather tweak the card/s a little more.
but i think i'm done now and more than happy, hell i'm thrilled by those results, never thought the card would go that far.
what do you think?
how's your machine/s working?
tell us about it, we wanna know, well at least i do.
have a great day.
can't help you with that one, the 2 blocks i found so far just showed up once,
but i'v got another update on the HD5850.
the core is up to 910MHz now (from 725@stock), which gives me ~297.000 khashes at default poclbm settings.
system needs ~230W now, plus ~15% power to get plus ~25% hashes, still a good deal.
seems like that's it for basic catalystcc oc'ing, maybe a bit more using higher voltages/other tools, but i'm fine with it.
to satisfy your screeny-fetish
but i'v got another update on the HD5850.
the core is up to 910MHz now (from 725@stock), which gives me ~297.000 khashes at default poclbm settings.
system needs ~230W now, plus ~15% power to get plus ~25% hashes, still a good deal.
seems like that's it for basic catalystcc oc'ing, maybe a bit more using higher voltages/other tools, but i'm fine with it.
to satisfy your screeny-fetish
$ nice -n 15 ./poclbm.py --user=******** --pass=******** -f 60 -w 256
No device specified, you may use -d to specify one of the following
found: 46380061, 26/10/2010 14:46
found: 46380061, 26/10/2010 14:46
17616 khash/s
Found this just now. Why did it find the same block twice? Could it be there are, oh, like two threads repeating the same work?
EDIT: also, the main bitcoin client credited me with 50btc, one block, at 14:45. Total to my credit is just one block 50btc. What's going on? I looked through the source, and the RPC commands list. Where does the source poclbm.py tell the bitcoin client that it found a hash below the target? (I'm a python newbie).
No device specified, you may use -d to specify one of the following
found: 46380061, 26/10/2010 14:46
found: 46380061, 26/10/2010 14:46
17616 khash/s
Found this just now. Why did it find the same block twice? Could it be there are, oh, like two threads repeating the same work?
EDIT: also, the main bitcoin client credited me with 50btc, one block, at 14:45. Total to my credit is just one block 50btc. What's going on? I looked through the source, and the RPC commands list. Where does the source poclbm.py tell the bitcoin client that it found a hash below the target? (I'm a python newbie).
Is poclbm.py supposed to use 100% CPU, and increase CPU usage of Xorg quite a bit as well?
I get about 11500 khash/s maximum from poclbm.py, which is the same I get from bitcoin when running on all 4 CPU cores. While poclbm.py is running, hash production from bitcoin is reduced to about 8k. Is this normal? Production from poclbm.py decreases if I reduce it's CPU share, e.g. by niceing it.
GPU is some ATI HD 5400 series.
OpenCL can run on CPUs, too. It seems like that's what is happening. Maybe. Does poclbm ask you to choose your device when you start it?I get about 11500 khash/s maximum from poclbm.py, which is the same I get from bitcoin when running on all 4 CPU cores. While poclbm.py is running, hash production from bitcoin is reduced to about 8k. Is this normal? Production from poclbm.py decreases if I reduce it's CPU share, e.g. by niceing it.
GPU is some ATI HD 5400 series.
My CPU usage is <5% for poclbm, so something's wrong.
cProfile on poclbm.py overnight, and here is the function hogging my CPU:
Code:
2549577 85597.463 0.034 85597.463 0.034 __init__.py:284(event_wait)
This is defined in pyopencl:
Code:
def event_wait(self):
wait_for_events([self])
return self
Btw -- polcbm.py claims to have found two blocks since it started, but only one is registered in my bitcoin client. :-/
Jump to: