|
Update: Reverted global getwork instance work, it was causing more problems than
it was fixing. Increased khash meter accuracy. Removed stuck executor
thread code, this didn't work right and the thread eventually unsticks
itself on applicable platforms anyhow.
|
|
|
|
|
For those wondering, I replied to the bug. OSX hybrid graphics are screwing up OpenCL apps.
|
|
|
|
|
I suggest everyone who uses my miner to upgrade to the newest version, it should fix the final issue with the pool rejecting shares.
|
|
|
|
|
Update: Forced all accesses to a getwork instance to be synchronous, should fix final network thread problems
|
|
|
|
|
Throwing up a dummy xvfb will indeed fix this. ATI users don't have this problem because X has to be running to use OpenCL
|
|
|
|
|
The ELFCLASS32 bug is, unfortunately, inside the AWT code inside Java. lwjgl rams into it because it initializes AWT even if I do not open a window. They are aware of the bug; Oracle has no plans on fixing it on their end (ANY app that tries to init AWT on a system without X running will do this).
|
|
|
|
I restarted service before few minutes because of some compatibility fixes for Diablo's miner. Please check your workers if they didn't crash during update and if so, please update to the latest version of your miner software. Main miners already solved those crashing issues.
Many thanks to RichardG and Delia for correcting and writing better texts for pool site. I will update it soon!
Please note that I'm leaving Internet for few days now. Few people from forum have phone contact to me and in case of pool problems, I can go online and fix it soon.
So, Merry Christmas and Happy Mining!
Your fix isn't. Oh well.  |
|
|
|
Does anybody have a comparison on how Linux against Windows machines are performing when running the GPU miners?
No, but Linux runs faster. |
|
|
|
|
Update: Made the getwork clone from network thread method more paranoid, should help with low difficulty targets like pools and the testnet.
|
|
|
|
I found I kept getting errors when running the miner... I fixed the ELF_CLASS error by deleting the non *64.so libs and renaming them to *.so (just remove the 64!) Then, I got an error about not being able to connect to a screen (it's a headless server); I installed xvfb...ran this; export DISPLAY=:1 Xvfb :1 -screen 0 1024x768x16 & and it worked fine  You didn't have to rename the libs. Setting DISPLAY alone fixes this (as long as you have an X server running). |
|
|
|
|
For those using my miner, I've made enhancements that should increase performance with pools.
It now uses a dedicated thread to manage getwork so it won't block kernel execution threads. I've also added an argument (-g/--getwork) to set the number of seconds between automatic getwork refreshes (pool users may want to increase this if they get a lot of network failures).
The first change should positively effect miner performance for people on high latency connections.
|
|
|
|
|
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.
|
|
|
|
$ ./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.
Thats a 5750, actually. 5750s do about 116 mhash/sec and are Junipers. |
|
|
|
|
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?
|
|
|
|
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 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. |
|
|
|
[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?
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). |
|
|
|
|
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).
|
|
|
|
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!
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. |
|
|
|
|
Update: Made logging output more consistent
|
|
|
|
|
Update: Removed -a, it autodetects it now
|
|
|
|
|
Show Posts
