Prior to ./configure, export ATISTREAMSDKROOT to point to your APP SDK directory and ADLROOT to point to your ADL sources and it should be OK. The ADLROOT part is not mandatory but you would lose the thermal monitoring support.

P.S libcrypto.so.0.9.8 comes with openssl.

You've lost so much time in ranting, apparently unwilling to accept objective reality. You could just have migrated to linux instead. It is JUST YOUR FAULT. I am not fixing anything. I am also unable to do so - it's a windows limitation, blame it on Microsoft.

We are providing you software for free (and you are making money out of it). We are trying to provide at least some basic level of support for free in our precious spare time. I personally haven't got even a single 0.01 BTC for this. Yet at the end someone accuses me of some absurd paranoid bullshit. Last time it was that I deliberately don't port it to Windows cause I was a FOSS idealist, heh. Now you are blaming all miner developers in conspiring against your favourite OS. You know what, I feel sorry I've lost so much time writing this reply. You deserve no explanation. You are correct - it's a conspiracy.

kripz you can reproduce it with the latest release? Also did you change your worker password in that timeframe?

It's kind of dilemma for me. What kind of propaganda post should I put in here. Well, definitely more newcomers means less profits due to the higher difficulty. On the other hand, I have other GPU-related stuff to do and I wouldn't mind naive idiots selling their new GPUs cheap en masse.

Any advice?

I have 2x5870s. Running @970MHz, I get about 418MH/s per GPU using hashkill, running at 980MHz, I get about 426MH/s. No memory downclocking involved. Fan speed at 80 keeps them below 65C, anyway that kinda depends on ambient temperature.

It is going to be in the same format as the command line. In a text file, one per line.

Got some bad news...multi-pool support (failover/load-balance) will be delayed. I've had some problems making this work correctly (especially as far as LP stuff is concerned). Another thing is that I will be quite busy the following week or two and won't have time to work on it.

Regarding recent DDoS attack on slush/deepbit pools, this is not good. Nevertheless, there is a tip that may be helpful: it's simple. Just run 2 or more instances against different pools. Since hashkill utilizes all GPUs, GPU load will be balanced nicely. Once a pool is DDoS'd, connections to it would fail and then the other instances will utilize more GPU power. To understand it better, here is an example:

You have 2x5870 cards, running at 400MH/s each, 800MH/s overall. You run two instances - first one running against slush's pool, the second one - against deepbit. GPU load is balanced - you'd roughly spend 400MH/s mining for bitcoin.cz and 400MH/s mining for deepbit.net. Then imagine deepbit.net gets attacked and your connections to it fail. Instance #2 would wait until it can successfully reconnect. No GPU power would be wasted though - now the GPUs would be fully utilized by instance #1 running against bitcoin.cz getting 800MH/s. Once deepbit.net goes online again, you would get GPU utilization balanced all by itself.

This is very quick and dirty load-balancing scheme otherwise hard to do with multi-GPU configurations and one miner per GPU. I am using it and it works nicely.

Doesn't poclbm display stales?

Some pools do report them (deepbit for sure). As for is hashkill more likely to get them...it depends on the pool and your "luck" mostly. Hashkill does flush the queues, but it does not immediately cancel the current getwork so if you have a share in the current NDRange, it would readily submit it and it would get display as stale. I could of course not submit that, but it does not matter...users would feel more happy about this of course, but they would not benefit from that in any way (other than feeling happier about less stales being indicated).

Slush's pool does not support long polling.


Put the export LD_LIBRARY_PATH=... line in your script.

There seems to be a misunderstanding here. Shares are not "processed". getworks are. Each of the 'procd' getworks result in zero, one or more shares. Your stats indicate that:

* You've requested a new getwork 5452 times since the program was run.
* Working on those 5452 getworks, you found 4755 shares and submitted them
* You have 64 stale (or invalid) shares - you submitted them but the pool rejected them.

Now since hashkill requests getworks in advance, if you by chance have a share per each getwork (not zero and not more than one), then you would still not have processed=submitted. That's because a queue is being filled in "in advance".

Multiple "short" blocks in a row are likely to bring that "efficiency" down. That's because on a new block, all the getworks in a queue that are already counted as "processed" are discarded. Efficiency is calculated for the whole program run, not the current block.

Connection failures (e.g unable to connect to the pool to send a share) obviously drops efficiency as well.

It is possible and a matter of luck. Efficiency is calculated based on the number of shares divided by the number of getworks received.

For a single getwork, you may have zero, one or more submitted shares and it is a matter of luck. If you have 3 getworks requested and found 4 shares while processing them - then yes, efficiency would be 125%. In the ideal scenario, efficiency would get close to 100% after hashkill has been working long enough.

There shouldn't be much of a difference (though device-host transfers would be slower with larger buffers of course). BTW is mapping/unmapping device memory possible with pyopencl?

What about lots of people repeating that "price follows difficulty" which is in fact plain bullshit? It's actually difficulty that follows price - and often that's speculative price.


Well, they also "created" this market. More than 90% of the miners wouldn't be there if speculators did not exist.

You are promoting the idea that miners profit should be somehow protected from that speculative factor, thus evening out risks. I would argue that everyone invested different amount of money thus taking higher or lower risk. It _is_ communism - I see nothing wrong about someone throwing money into a risky venture such as bitcoin then losing his investments. I see no reason why wouldn't someone profit on speculative margins while others suck it up due their own greediness and stupidity.

Here - I am suggesting you to do something better. Since you don't want to thrive on speculations, create a communist pool. A pool where everyone gets the same reward per block doesn't matter how much computing power he throws in it. That's because basically everyone that spent some money on GPUs actually relied on speculative BTC price at that particular moment. No need to do that. Stop buying that fancy hardware. Get the reward you think you deserve so much as if it is your human right. Get the same reward as everyone else believing in that union. Drive the speculators out. Eheh.

And how do you know your pool does not do the same?

Well, blame it on all those bitcoin calculators. Full of people joining in thinking about "buy 2x5850, then upgrade to 2x5870 in two months, then 2x6990 in two months, then probably 7990s...then probably a second rig...then another rig...then a yacht".

Sorry, no free lunch.

@xanatos, nice

Anyway, why did you remove that one?


I understand that workgroup size is configurable in poclbm. However, in most cases, 64 should be the best one. Also, hardcoding the required workgroup size helps the OpenCL compiler to do better the register allocation stuff as it "knows" the workgroup size in compile time and do not make worst-case assumptions. You are losing performance due to this.

Another thing is (don't know if that's possible with pyopencl) - don't use clenqueuereadbuffer() (or whatever it's equivalent is). Use clenqueuemapbuffer() instead. It's noticably faster. Hm really started wondering about modifying some python miner to incorporate that kernel there, looks like a quick way to make it portable to windows. Besides, there are obvious problems with the non-ocl part which are due to code inmaturity.

http://hashkill.sourceforge.net/

I am _not_ providing any support regarding building it anyway,sorry.

It's GPL so it can be embedded into GPL software.

You SHOULD NOT set VLIW4 on 5xxx. The reason not using VLIW4 is slower is most likely because you don't take into account that 3 hash operations are calculated instead of 2 (you can consider that as if it was using uint3s instead of uint2s). I am not using uint3 because the OpenCL compiler is buggy and generates wrong ISA code, so that I interlace one uint2 and one uint hash operation.

Another thing is: do not pass OLD_ATI to the kernel unless you have a 4xxx GPU. Otherwise you'd have no BITALIGN and BFI_INT.