< 4GB However with PAE you can address more, up to 64GB. Over 8GB you will be suffering badly from the overhead of mapping/unmapping regions in lowmem. Anyway, it really does not matter. For a SSE2 CPU miner, going to 32bit on a 64-bit system would be detrimental as the number of xmm registers is cut by 2. With GPGPU stuff it does not matter.

Opsss......I now see what's the problem. You don't need to run hashkill as root (via sudo). It is only needed for the installation (sudo ./install.sh). Once you are done, you just run hashkill-gpu. You can do export ....; sudo hashkill-gpu or sudo export ... ; sudo hashkill-gpu ... but the environment won't be preserved across those so you won't be getting the ISA dump. So you just have to drop that sudo thing. In fact I really don't recommend running hashkill as superuser - it does no matter at all as far as performance is related and it can run perfectly well without superuser privileges. I tend to minimize the set of root processes running on my system, kind of paranoia from days when I used to be a sysadmin. In fact, running as root can only lead to problems as the root user may not be allowed to make a connection to the X server (on my debian devel host for example I need to explicitly allow this with the xhost command).

Thanks. Is that on stock clocks or OC?

There is in fact benefit in doing that. Context switch overhead is nothing compared to kernel launch and buffer copy one. You are likely to utilize the GPU better. With faster GPUs that makes sense. Also, with NVidia Fermi architecture, concurrent kernel execution is possible which does not bring 2x faster speeds of course but utilizes the GPU resources even better (speedup about 5-10%). That's why I create 2 threads per device in hashkill, each of them with its own context and queue. Speedup is not significant, but still there is one. You can easily check speed difference if you run it with -G 1 (single thread) and -G 2 (two threads per GPU). With my 6870, it's about 3 M/s.

However, for a multithreaded application, this requires a thread-safe OpenCL implementation. Thread-safety is a requirement to OpenCL 1.1 standart which is implemented in SDK 2.3 and above. So with 2.2 and 2.1 your only way is with multiple processes, not multiple threads. In this case, yes, context switches are more expensive.

The 1.5% of stales is not a real concern IMO, I guess it is within acceptable range. It can be improved, but I don't really see significant reason in that  - point is we cannot cancel an already running kernel and if a solution is found in its NDRange, it will be submitted. OK, I can make it not submit it at the end, but still that would only make it look better for users while in fact it does not matter. That said, when using -D chances are that stale number would be higher and that's kinda tradeoff for the higher speed.

Well hm...look for *.isa. /tmp should be writable, that's very strange.

Efficiency can go over 100% or below 100% - it's a matter of luck. I've had some periods where it is way over 100%, also periods where it drops at 70-80%. Overall with time it should get close to 100% though. The stale counter is additive, yes.

BTW could you provide me the ISA dump?

I am mostly interested in the SQ_PGM_RESOURCES:NUM_GPRS field which should be among the last lines.

OK to anyone that needs the source, here it is:

http://www.gat3way.eu/poc/hashkill-src.tgz

Well, at that point I am _not_ providing any support to anyone that has problems building it. Also, I cannot promise that at that point I am going to follow any suggestions, even if they sound very sensible. You'd need to set two environment vairables, ATISTREAMSDKROOT and ADLROOT set to proper paths in order to properly build that.

OK, newer (hopefully last) alpha is ready.

New in that release:

* Fixed the "fflush" problem: now progress is displayed correctly, not updated with a newline
* Better getwork mechanism: smaller granularity for queueing thread, separate "submit" threads meaning that network-related performance loss is reduced
* Fixed long polling - it is now working correctly and the stales number should greatly be reduced on pools that support it. Stales are still possible though cause the current kernel invocation is not being canceled. Chances are about 1/1000. Also, stales are possible due to HTTP latency issues.
* Added thermal statistics: at any time during mining, press ENTER key to get your GPU temperature and utilization stats
* Added thermal throttling: when a GPU reaches a certain temperature limit, it is being disabled for one minute. The temperature threshold is 90 degrees Celsius by default and can be changed via the -T command-line option
* Changed the kernel to use a worksize of 64. It does not reflect on performance but makes speed more "stable"
* Changed the VLIW4 kernel (69xx cards). Now it should be a bit slower, but more stable.

Not added:

* The failover protocol
* HTTP keep-alive
* HTTPS support

Note: Thermal throttling/monitoring work on ATI cards only at the moment. There are corner cases where it would not work (e.g having adapters not supported by OpenCL).


Download:

64-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86_64.tgz

32-bit:
http://www.gat3way.eu/poc/hashkill-0.2.4-x86.tgz


Reminder: use SDK 2.3 or newer!

I am not a firm believer in the theory that opensourcing something would automatically eliminate chances of having deliberately planted malicious code. Its the peer review that eliminate that, not the public source itself (see the underhanded C contest eheh).

Yes, source is the prerequisite, however there is also something else. Hashkill has already turned into a relatively large enough project (~130-140.000 lines of code at present) with a good number of dependencies and supporting all this in my spare time is not easy. I add new functionality faster than I fix bugs (unfortunately as my spare time is limited). This of course reflects on my autoconf/automake stuff (the bitcoin part brought 3 new dependencies - curl, json-c and ADL). Autoconf macros are still buggy and building is a bitch. There are also sometimes some minor API changes in some library that may fail everything. It's just not tested well enough at the moment. I don't feel like answering questions like "build failure XXX, please help" while having to fix some serious issues with the bitcoin code. Static-linked binaries are a nice way to make it working for most distros out there without depending on additional packages and stuff.

