Sigh, -s did not work as well as I had hoped, and now it is gone. There goes my 99.1% efficiency, back to 95% I go.

I've updated the mhash counter code to average over 30 seconds, and I've also added executor lockup detection (which should never happen, but apparently does on really fubar machines).

Fixing it to work on satoshi's getwork impl is still on my todo list.

Also, for those having the lwjgl ELFCLASS32 bug on Ubuntu x86-64, I've discovered the fix: your DISPLAY is unset because you're running it headless over ssh. Do export DISPLAY=:0 before running and it should work fine now.

Not yet, still gotta use m0's version instead.

It would be immensely useful if you'd return if what I sent to the client actually was an actual hit. It makes it easier to debug issues in miners due to sanity checking.

As a side note, do not try -s on Radeon 5xxx. It is slower, and it can also lead to random segfaults because I think I'm hitting a bug in the driver.

Now, as for the gigantic hash problem is, the hash counter is increased every time a kernel is queued... if the kernel fails to queue (which I just added detection of in the build I just pushed out), it would still increase the hash counter. Now, it quits and bitches.

UukGoblin on IRC found a slight tiny bug in the new code I wrote for split, so I just fixed that, it effected people not using split. This should cure some of the problems some of you were having.

So, everyone upgrade and see if you're still experiencing bugs.

Something is not working right here on your machine. There is no way you should be getting above 94 mhash. What do you get with mine with split not enabled?

Also, yes, -s completely destroys desktop interactivity. Try using -f 240 on top of that until I commit a change to implicitly do that with -s (4xxx needs -f 120 to begin to operate normally without destroying desktop interactivity)

Satoshi, please fix your implementation of getwork so it complies with m0mchill's specification

Update: added Radeon 4xxx mode that splits the OpenCL kernel payload in half... use -s. I am now 99.1% efficient on Radeon 4xxx hardware.

Update: You no longer have to edit the OpenCL to enable the bitalign hack for SDK 2.1 and Radeon 5xxx anymore: just start the program with -a

There is a small problem, slush: I wasn't aware Ions supported OpenCL at all. -w and -v should only be used by people who know what they're doing. -w 1024 is too high for any platform I've seen, and the nvidia driver should reject it.

43 ghash/sec sounds like the miner isn't running at all, which I'm not sure how my app arrived at such a point if Nvidia's drivers are written correctly... which, its Nvidia, when have they ever written anything correctly.

Updated miner. As mentioned in updated op, on ATI 2.1 + 10.10 (which is slower than 10.9), using -w 64 -v 1 (not -v 2), I get almost 75 mhash on my Radeon 4850 which gives me above 95% estimated efficiency; using only 1% CPU in the miner and 0% CPU in X.

Oh, and as a side note, it does not automatically detect Radeon 5xxx on SDK 2.1; for the time being, you have to edit DiabloMiner.cl in the jar, comment the first line and uncomment the second and third lines. This is not required for SDK 2.2.

So, I just installed Cat 10.10... on my miner, -w 64 -v 2 is no longer optimal... -w 256 -v 1 is, and my speed is lower than it should be (about 66 mhash vs 70). So, they improved one issue (-v 2 should not have been performing better than -v 1), but got worse somewhere else. Bleh.

That doesn't make any sense because it will just overwrite the entire error a second later. The error is supposed to be part of the ongoing log.

Not only that, I don't know if the exception is JSON or an actual error due to how I hand the exception down, which is actually the correct behavior for designing such an app; you're trying to fix it in the wrong spot. What you really want to suggest is getting the message out of the JSON and then handing that down, which CAN be done.

I'm still. however, not changing the log behavior, this is exactly the way it should work in ANY app designed like this.

Thats not something that can be fixed usefully, consoles don't work that way without heavy manipulation (such as using curses). Bitcoin does not output a JSON message if it is not connected, it only says that it can't connect, and I'm not going to remove the JSON output when it DOES connect and fail because it is a useful debugging tool.

Ahh, well I can't help you there. I bet OpenGL apps don't work with Remote Desktop either. Just because its not opening a window doesn't mean my miner isn't using your video card. Same way on Linux, to use OpenCL, you have to have X running.

Nvidia is out of their minds then. Send a bug report to them demanding OpenCL 1.1 support. AMD has already had it for around 6 months, there is no reason why Nvidia can't. This is absurd.

I suspect that their Windows driver is broken then. Nvidia is advertising OpenCL 1.1 support in these beta drivers, yet it lacks it. You should just go buy a AMD card instead, you'll get several times more mhash anyhow.

Yes, but since I'm on 6, I'd have to install 5 to build jars that work on 5, and I'm not going to do that. 6 has performance increases that make it worth using (same way as 7 over 6 when 7 finally ships).

There is no reason to still be using Java 5 six years after it came out. Either upgrade to 6, or build your own copy.

See that Github link in the op post?

It does. That error (which only appears on Windows that specific way; on every other OS it is a less scary normal exception) means your Nvidia driver is too out of date; Nvidia is lagging on OpenCL support (I suspect they will be filing for bankruptcy in the next 2-3 years).


I do not recommend using a 32-bit JVM on a 64-bit Windows. Many apps break due to poor design in Windows. That error, however, is more Nvidia-can't-code problems.