At home page they stated: "We support stratum enabled miners - please use dcr.coinmine.pl:2222 to have much lower rejects" Maybe will be some help to you. Anyway I switched to solo mining and today is happy day: solved solo block and this was block #2 since I'm solo mining. #1 was also solved last monday, mondays are happy days for me.
Anyone watch the round statistics for block 22537? Found with "actual shares 8" and "percentage 0.0". Find the mistake...
Lots of rejects since half an hour, like 25-50%. Nothing changed on my side. @feeleep Still alive? Please check also PM. I think the pool has a serious misconfiguration with shares/rewards. Not just the bogus front-end stats but the actual rewards for each block.
Okay, now coinmine found a block with 1 share. Block 23171. Finder "estebun961". Obviously estebun961 should have received the entire block reward (minus 1% fee). No other miner in the pool should have received any reward for this block. However when you navigate to round statistics for block 23171, you will see that a total of 305 miners have received rewards for this particular block (pretty much all in the pool I guess), with miner "estebun961" getting just 0.01461608 DCR. Don't get fooled by the "round shares" and "round %" in that statistics because it is bogus and always has been on coinmine (I reported this to @feeleep back in February) . But the received reward in the column "amount" is correct because it fits to the data shown under "transactions". I noticed this obvious misconfiguration which affects the mining rewards of all miners two days ago. Block 22537 was found with 8 shares and a total of 296 miners received payments for it. Obviously that's not how it should be, since it was likely only one or two miners that have contributed shares to that block.
What a coincidence. Just now suprnova (not coinmine!) found a block with 1 share. Block 23174. And as it should be only the lucky finder received a reward, the entire block reward minus the pool fee. Round stats here: https://dcr.suprnova.cc/index.php?page=statistics&action=round&height=23174 Since I have rigs mining on suprnova too I can confirm that I (and likely anyone else except the lucky finder) did not receive reward for that block. Suprnova therefore seems configured properly. Coinmine however seems to have a broken reward/payout system.
Okay, here is another issue with coinmine that didn't exist until appr. six hours ago. If I connect only one worker, it will hash nicely with almost zero rejects. As soon as I connect more workers they will produce 50% or more rejects. Not those rejects with additional messages but just "rejected" instead of "accepted" in each cgminer line ("Rejected blabla Diff blabla GPUx"). I can only suspect that this is maybe some anti-DDOS measure. Like one incoming connection per IP is okay but more than that is treated as DDOS and somehow blocked? But it isn't actually blocked, the second and next workers can connect. They just produce appr. 50% rejects. It doesn't mention which worker connects first. The first one is hashing nicely with zero rejects. All others get 50%+ rejects. In the past I could connect all workers and they all worked nicely. No change in config on my side whatsoever.
Good catch. That's on suprnova however and yes, it looks strange too. It says that the miner contributed 7 out of 8 shares (87.5%) but he didn't receive 87.5% (minus 1%) of the block reward (18.1670172 DCR) which would have been 15.73... DCR. Instead he received only 15.10... DCR. And 1 share out of 8 (12.5%) was not paid out at all.
As I said, not just 1 share (12.5% in this case), but also the miner with the 7 shares received less than he should have. It's also possible that all 8 shares were his. Only the pool can tell what happened. What is shown in the front-end is fishy and even more so in the coinmine case because if rewards are not distributed according to actual shares contributed, then based on what else?
Oh, something happened at coinmine. It looks like it works now as it should with regard to round rewards. Look at this: https://www2.coinmine.pl/dcr/index.php?page=statistics&action=round&height=23480 Block 23480 found by "shirbazo" with 1 share. And only the lucky finder got DCR, the entire block reward. Until now the reward was always split on all miners in the pool in such a case.
hi - you are very fast in writing.... lets go one by one - payout system - it is very difficult to find what happened with "lucky finder" but for sure it should not be only one person, because there was much more shares in DB at that time. There may be several reasons why system detected only one miner but most probably it was when block was already in wallet and it was detected by pool however getwork/stratum server still did not write shares into DB (not necesarily for that block). In this case pool has a "failover mode" when it takes share which more or less matches to the time when block as found. It may be that it took all shares for previous block and then for net block only one share remained in DB... Not sure if this is clear enough It may happen when you have thousands of miners and there is some interruption in network connection or just longer DB query. Next one - rejection rate - is it still happening? I am receiving alerts about DDoS attacks from my provider but they may be fake and they are probably related to shitty cgminer longpoll implementation when it creates several connections to server and never close anything, which ends up in situation when there is 100 workers on one server and 6000 connections.... Thats why stratum is better and may handle workers better even with Decred getwork-over-stratum implementation. I will try to add additional servers for getwork/longpoll but I must calculate if I will not be loosing money... feeleep
Yes, still 50%+ rejects whenever I connect more than one rig. First rig will run fine, all others will produce just this: decred cgminer 0.0.4 [2016-04-29 13:54:34] Rejected 168be26d Diff 11/8 GPU 2 [2016-04-29 13:54:49] Accepted 1b377c5e Diff 9/8 GPU 1 [2016-04-29 13:54:52] Rejected 06ceefe9 Diff 38/8 GPU 0 [2016-04-29 13:55:02] Rejected 05ad395e Diff 45/8 GPU 1 [2016-04-29 13:55:07] Accepted 13e64c2c Diff 13/8 GPU 0 [2016-04-29 13:55:12] Accepted 105a8d67 Diff 16/8 GPU 0 [2016-04-29 13:55:14] Accepted 0ab21a3d Diff 24/8 GPU 1 [2016-04-29 13:55:18] Rejected 0698a4cc Diff 39/8 GPU 2 [2016-04-29 13:55:20] Accepted 13275879 Diff 13/8 GPU 1 [2016-04-29 13:55:21] Rejected 148d1a5a Diff 12/8 GPU 0 [2016-04-29 13:55:23] Rejected 01498a06 Diff 199/8 GPU 2 EDIT: This happens with the new 0.1.0-decred cgminer too. And only on your pool. I can connect multiple rigs to other pools and they will just mine fine. As I said, the problem with the rejects appeared suddenly on wednesday (27.04.) evening and persists since then. My only guess, after eliminating all sources on my side, is that you changed something on the pool config by that time. Your pool ran nicely with multiple rigs since weeks and months. EDIT: If I set queue to 0 as you recommend, I get this: [2016-04-29 14:22:14] Pool 0 not providing work fast enough [2016-04-29 14:22:15] Accepted 087c8f59 Diff 30/8 GPU 0 [2016-04-29 14:22:16] Pool 0 not providing work fast enough [2016-04-29 14:22:17] Rejected 0c82ad47 Diff 20/8 GPU 1 [2016-04-29 14:22:21] Rejected 0423f923 Diff 62/8 GPU 0 [2016-04-29 14:22:22] Accepted 1a5aa2cc Diff 10/8 GPU 0 [2016-04-29 14:22:24] Pool 0 not providing work fast enough [2016-04-29 14:22:28] Pool 0 not providing work fast enough [2016-04-29 14:22:29] Rejected 13aa37b7 Diff 13/8 GPU 0 [2016-04-29 14:22:32] Rejected 0df5b7ea Diff 18/8 GPU 0 The first rig connected to your pool runs fine, with queue 1 and so did in fact all until wednesday evening. Going to try sgminer and stratum, however others have reported that it does not make full use of AMD cards. Something like 20% lower hashrate.
the miners didn't show anything weird and still running well but the rate at the pool is not even 1/2 or 1/8 of the hashrate reported in the miner at times. Sometimes it just stop working or hashing at 100mh instead of 2gh. Were there no issues from the pool? At times it dropped to 15-21% pool efficiency and also the total pool hashrate halves or even more. Happens about 5-6 times daily, at least that is what I been observing...