This has been debated before, but is one any better than the other? I've always just used ethproxy. With about 120 MHS would I benefit from using QtMiner?
@SIRacer09 I ran both eth-proxy and qtminer side-by-side and found no measurable difference, although I run an eth-proxy per rig, not one central proxy. For me, qtminer's lack of failover, and the way it regenerates the DAG, are large negatives.
@dr_pra I've noticed a difference since you upgraded your geth and stratum backend, I've noticed a positive difference on the pool today! The max credits to get a block seems to have come down a good bit. I would imagine that's an indication of fewer uncles? In any case, it looks very good from my end! Thanks!
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.
@dr_pra Massive difference in stability since the recent change. Rigs used to reconnect to stratum at least a few times a day, now they haven't dropped off once.
@work@dr_pra yes, connection is much more stable, but I see a small uptick in invalid shares on SOME, but not all rigs. Because the connection is stable, then total number of invalids might be higher, but out of many more submitted. What is the source of invalid shares? How to reduce them at the miner level? Are the errors the result of the client/server interaction, or purely miner?
@work@dr_pra yes, connection is much more stable, but I see a small uptick in invalid shares on SOME, but not all rigs. Because the connection is stable, then total number of invalids might be higher, but out of many more submitted. What is the source of invalid shares? How to reduce them at the miner level? Are the errors the result of the client/server interaction, or purely miner?
I wonder this too. I'm getting ~3% rejected shares, but I've never seen a bad GPU result. On MiningPoolHub I don't seem to get any rejected shares.
@work 3% invalid rate seems high. Here are my invalid percentages. The rig for the first entry was recently restarted, but its percentage is inline with all the rest:
Invalid shares are always an indicator of an issue with your local miner. An invalid share is a share which has an difficulty lower than the pool share target difficulty.
I believe most of the invalid shares are from when the GPU finds a solution to the previous work after the pool already pushes new work to the mining client. Ethminer has a check in place that will make sure that the solution to previous work isn't submitted to the server; however, qtminer doesn't have such a check in place and submits all found solutions. Thus, theoretically, there shouldn't be a difference in the number of valid shares submitted whether you use ethminer or qtminer. If you use qtminer, you'll be able to see the statistics of how many valid/invalid shares you have, whereas with ethminer, you won't.
If this is the case for most of the invalid shares, then I believe a possible solution to this problem is to use a smaller value for the global-work size, since once given work, the GPU will finish processing all items in the global-work group. Thoughts?
@caesar0901 Funny you mention global-work size. I have posted several times about global and local work size and how they influence the runtime of the kernel, but no one seems to care that the values they use results in kernel times approaching 200 ms, sometimes even more. I have found that a 40 ms kernel time gives me the best raw hash rate *and* the best submitted work hash rate. It's not all about your GPU hash rate, which is what everyone seems to be obsessed about. I get NO rejects (just check a months worth of logs on 18 rigs) and my GPU error rate is .5% - .75%.
On a related issue, I've noticed that the GPU error rate (# GPU errors/# results found), is noticeably higher for my 6 GPU rigs than the one single GPU and one 3 GPU rigs I have. The single GPU has virtually no GPU errors, the 3 GPU rig has < .3%, while the 6 GPU rigs have the values I gave above.
@hasher For my rigs, with 26.2 MH/s raw rates per GPU, I set global work to 16384. I don't change local-work. This gives me kernel runtimes of 39-40 ms. If you have a lower raw hash rate, you would use a smaller global-work value. If you leave global and local work as default (4096 and 64, respectively), with a 25 MH/s hash rate, the kernel runs 10.8 ms.
Something is definitely changed because I have frequent "Waiting for work..." messages. And this is happening only in the last few days. All my rigs are showing smaller Effective hashrate compared to Reported hashrate.
@dlehenky So my buddy and I put together a rig with 2 R9 280x, 3 7950s and 1 R7 370. I have another rig with just 1 R7 370. Does that mean I should be running global and local work as default (4096 and 64) on both my rigs since only 2 GPUs out of all of them do about 25 MH/s?
@work Hmmm didn't know I could do that. Since I have three different card types... R9 280x, 7950, and R7 370 in the same rig, would I benefit from running 3 instances of ethminer, each with their various local and global settings?
@SIRacer09 I don't know about R7 370-did not mine with those yet (they are coming), but for both 280X and 7950 local work 128, global work 8192 seems to work fine on qtminer without running multiple ethminer instances.
Comments
With qtminer: Waiting for work packet.. and headerhash only zero's...
p.s Actually it did make 000...0 dag but still working with no hiccups, will see.
What is the source of invalid shares? How to reduce them at the miner level? Are the errors the result of the client/server interaction, or purely miner?
@work 3% invalid rate seems high. Here are my invalid percentages. The rig for the first entry was recently restarted, but its percentage is inline with all the rest:
If this is the case for most of the invalid shares, then I believe a possible solution to this problem is to use a smaller value for the global-work size, since once given work, the GPU will finish processing all items in the global-work group. Thoughts?
On a related issue, I've noticed that the GPU error rate (# GPU errors/# results found), is noticeably higher for my 6 GPU rigs than the one single GPU and one 3 GPU rigs I have. The single GPU has virtually no GPU errors, the 3 GPU rig has < .3%, while the 6 GPU rigs have the values I gave above.
Edit: Using qtminer on both eu1 and us1 servers
Constant "Waiting for work...", about 10-15 seconds every 10-30 minutes.
Miners are on qtminer.
I don't know about R7 370-did not mine with those yet (they are coming), but for both 280X and 7950 local work 128, global work 8192 seems to work fine on qtminer without running multiple ethminer instances.
Not sure how frequently, but can confirm it's still happening as of ~10min ago using US2 server