Accepted hashrate

Post by **Chris Sokolowski** » Wed Apr 22, 2015 11:02 pm

It shouldn't make a difference; they're stale either way. It's just a matter of whether shares are rejected on your end or on our end.

kires · Post by **kires** » Thu Apr 23, 2015 10:24 am

I've pointed one miner here, and the other at ghash, just to ameliorate the effects of the trouble that my stupid Titans seem to be having. The issue is not as simple as low hashrate or high rejects. My reported hashrate here is very unstable, (while the hashrate as seen from my side remains stable) and the miner itself will occasionally and randomly fail over to its backup pool for a few minutes, which indicates that... well, I'm not sure what it indicates, but it's weird. My real question is this: Is this an issue that you believe is worth investigating? If it's only my miners (or Titans) that are experiencing the issue, then I would totally understand you not wanting to spend a lot of man-hours on the problem, but it does seem that at least one other user is experiencing the same thing, and slawek isn't running the same hardware I am. Of course, I'm still willing to give you access to one for all the testing you care to do.

Post by **Steve Sokolowski** » Thu Apr 23, 2015 11:32 am

One lesson I've learned from programming for years is that if an error occurs, you always need to figure out what the cause is, even if it seems minor. For example, on Monday I discovered that there were exceptions that were causing about 100 shares to be lost per day because the number of earned coins was negative.

100 shares was miniscule, but upon further investigation I found that the issue was caused by floating point addition and subtraction being imprecise. If you do something like 5.0 - 2.0 + 2.0, you might end up with 4.9999999987342332. Over time, these errors led to inaccurate payouts, even when the shares were not dropped.

Even if this issue only affects your own miner, it's still a problem worth investigating because we don't know the cause. There might be a serious effect elsewhere in the system caused by the issue. I definitely want to investigate and try to figure out what the reason for this problem is. I'm going to look at the shares you've submitted and try to determine if there is a pattern in them.

Post by **Steve Sokolowski** » Thu Apr 23, 2015 11:35 am

Wait a second. You set "no-submit-stale" to true? If so, change it to "false."

Because we merge mine coins, a share is rarely completely stale. If the primary coin is stale, you will still get credit for the merge mined portion, and vice versa. If you set your miners not to submit these shares, you will lose money.

Please change that to submit stale shares and tell us what effect that has.

kires · Post by **kires** » Thu Apr 23, 2015 11:45 am

Oh, It's been set to false ever since I read that bit about partial shares in the FAQ. I was just checking to be sure, in light of all the changes and the general weirdness I've been seeing.

Post by **Steve Sokolowski** » Thu Apr 23, 2015 1:01 pm

There is also one additional issue that needs to be looked at where some miners are being assigned to coins that are too easy for their static difficulties. Fixing that might happen to fix your issue too.

If not, then I'm going to look at the shares you've submitted to see if I can determine any patterns in the data.

Post by **Steve Sokolowski** » Thu Apr 23, 2015 2:57 pm

I looked at your shares, kires, and there is definitely something strange. There are periods where everything is operating normally, and then for as many as 40 seconds, no shares are submitted. I thought it might be caused by coin switches, but these issues are occurring even when the same coin is being mined. I'll continue investigating.

Post by **Steve Sokolowski** » Thu Apr 23, 2015 3:16 pm

I think I figured this issue out. The problem was an incorrect assumption.

We had assumed that a miner who is connected to the pool and assigned a coin always submits shares. However, as it turns out, that isn't the case. Some miners are connecting and not submitting any shares, even rejected shares. As a result, their hashrates are zero, leading to occasional division by zero errors which are causing some shares to be lost.

We should have this fix released in about three hours.

kires · Post by **kires** » Thu Apr 23, 2015 3:53 pm

Fascinating. That would jibe with what I'm seeing from my end. Something is stopping my shares from getting through, maybe bfgminer or maybe some crazy connectivity issue. The fact that the miner is failing over to the backup pools tells me that it's maybe not as simple as BFGMiner just deciding to not send any shares for a while. Now the mystery becomes 'why the hell do miners just stop sending shares, or what is preventing the shares from getting through or getting sent?

Also, do you think it would be worthwhile to remove the static difficulty setting from my connection string?

Post by **Chris Sokolowski** » Thu Apr 23, 2015 4:29 pm

I suspect that some mining software connects to all pools in the configuration file simultaneously, including backup pools, and only submits shares to the primary pool. This would allow the miner to fail over to the backup pools faster, eliminating the wasted time between when the primary pool fails and a connection is established with the backup pool.

Regarding the static difficulty, I've found that each miner has an optimal difficulty to get the maximum hashrate, which at the moment our mining server cannot determine. The automated difficulty adjustment of the mining server will almost surely escalate your miner to d=65536, which may be suboptimal. If you know d=8192 is optimal for your miner, I would keep that difficulty; our current server can't calculate it better than you.

Accepted hashrate

Re: Accepted hashrate

Re: Accepted hashrate

Re: Accepted hashrate

Re: Accepted hashrate

Re: Accepted hashrate

Re: Accepted hashrate

Re: Accepted hashrate

Re: Accepted hashrate

Re: Accepted hashrate

Re: Accepted hashrate