Update: Added dedicated getwork thread, now only gets new work once per 5 seconds instead of 3 times per gpu per 5 seconds.
This should improve performance on miner pools due to remote connection latency, and it should also improve performance on setups that have many miners connecting to a single LAN bitcoind.
Another update: Added -g/--getwork to change the number of seconds between getwork refresh, should help high pool latency issues, default remains 5.
Another another update: the sh scripts now set an environment variable that fixes SDK 2.2 and 2.3 CPU time usage. I still recommend 2.1, but at least it doesn't go apeshit anymore.
Topic: DiabloMiner GPU Miner - page 83. (Read 866206 times)
True, my bad, a typo.
By the way, clocking core from 700MHz to 850MHz looks stable and you can get quite a bump in performance, 140 mhash/sec right now
By the way, clocking core from 700MHz to 850MHz looks stable and you can get quite a bump in performance, 140 mhash/sec right now
$ ./DiabloMiner-Linux.sh -u lolzuser -p mehpw -w 64
[12/15/10 6:39:36 PM] Started
[12/15/10 6:39:42 PM] Added Juniper (#1) (9 CU, local work size of 64)
111224 khash/sec
Listed as Juniper, it's a Radeon HD 4750.
[12/15/10 6:39:36 PM] Started
[12/15/10 6:39:42 PM] Added Juniper (#1) (9 CU, local work size of 64)
111224 khash/sec
Listed as Juniper, it's a Radeon HD 4750.
Thats a 5750, actually. 5750s do about 116 mhash/sec and are Junipers.
$ ./DiabloMiner-Linux.sh -u lolzuser -p mehpw -w 64
[12/15/10 6:39:36 PM] Started
[12/15/10 6:39:42 PM] Added Juniper (#1) (9 CU, local work size of 64)
111224 khash/sec
Listed as Juniper, it's a Radeon HD 4750.
[12/15/10 6:39:36 PM] Started
[12/15/10 6:39:42 PM] Added Juniper (#1) (9 CU, local work size of 64)
111224 khash/sec
Listed as Juniper, it's a Radeon HD 4750.
That usually indicates a fault in the OS somewhere. Since no one gives a shit about OpenCL on OSX (not even Apple), I'm not sure what to tell you. Any other OSX users want to chime in?
Hi Diablo, just catching up from IRC on my osx experience.
This works great… but it seems to generally freeze the machine after a few minutes. Cursor is mobile and I was able to ssh in last time. The java process was no longer running when I sshed in. I'd like to help figure out ways to improve the stability. Any ideas?
Code:
511 pyramid:~/Projects/DiabloMiner$ ./DiabloMiner-OSX.sh -u jcw9 -p notarealpasswordfolks -w 64
[12/14/10 2:56:50 PM] Started
[12/14/10 2:56:59 PM] Added ATI Radeon HD 5750 (#1) (10 CU, local work size of 64)
49951 khash/sec
This works great… but it seems to generally freeze the machine after a few minutes. Cursor is mobile and I was able to ssh in last time. The java process was no longer running when I sshed in. I'd like to help figure out ways to improve the stability. Any ideas?
H == 0 is checked for every nonce... m0's does H == 0 and G <= target in the kernel for every nonce, and pays a slight speed penalty for it. So, if I check H <= target, I will pay a similar speed penalty.
Well, in fact, there are two different problems:
1. Allow small targets - under 32 bits (H > 0)
2. Perform full checking before send work back to bitcoin to save server resources.
ad 1)
I think it could be easy for every nonce to not compare H == 0, but H <= constant, where constant is pre-counted for every work from bitcoin. It should be easy and safe enough to pick last 32 bits from target and convert to this constant.
ad 2)
Full checking is not performed for every nonce, but only when H <= constant is found. So it does not slow down computing (as it is performed only for hashes which already passed first check), but save resources for server
Quote
Edit: Also, you have to check the full hash on your side anyhow when you submit it to your bitcoind via getwork. It will reject it if its wrong (returns false).
Yes, I'm checking result of bitcoin's getwork() to obtain if block was found. My own checking is against low target to counting worker's shares.
Except you misunderstood what I said about 2. I _already_ fully check the hash, from scratch, using the full 80 bytes of header just to make sure its correct. However, _you must also check this_ as you cannot accept user input as valid. It would take me three seconds to screw over the entire pool once it gets going.
Also, re: 1. See how m0's kernel does it? He has a kernel arg named target, and the kernel does G <= target. This is exactly the same thing as doing H <= target, I would code it exactly this way. GPU hardware can check if something == 0 much faster than <=.
The only reason I would add this code is if, eventually, testnet difficulty dramatically drops again and this would need to be ready before hand.
H == 0 is checked for every nonce... m0's does H == 0 and G <= target in the kernel for every nonce, and pays a slight speed penalty for it. So, if I check H <= target, I will pay a similar speed penalty.
Well, in fact, there are two different problems:
1. Allow small targets - under 32 bits (H > 0)
2. Perform full checking before send work back to bitcoin to save server resources.
ad 1)
I think it could be easy for every nonce to not compare H == 0, but H <= constant, where constant is pre-counted for every work from bitcoin. It should be easy and safe enough to pick last 32 bits from target and convert to this constant.
ad 2)
Full checking is not performed for every nonce, but only when H <= constant is found. So it does not slow down computing (as it is performed only for hashes which already passed first check), but save resources for server
Quote
Edit: Also, you have to check the full hash on your side anyhow when you submit it to your bitcoind via getwork. It will reject it if its wrong (returns false).
Yes, I'm checking result of bitcoin's getwork() to obtain if block was found. My own checking is against low target to counting worker's shares.
[13.12.10 07:10:53] Started
[13.12.10 07:10:53] ERROR: No OpenCL platforms found.
Some more bruteforcing and I seem to be a little closer. Trying on Win7 x64, with ATI 5870. I just installed the ATI stream SDK v2.2 and I see to be one step closer now. Any idea why it fails to identify the OpenCL drivers?
[13.12.10 07:10:53] ERROR: No OpenCL platforms found.
Some more bruteforcing and I seem to be a little closer. Trying on Win7 x64, with ATI 5870. I just installed the ATI stream SDK v2.2 and I see to be one step closer now. Any idea why it fails to identify the OpenCL drivers?
Try installing the version of Catalyst that includes the the stream runtime already (downloading offers two choices, 10.12 is supposed to eliminate this and always include the runtime).
[13.12.10 07:10:53] Started
[13.12.10 07:10:53] ERROR: No OpenCL platforms found.
Some more bruteforcing and I seem to be a little closer. Trying on Win7 x64, with ATI 5870. I just installed the ATI stream SDK v2.2 and I see to be one step closer now. Any idea why it fails to identify the OpenCL drivers?
[13.12.10 07:10:53] ERROR: No OpenCL platforms found.
Some more bruteforcing and I seem to be a little closer. Trying on Win7 x64, with ATI 5870. I just installed the ATI stream SDK v2.2 and I see to be one step closer now. Any idea why it fails to identify the OpenCL drivers?
H == 0 is checked for every nonce... m0's does H == 0 and G <= target in the kernel for every nonce, and pays a slight speed penalty for it. So, if I check H <= target, I will pay a similar speed penalty.
Edit: Also, you have to check the full hash on your side anyhow when you submit it to your bitcoind via getwork. It will reject it if its wrong (returns false).
Edit: Also, you have to check the full hash on your side anyhow when you submit it to your bitcoind via getwork. It will reject it if its wrong (returns false).
testnet, for the time being, has been > 32 bits. Checking if H <= target (instead of H == 0 and then G <= in the host code) would slow it down. I could add it, but it'd cause complexity that might slow it down for normal users if I do it wrong.
Well, but this check is performed only when possible valid block is found, right? So we are talking about 'slowing down' once per tens of seconds or even minutes for every worker (depends on target and machine speed).
I'm asking that because strict checking on workers are much 'cheaper' than lazy checking on workers and full check on central server. For saving server resources we need to distribute full target checking as much as possible...
Could someone please take the time to write down the steps needed to get this to run on Win7 x64?
Feature request: Please support targets with less than 32bits of zeros
Reason: Miner is not properly working on testnet, where target can be under that. I'm also working on cooperative mining server and would like to introduce small targets for counting shares of every worker. DiabloMiner with correct target handling will be compatible with this mining server...
Thanks!
Reason: Miner is not properly working on testnet, where target can be under that. I'm also working on cooperative mining server and would like to introduce small targets for counting shares of every worker. DiabloMiner with correct target handling will be compatible with this mining server...
Thanks!
testnet, for the time being, has been > 32 bits. Checking if H <= target (instead of H == 0 and then G <= in the host code) would slow it down. I could add it, but it'd cause complexity that might slow it down for normal users if I do it wrong.
How's this vs. all the other mining tools?
Its faster than m0's, which is your only other option.
How's this vs. all the other mining tools?
Feature request: Please support targets with less than 32bits of zeros
Reason: Miner is not properly working on testnet, where target can be under that. I'm also working on cooperative mining server and would like to introduce small targets for counting shares of every worker. DiabloMiner with correct target handling will be compatible with this mining server...
Thanks!
Reason: Miner is not properly working on testnet, where target can be under that. I'm also working on cooperative mining server and would like to introduce small targets for counting shares of every worker. DiabloMiner with correct target handling will be compatible with this mining server...
Thanks!
Update: Made logging output more consistent
Update: Removed -a, it autodetects it now
Hello. I looked through this thread and can't find the download link for this client.
Repost please?
Thank you.
Repost please?
Thank you.
It's in the very first post of the thread, at the top, where it says "Newest binary".
Hello. I looked through this thread and can't find the download link for this client.
Repost please?
Thank you.
Repost please?
Thank you.
Jump to: