It _is_ opensource and the SVN repository is located on sourceforge. I do not commit any change though until I am OK with the current situation. The SVN contains sort of baselines of the current code I am OK with.

How about that:

1) I promise I would commit every single change to the sourceforge SVN. Even a single new comment line.
2) I charge you modest ammount of BTC for answering any question related to build configuration and compilation.

You see, my spare time is rather limited and it is going to be even more limited if I have to answer questions about building a code I still consider experimental. Debugging build issues and solving people's build problems takes up my time I can use for improving the software. I am giving you a compiled binary and spare you from installing the right prerequisites and do the necessary things for a successful build. Some of the prerequisites are not even present in the distro's repositories, so (for example on Slackware) you'd have to build them from source.

Then again it all boils down to the following: since you value opensource that much and need transparent, real-time access to the code. On the other hand (eh) I am the only one working on that project and my time is too limited to resolve problems of users that want to build experimental code. Are you willing to pay for that support? I'd think no.

You need the ICD stuff installed. Go to /opt/AMD-APP-SDK-v2.4-lnx64, tar -zxvf icd-registration.tgz; cp -rp OpenCL/* /etc/OpenCL

SDK2.4 has different library names. You need to reinstall the ICD files for that. DO NOT DELETE ANYTHING FROM /etc/OpenCL !!! Otherwise you would lose backward compatibility with older SDKs.

P.S I am also mining on mining.bitcoin.cz as well. This morning when I got up, I noticed hashkill is stuck on "authentication failure". I've lost a couple of hours not mining anything. That's not good. I will investigate that. Anyway, multi-workers (in failover or load-balance mode) will be supported soon.


The speed indicator displays speed averaged in last 5 seconds. Anyway, that's not good. This means one or more threads are not "fed" fast enough with getworks and are waiting for more work to come and so they are idle. This could be a normal situation with slower links after a long polling notification as the queues are flushed and we are waiting for new work. But this is not normal otherwise.

Yes and who bought your BTC? Why can't you accept the fact that one day they may decide to sell it for a fiat currency just like you did?

IMO yes, faith is what drives demand and demand is one of the two factors driving value.

Green paper currency is backed by multi-billion industry/mining/services sector that puts its trust in it. Bitcoin OTOH is not.

Who knows? That's what keeps the influx of new miners after all.

Once seasoned folks decide to cash out it's very much becoming a Ponzi scheme. Well someone gotta profit on all that swarm of people throwing thousands of fiat currency into GPUs and BTC. Anyway, unlike Ponzi schemes that would not be the end of it all. It's like evolution you know   Nobrainers deserve their fate.

You are kinda wrong on this. While typically the 2xsha256 kernel could require as few as 4 bytes of __global (video) memory to store kernel results, you are likely utilizing much more than that. The kernel code is initially placed in the video memory and most modern AMD GPUs have just 48KB worth of instruction cache (this might be different on Cayman as far as size is concerned, haven't checked). Any bitcoin kernel binary takes more than 100KB and naturally does not fit there and this leads to performance degradation the bigger kernel size is. This is also beyond what profilers like sprofile can show you.

Don't think so, but anyway I should check this possibility. Definitely though 2.1 would crash.

You need 2.3 or above, sorry. It also works on 2.2, but speeds are not optimal.

What SDK version you use?

Nope, there is nothing that can be done in that case and it's a matter of luck. You will see higher stale percentage on "shorter" blocks and lower stale percentage on "longer blocks".

Yeah, that's expected then, they have no long polling support. When block is solved there is no mechanism to inform you about that and hashkill is still working on a stale getwork (then eventually submits a share that is stale already). mining.bitcoin.cz does not "punish" you for submitting stales though (at least to my knowledge).

Does your pool support long polling?

I think those are not related. Besides, hashkill does the BFI_INT replacement as well.


Probably hashkill-gpu < /dev/zero instead?

Have a look at this:

http://developer.amd.com/support/KnowledgeBase/Lists/KnowledgeBase/DispForm.aspx?ID=19

I am running hashkill via ssh. No logged gnome user required. Also no local console logins needed.

Hmpf, that should have been resolved already. You are sure you ran install.sh with root privs?



That would be nice...but what exactly are we going to configure that is hard to configure via command-line?


Right now there is such mechanism, but it's like read-only...you can have a look at the ~/.hashkill/bitcoin.json. It exports hash speed and etc stuff in json format. It sucks though and definitely it would be good to control it remotely.


This is a very bad idea. Tried doing that in the past. The end result being something that works good on one system and goes crazy on another (well I guess that's what the whole GPU programming is about anyway). Overall I am not inclined


This is an interesting idea that never occured to me before. Worth trying.


I guess -D and -G work that way. -D -G4 is rather aggressive while just -G1 is the most responsive.

If the bubble bursts, the market would be flooded with cheap GPUs so you are not likely to sell it at the price you expected (not even sell it).

Default thermal throttling value is 90C and there should be a warning displayed about that. I will investigate that GPU dropping issue as I haven't reproduced it yet.

Lowering mem clock should not affect performance as we use just 4 bytes of video memory. I can experiment with that though since we're also able to use host-accessible memory for that. However, since I use my machines for hash cracking too (where a lot more video memory is required) I can't afford to flash my GPU bios and extremely underclock memory just for testing.

No worries, market will be flooded soon with cheap second-hand GPUs used for mining.