@Ara re: 0 H/s in log output. It means your kernel is running longer than the 200 ms reporting window. Try running it without '--cl-local-work' on that rig and see what you get.
@o0ragman0o My GTX Rig is a hackintosh, all the cudaMiner stuff I could find is compiled binaries for Windows. Anyone have a link to the CUDAMiner source so I can build for OSX? @Genoil ?
@Ara eth mining on Windows+Nvidia is best done on win7/8 or by downgrading drivers. Your hashrate could be around 12MH/s. AFAIK nobody has successfully built my fork on OSX.
True, if on 10.11.x El Cap. I think it can (or was) able to be done on 10.10 Yosemite, but I don't have an install to try it on. On El Cap there are llvm/c++11 and linker errors all over the place, I've tried several things and only gotten to about 95-98% when "uncorrectable" errors enter in. Similar but fewer issues have cropped up compiling on linux (ubuntu), but @Genoil develops on Windows (.NET/VB?) and the source is a bit too tied to that environment.
That said, the homebrew cpp-ethereum install can be used, but the Apple Radeon drivers are mostly the problem (I think), because hashrate is much, much lower on MacOS X & AMD cards than using Genoil's miner with OpenCL on Windows (which I'm successfully doing on a Mac Pro with bootcamp)...
Thanks @Genoil I'll give it a shot, or perhaps I'll run docker or VMWare Fusion and have GPU acceleration turned on and see if it works. For my main rig ( r9 380 ) I'm seriously thinking of switching out linux for windows, as much as I hate to have to do that it seems the most supported by the ethereum community and drivers do seem to work better there. Thanks again all.
@dr_pra Something happen in the last hour? All my eth-proxy miners went offline at the same time, 16:06 on your site. I can't access their terminals just yet to see if it's rpc errors or not....
What does "poll-free" mining mean? All Ethereum clients currently do not provide a way to push new work to a mining backend when a new block arrives. The only official method is to use the "getWork" RPC call and to continuously check for new work at a fixed interval (e.g. 200ms). But this means that you will potentially mine up to 200ms on an old block. Setting the polling interval to a lower value like 10ms does work but will put a lot of stress on the underlying node as well as the mining backend.
We now have patched our Ethereum node to immediately inform the mining backend when new work becomes available. This means we were able to reduce the potential time we mine on an old block from ~200ms to less than 1ms and at the same time reduce the stress we put on our nodes by eliminating the need for continuous RPC calls.
This method should, in theory, allow us to decrease the pools uncle rates even further.
@dr_pra Is something going on again with the stats? All of my rigs are mining and submitting shares, but the reported effective current hashrate is less than half of what it should be. ???
I have 3 rigs on your pool, 2 on windows and 1 on Linux. The Linux one doesn't show shares, but I know it's hashing because it gives 'solution found' and the per round amount goes up. I would like to see shares however, so I was wondering if it could be a problem on your end or if it must be on my end?
@dr_pra Yeah, I think it was actually on my end -- I believe my internet service actually went down for a short period of time in the early morning hours. Ugh. Not much anyone can do about that.
Small update. I deleted all dags and now i think is ok. Also the qtmienr didnt generate the 000000...0 dag this time as it was before. So I suggest everybody delete your dags and check if its working now without hiccups.
p.s. Actually it did make 000...0 dag but still working with no hiccups, will see.
Comments
That said, the homebrew cpp-ethereum install can be used, but the Apple Radeon drivers are mostly the problem (I think), because hashrate is much, much lower on MacOS X & AMD cards than using Genoil's miner with OpenCL on Windows (which I'm successfully doing on a Mac Pro with bootcamp)...
Thanks.
BTW you have not answered my query about invalid shares.
What does "poll-free" mining mean? All Ethereum clients currently do not provide a way to push new work to a mining backend when a new block arrives. The only official method is to use the "getWork" RPC call and to continuously check for new work at a fixed interval (e.g. 200ms). But this means that you will potentially mine up to 200ms on an old block. Setting the polling interval to a lower value like 10ms does work but will put a lot of stress on the underlying node as well as the mining backend.
We now have patched our Ethereum node to immediately inform the mining backend when new work becomes available. This means we were able to reduce the potential time we mine on an old block from ~200ms to less than 1ms and at the same time reduce the stress we put on our nodes by eliminating the need for continuous RPC calls.
This method should, in theory, allow us to decrease the pools uncle rates even further.
I have 3 rigs on your pool, 2 on windows and 1 on Linux. The Linux one doesn't show shares, but I know it's hashing because it gives 'solution found' and the per round amount goes up. I would like to see shares however, so I was wondering if it could be a problem on your end or if it must be on my end?
https://i1.someimage.com/w0s3vUc.png
Every 15-20 minutes my rigs are waiting for a half a min with now work. I notice it becase the fan of gpu are slowing down and the noise is lowering.
Using qtminer.
p.s. Actually it did make 000...0 dag but still working with no hiccups, will see.