python OpenCL bitcoin miner

[sturle]

Is poclbm.py supposed to use 100% CPU, and increase CPU usage of Xorg quite a bit as well?

Code:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 4885 sturle    20   0  420m  56m  26m S  264  0.7  53:15.06 bitcoin            
 5522 sturle    20   0  231m  63m  24m S   97  0.8   9:44.01 poclbm.py          
14130 root      20   0  491m 174m 122m S   27  2.2  12:25.19 Xorg               

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.

[davout]

I think it's a really good thing that such a client gets public, it decreases the chance that the blockchain gets overtaken by NSA XD

[BitLex]

core i7 quad, nvidia GT240, 64bit ubuntu 10.04

CPU: 7000 khps
GPU: 20000 khps

Should I be getting more?  I have python 2.6.5 installed.

compared to my GTX260 which gets ~37.000 stock (575core/1240shader) and up to 45.000 oc'd (685/1480),
you should be ok with 20.000.

gonna run it on a radeon 5850 as soon as it arrives, should be by tomorrow.
hopefully i'll get some more outof that.

[bethel]

640mhash/s - radeon 5970 870mhz/1305mhz - temp : 83c

Presently it run fine, but i'm not sure it gonna be stable, gonna update here if I have any news.

Malouin

What are your -frames and -worksize arguments like? Also what -askrate interval do you have?

I did get two cards working (had to use the crossfirex cable and enable crossfirex).

The thing that baffles me is how to get the same performance out of two cards together as I got out of two cards seperately. It seems if i set the frames very low like -frames=2 I can get one card to do about 97% gpu capacity. The other card, however drops to 60-80%. When I make the frames high like 256 it does ok but any other program on my machine seems to have a higher priority and will make poclbm.exe run slow.

Currently the best compromise I found was
--frames=25 --rate=3 --worksize=256 --device=1 --askrate=30

On a single core processor machine this produces about 90% on each card average but has wild swings.

For a while I thought the issue was my MB or CPU not feeding the data fast enough but I tried the cards in my gaming machine with a quad core and dual x16PCIe slots and it still was about the same.

Any ideas?

[da2ce7]

A quick question, I have had the miner running, if found a "found: 339339279, 26/10/2010 06:27"  however, the coins for that block haven't been added to my bit coin wallet...  Have I missed something, or is my wallet corrupt or something?

I have had non open-cl coins generated, maybe my node isn't announcing the newly found block, It dose say 8 connections..

[xxmalouinxx]

bethel : -f 35 and -w 128 . I don't have any rate or askrate variable.

da2ce7 : If you started to generate before having all the block downloaded, then the block you found isn't valid. Restart your client and start to generate once you got all the block. This happened to me too, david explained it to me pretty well =)

Malouin

[da2ce7]

do you need to have they client generating at the same time as the open-cl miner?

[xxmalouinxx]

Nop, my bitcoin client don't generate from CPU.

[BitLex]

HD5850 just arrived and gets a whopping ~235.000khash/s stock, very nice indeed.
that's 5 times a GTX260 oc'd at nearly the same power consumption (~200W),
it's actually a few watts less on the HD5850, still room to oc it a 'lil.  


some updates:
ran fine througout the day so i did some more testings,
right now i'm up to 267.000 with default poclbm-settings*,
the core clocked at 825MHz (stock 725MHz) doesn't even get close to hot,
stock <63°C vs. current <66°C, it's fan is still idle,
with a bit of luck it might even break 300Mhash, but i'm more than pleased for now.

this card is well worth its money.

* ~270.000 with frames=10, desktop gets kinda unusable then though, but if i dont need it anway there's some extra Mhs to gain


woot!
and just as i write this i generated my first OpenCL block!

it no longer just seems to work, it really does. 

[Vasiliev]

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?

My CPU usage is <5% for poclbm, so something's wrong.

[sturle]

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?

My CPU usage is <5% for poclbm, so something's wrong.

poclbm.py is instructed to use the video card, not the CPU.  If I choose both (0,1), it uses 400% CPU for only 4 khash/s.

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

Some kind of active wait loop in wait_for_events?

Btw -- polcbm.py claims to have found two blocks since it started, but only one is registered in my bitcoin client. :-/

[fergalish]

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

[BitLex]

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

[BitLex]

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.

[sandos]

Well, I recently stopped mining on my  CPUs. Really no reason for that anymore it seems =)

[BitLex]

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.

[xxmalouinxx]

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

[BitLex]

yeah, that's why i didn't use it

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

[Syke]

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.

[BitLex]

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=<forwarded-nodes-ip> (showing 1connection),
-addnode=<forwaded-nopdes-ip> (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.