New release tonight

[Steve Sokolowski]

Good afternoon!

Chris will issue a new release tonight. As you may recall, yesterday we resolved an issue where some types of rejected shares were not recorded to the database. This issue was discovered while investigating a May 17 ticket that we recently got around to, which complained about a high number of rejected shares. When we tried to query the miner's shares, we found that the ratio his miners displayed didn't add up because of this recording error.

Originally, we planned to allow the rejected shares to record for at least three days and then to begin investigating whether there are some rejections that can be eliminated. However, when I checked this morning, I noticed that there were a lot of "Duplicate share" rejections that had been correctly recorded even before this release, but which nobody had ever thought to query for. These are lowering profitability by almost 1%.

Upon further investigation, I determined that some miners are restarting work when they are sent a "work refresh" every 55 seconds when they are mining very difficult coins. "Work refreshes" were necessary in 2013 to work around bugs in cgminer and bfgminer where those programs would erroneously assume the mining server was disconnected if no new work was available within 60 seconds, and therefore they would frequently disconnect and reconnect to the mining server when mining difficult coins like litecoins.

At the time, we weren't able to reproduce the issue with our miners, nor are we able to now, but adding work refreshes was known to other pools and it did resolve the disconnects issue. I don't know whether the problem still exists in the most modern miners, as we don't have access to all types of miners. Therefore, in addition to resolving the "duplicate share" issue with work refreshes, I also added a new "e=" password argument, the purpose of which is described in the documentation.

There are three valid values: "work," "difficulty," and "off." In "work" or the default mode, work refreshes are sent as before. In "difficulty" mode, proving that the mining server is still connected is accomplished by sending a difficulty change request to the same difficulty. In "off" mode, no work refreshes are sent, improving the profitability of miners which either run or can be configured to run without the timeout bug.

The changes will be available tonight. Once they are released, feel free to try setting "e=off" to see if you can improve the performance of your miners!

[jeffms2003]

How will profitability only increase by 1% if has rates have been understated by 5%-10%? If eliminating the duplicate work fixes the issue and allows my ASICs to process 5%-10% more shares, would I not see a 5%-10% increase in daily earnings assuming the rate/s/day remains constant?

[Steve Sokolowski]

How will profitability only increase by 1% if has rates have been understated by 5%-10%? If eliminating the duplicate work fixes the issue and allows my ASICs to process 5%-10% more shares, would I not see a 5%-10% increase in daily earnings assuming the rate/s/day remains constant?

If your ASICs encounter this duplicate share issue 10% of the time, then profitability for your ASICs will go up by 5%.

However, the average miner only encounters 1% of duplicate shares due to this problem, so most miners won't see a 5% increase from this fix. There may be other issues that we'll continue to investigate after this one has been resolved.

[grinbuck]

Has this been released yet?