Problems with hashrate calculations

The problems with hashrate calculations reappeared today. What seems to be happening is that lots of shares are queuing up for insert, and during high database load periods, they all go in at once a few minutes later. This tricks the hashrate calculations to be up and down, even though the same number of shares are being inserted.

As far as I can tell, profitability is not affected by this problem, and the same number of shares are actually being submitted and paid out; their recorded times are simply off by a few minutes. I plan to investigate this issue in the evening.

I actually discovered that this is a major problem. The mining server can slow down when there is too much load because there are blocking calls to the database that still remain. It is true that no shares are lost, but some miners can have trouble submitting shares during those slowdowns.

For now, this should not be a problem, because it can be mitigated by killing the block explorer. Tonight, I'll work on a permanent solution and then the server will be able to handle high load periods again.

I am using using nicehash, things are going well for hours and then my rejected due to timeouts goes to between 50% and 100%.
I changed to a different pool, , and things seem to be good.

The way I have solved it is to wait for a little while, 1-2 hours, and then resume.

related?

I think this is a different problem than Nicehash is having.

While I don't have access to their code, if you were experiencing this problem here, you would simply see delays in accepting the shares. Here, the shares wouldn't be rejected; you would see it as a disconnect.

The problem with our pool should be fixed now. I reduced database load until we have the code to deal with it. I think Nicehash's problem is unrelated.

Thanks for the response.

Steve Sokolowski wrote:While I don't have access to their code, if you were experiencing this problem here, you would simply see delays in accepting the shares. Here, the shares wouldn't be rejected; you would see it as a disconnect.

That is kinda what I am seeing. I do not see them as rejected by prohashing I just see my rate cut by 50-100%.

On their end I am seeing them as rejected by pool due to timeout. Timeout for them is defined as "Speed measured according to shares for which pool did not respond in 15 seconds time."

Do you see this rate being cut now, or just earlier in the day, before 12:00pm?

I have not been using prohashing since 7/5 @ 2pm ET.
I can tell you 7/5 1:20pm to 3:40pm these timeout's were in the 50-75% range.

I will try a test now and see how it goes.
I will let you know.

I have been running for 18 hours and no "Rejected Due To Timeouts" have occurred. Awesome thanks!!
I did however have issues between 12AM and 4:30AM ET but they looked like issues with connectivity, nicehash shows them as dead orders.
I believe it to be unrelated to the original problem as the behavior is different, so I am good, thanks!!

The problem between 12AM and 4:30AM EDT were an issue with database overload on our side. We have corrected the problem, and it shouldn't happen again.

Let me know if you experience any other issues. We are always looking to fix bugs, and since we can't test every single make and model of miner ourselves, we appreciate feedback.