ethpool.org - Predictable solo mining pool

1171820222326

Comments

  • SIRacer09SIRacer09 Member Posts: 246 ✭✭
    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?
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    @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.
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    @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!
  • MinerEdMinerEd Member Posts: 3
    @dr_pra I seem to have the same problem as mentioned here: https://forum.ethereum.org/discussion/comment/27678/#Comment_27678
    With qtminer: Waiting for work packet.. and headerhash only zero's...
  • crsminercrsminer Member Posts: 75
    MinerEd said:

    @dr_pra I seem to have the same problem as mentioned here: https://forum.ethereum.org/discussion/comment/27678/#Comment_27678
    With qtminer: Waiting for work packet.. and headerhash only zero's...

    Me too
  • zorvalthzorvalth Member Posts: 174
    edited March 2016
    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.
  • workwork Member Posts: 2,084 ✭✭✭✭
    @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.
  • BiodomBiodom Member Posts: 693 ✭✭✭
    edited March 2016
    @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?
  • workwork Member Posts: 2,084 ✭✭✭✭
    Biodom said:

    @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.
  • MrYukonCMrYukonC Member Posts: 627 ✭✭✭
    edited March 2016
    @Biodom

    @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:
    0  / 102  / 0.0%	
    23 / 3669 / 0.6%	
    13 / 3404 / 0.4%	
    2  / 918  / 0.2%	
    14 / 2588 / 0.5%	
    19 / 2672 / 0.7%	
    2  / 866  / 0.2%	
    16 / 2813 / 0.6%	
    0  / 466  / 0.0%	
    20 / 2645 / 0.8%
    Post edited by MrYukonC on
  • workwork Member Posts: 2,084 ✭✭✭✭
    @MrYukonC which server? I'm on us2
  • MrYukonCMrYukonC Member Posts: 627 ✭✭✭
    @work us1 with qtminer.
  • dr_pradr_pra Member Posts: 445 ✭✭✭
    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.
  • workwork Member Posts: 2,084 ✭✭✭✭
    @dr_pra the shares pass CPU validation tho... and I get 0% rejected on another pool.
  • caesar0901caesar0901 NYCMember Posts: 18
    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?
  • dr_pradr_pra Member Posts: 445 ✭✭✭
    @work please create a support ticket, otherwise it is impossibel to support your issue as I don't know your mining address
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    edited March 2016
    @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.
  • hasherhasher Member Posts: 642 ✭✭✭
    @dlehenky care to share some optimal global and local work size settings then? I'm all ears..
  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    edited March 2016
    @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.
  • crsminercrsminer Member Posts: 75
    edited March 2016
    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.

    Edit: Using qtminer on both eu1 and us1 servers
  • dr_pradr_pra Member Posts: 445 ✭✭✭
    @crsminer this issue should now be resolved.
  • SIRacer09SIRacer09 Member Posts: 246 ✭✭
    @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?
  • crsminercrsminer Member Posts: 75
    @dr_pra Look, this is what I am talking about:





    Constant "Waiting for work...", about 10-15 seconds every 10-30 minutes.
    Miners are on qtminer.

  • dlehenkydlehenky Member Posts: 2,249 ✭✭✭✭
    @SIRacer09 The number of GPUs you are running has nothing to do with your global and local work value, since they apply to each GPU, individually.
  • SIRacer09SIRacer09 Member Posts: 246 ✭✭
    edited March 2016
    @dlehenky Correct. I only have 2 of the GPUs that hit the 25 MH/s mark. Should I use the defaults since you can't set the local and global per gpu?
  • workwork Member Posts: 2,084 ✭✭✭✭
    edited March 2016
    @SIRacer09 or you could run 2 instances of ethminer, one for each GPU. Genoil's branch supports device selection.
  • SIRacer09SIRacer09 Member Posts: 246 ✭✭
    @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?
  • workwork Member Posts: 2,084 ✭✭✭✭
    @SIRacer09 I can't speak to how much better it will be, but it's possible and might be worth trying.
  • BiodomBiodom Member Posts: 693 ✭✭✭
    edited March 2016
    @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.
  • LogicaluserLogicaluser Member Posts: 214 ✭✭
    @dr_pra I've also experienced the same as @crsminer with the 10-30sec of 'waiting for work package' on occasion.

    Not sure how frequently, but can confirm it's still happening as of ~10min ago using US2 server
Sign In or Register to comment.