Topic: hashkill - testing bitcoin miner plugin - page 17. (Read 90911 times)

Very nice work!  Seeing 365-370MH/s on my 5870!

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.

Still seems to have a somewhat high rate of stale shares (as reported in the deepbit stats), but only about 1.5% compared with the 10% last time I tried it.  Does report the new long polling blocks properly now.

As far as the whole untrusted code thing goes I have just been running it in a sandbox (the same as when testing other miners, open source doesn't necessarily matter if I don't have the time to look through it properly), no access to home directory, read access to standard system libs, write access to /dev/ati and /tmp and I can remap accesses to /usr/share/hashkill to something under the working directory.  Still have to trust code somewhat but it would stop any basic wallet-stealing (as well as reporting that it was tried).

maybe try it in one of the /hashkill subdirectories?

BTW, i tried running it as sudo - it said no such program as 'export'.

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

hmm...  how do i do that?

i tried running "export GPU_DUMP_DEVICE_KERNEL=3" (also 1 and 0) in tmp - but no isa file magically appeared.  i also tried while hashkill was running.

what am i doing wrong?

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.

been running non-stop on slush since my last post.  no real issues.

efficiency is down a touch - steady at 98-99%.

the 'stale' counter is session-additive, right?  it's up to 139.

Mhash/sec holding rock-solid at 173.  no variance at all.

if you'd like any generated logs or anything, let me know, gat3way.

 

per my previous post:


i'm now running the latest version (still called 0.2.4-x86_64) on slush's pool.  173 Mhash/sec like a heartbeat.  efficiency at or above 100%.

a winner!

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.

The whole 'root install' thing really doesn't matter.  Look at the install.sh script.  It's using root privs to copy files into /usr/bin and /usr/share/hashkill.  None of those files are setuid/gid.  When you actually execute the files, you are executing them (unless you are being silly and running hashkill as root or with sudo) with an unprivileged user account.  At that point, your risks are the same as if you ran a binary from your home directory.

Now, open code is a different story....

thank you, gat3way.

i'll install tonight and let you know.

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!

Okay I can appreciate an argument like this ... if you tearing through a development stage things are flying everywhere and its easier to spit out binaries ... good on ya, poclbm and phoenix are tough competition.

In this case, it is probably best for people who want to test with this code to do it on a dedicated test rig or VM maybe, but not a production mining rig of a cluster or one with a real currency at stake or in the environment anyway.

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.

I think that a non-root user could create a chroot system to install and use it anyway, so I suppose this is not a valid concern.

No conspiracy theory, I think you are probably doing some good work here, it has the right pedigree.

Just it would be bad practice to do what you are asking for people who are testing it ... unless of course they know and can trust you. I'm pretty sure you wouldn't do it yourself, knowing which side of the security fence you come from. Good luck, carry on.

"Here I've got a binary that is a sub-system for your digital currency miner, just use root to install it and you'll be sweet." (Has a bad look, if you know what I mean.)

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.

I can understand this, I have worked with gat3way on testing this over IRC on my 6990 system and 5970 I have also seen the source code. You can also get code for everything but the bitcoin plugin off his website. But I am sure when he is ready he will release the code to the public.

I'm not going to install any binaries with root privileges without seeing the source.

Particularly not one from a hash-cracking expert, that would be a huge security hole, wouldn't you agree? Would you do it?