One might argue that rewriting everything in a higher-level language like e.g python would be a better idea and I completely agree. It is also much more portable. However it is already too late for this.

Root privileges are needed only for the installation and the installer script is apparently open source. Then yes - it's a question whether you trust binaries and it is a valid point. Then again, you already do that as the whole OpenCL stack is proprietary. So at the end it boils down to whom you trust to provide you binaries. Of course, in theory I could trojanize you, I could put your system in an evil botnet whose aim is to (say hm) generate bitcoins for me. Not that this wouldn't show up in a simple strace output for example, but then not anyone would bother to check that. Well, it's obvious I can't give you guarantees on that and it's all a matter of trust. Of course, I can make claims as much as I want, but apparently it does not matter.

Until I can get it to a point where I consider it stable enough, I am not putting the code in public. That is my personal choice and I have the right to do that just as you have the right to build some conspiracy theory around that. Source is available upon request though and I would not refuse to provide this to anyone that tests it. However, I am not willing to release it in public at that moment. It will be released soon, but only after I eliminate the present issues and integrate the functionality I've planned.

Users for the hash cracking part requested that on a number of occasions. The reason I am not reluctant to do this is that it creates a possible security problem. The architecture consists of a core binary (hashkill-gpu) and a number of plugins that are in fact shared libraries  (/usr/share/hashkill/plugins) and are loaded dynamically. Having the libraries located in a path that is only writable by root ensures noone can play nasty tricks. If I let the users install them wherever they want, someone might install them in a world-writable directory. This creates a security hole because anyone that can overwrite files there, can take advantage of that to mount local privilege escalation attacks. Besides (from the hash cracking perspective) I don't feel comfortable with the idea that anyone can install the program to crack hashes, without superuser knowledge. So - if you are the owner of the machine - you will install that anyway. If you are an ordinary user and you really need that, you can ask the admin to install it. I am not letting users to crack hashes on a system they don't have permission to. It is resource-intensive process and it may be related to illicit activities.

It overwrites, no need to delete.

OK think I fixed the "fflush" problem. Also managed to integrate the ADL part: now we have some nice statistics about GPU temperature and utilization when you press ENTER key:



There is a user-defined temperature threshold (default:90) that causes the miner to disable the particular overheating GPU for 1 minute when reached. I guess better idea would be to increase fan speed (perfectly possible) but haven't done that yet.

getwork mechanism also improved for faster cards - well, unless you have >2.4GH/s total compute power  

The ADL monitoring does not depend on any new libraries, it's part of the Catalyst driver suite.

Need some more testing, will release it soon.

Yep, -D is indeed less stable. A very slight variance in desktop usage (e.g minimizing a window) can decrease performance a lot for some interval of time. It's just too flaky for normal desktop usage. This should be used only on dedicated systems.

@bolapara, with -G4 you are too much dependant on CPU and memory. With systems with multicore CPUs and lots of RAM that's OK, but I guess you'd be better off if you provide -G 2 (or no -G at all). -G4 requires about 700 MB of system memory on a single-GPU system and probably about 1GB with dual-GPU ones (sigh) and if you don't have them free, you can get into swap and generally fuck up overall performance quite a lot

Also, with -G4 it takes more time until all threads kick in and initial kernel compilation time is much slower as well. So you are likely to see peak results after ~20-30 seconds or even more with multi-GPU systems.

As a general rule, I'd advise you to stay off turning -G option (unless you are nvidia user with newer drivers where -G2 helps a lot). It has a significant meaning with some "fast" hash cracking plugins (e.g mysql-old), but it does not bring much benefits with bitcoin. You are likely just increasing your overall power consumption without any benefit.

Yep, this is another thing I need to get done - with faster systems, the keyspace is exhausted faster than we can fetch getwork()'s. I have to perfect the queueing mechanism a bit. Noticed that while testing with 6990.

As a workaround, you can run separate instances against different devices by setting the COMPUTE environment variable to get best performance until I fix that.

Never tried it solo in fact. Should test. -D option brings higher speed at the cost of less responsive desktop. The infinite progress indicator issue will be fixed soon, looks like I've forgotten to flush stdout

OK, could you please run export GPU_DUMP_DEVICE_KERNEL=3, run hashkill on 5770 for  30-40 seconds and give me the bitcoin_Juniper.isa file generated? This way I can have a look if there is a replacement issue.

@bolapara: did you use the -D option?

We just tried hashkill on 5970 (which has the same cores as 5870) and speed was as expected: 620-630M/s at stock speeds. That is with -D applied

@mskwik The stale shares could indicate a problem (e.g bad BFI_INT replacement). What GPU do you have?


As a side note, I got ADL working and I can now correctly get GPU temperatures, activity percent and clocks. Wondering how to proceed with that thermal stuff: should I quit when a threshold is reached....or probably pause for a certain period....or completely disabling that GPU? Hmm...