Status as of Sunday, April 23, 2017

[Steve Sokolowski]

Here's a status update as of this morning, which will be brief because I want to spend the day working on as much as possible:

• It turns out that blocks were being orphaned more often than usual because the IP address of the mining server had changed during the upgrade, and as a result the software that throttles our coins' upstream bandwidths was not running properly. This problem also caused slow download speeds accessing the website. The issue has been resolved and in addition to faster website response times, the end result should be better coin selection and increasing profitability as the true orphan rates are determined over the course of the next week.
• DASH is still losing blocks due to an unrelated issue. I tried a fix this morning, but we'll need to find a block before I know if it worked.
• Michael has been hard at work on the website yesterday and will be today as well. We expect some of the annoyances listed in the "Website wishlist" thread to be eliminated within a few days.
• Chris had to restart the entire system last night due to poorly designed software from Intel. Rather than allow the RAID for the block explorer data to simply be reformatted, they displayed a message stating that the operating system kernel didn't receive some sort of message and that a full reboot was required. After rebooting, Chris was able to start copying back the block explorer data. Hopefully, the block explorers will be online within a few days. These constant RAID problems are largely responsible for the block explorer delays.
• Given that SegWit on Litecoin is likely to activate regardless of what we do, we won't need to take any action to assist in its activation, and therefore won't have to sacrifice any profit.
• Miningrigrentals is fundamentally incompatible with x11 mining on this pool. The problem is that, for some reason, they disconnect miners from pools with low difficulties immediately upon start. I'm not sure why they care about the difficulty, but even if they do, they don't wait until the password argument can be parsed and the difficulty in the argument determined about 0.1s later. Miningrigrentals works with Scrypt because the difficulty sent to miners upon connect is a scrypt difficulty, so it isn't out of their range of valid difficulties. We can't provide a date on when this issue will be resolved because it isn't only our issue.
• I'm going to investigate the "NiceHash stales" today, although I think that part of the issue may have been resolved by that daemon upstream bandwidth fix. Please update me if you're still receiving strings of stale shares with NiceHash.
• The mining server is suffering from performance issues and this, in turn, is causing share inserts to be delayed and the website statistics to have gaps. There is no easy fix for this problem and we expect the messages about statistics delays to continue for several weeks. However, these issues do not cause losses of money.

[FRISKIE]

Hey Steve, I'll setup a lower hashrate order on Nicehash and let run awhile, and post a link to the perf graph after a while. I'll start without setting a static coin and use "h=50" , test a while, then do one more with "c="

[excelerator]

Here's a status update as of this morning, which will be brief because I want to spend the day working on as much as possible:

• Miningrigrentals is fundamentally incompatible with x11 mining on this pool. The problem is that, for some reason, they disconnect miners from pools with low difficulties immediately upon start. I'm not sure why they care about the difficulty, but even if they do, they don't wait until the password argument can be parsed and the difficulty in the argument determined about 0.1s later. Miningrigrentals works with Scrypt because the difficulty sent to miners upon connect is a scrypt difficulty, so it isn't out of their range of valid difficulties. We can't provide a date on when this issue will be resolved because it isn't only our issue.

Your statement about the date for the MRR difficulty issue being resolved " isn't our only issue." is a little ambiguous. Do you have additional issues with MRR for X11? Where does this issue fit into your prioritization for enablement?

[FRISKIE]

Nicehash is still a mess - I did a few test jobs but terrible results, I suppose until the server performance issues are resolved the issues with stale and reject shares will persist.

[Steve Sokolowski]

Here's a status update as of this morning, which will be brief because I want to spend the day working on as much as possible:

• Miningrigrentals is fundamentally incompatible with x11 mining on this pool. The problem is that, for some reason, they disconnect miners from pools with low difficulties immediately upon start. I'm not sure why they care about the difficulty, but even if they do, they don't wait until the password argument can be parsed and the difficulty in the argument determined about 0.1s later. Miningrigrentals works with Scrypt because the difficulty sent to miners upon connect is a scrypt difficulty, so it isn't out of their range of valid difficulties. We can't provide a date on when this issue will be resolved because it isn't only our issue.

Your statement about the date for the MRR difficulty issue being resolved " isn't our only issue." is a little ambiguous. Do you have additional issues with MRR for X11? Where does this issue fit into your prioritization for enablement?

This issue could be resolved if they didn't disconnect miners immediately and waited a second or two to see what difficulty the mining server assigns to the miners. That would be an easier fix.

A harder fix that Chris has suggested is that we could set up some sort of proxy server on a different port, and anyone who connects to that proxy server would get an initial difficulty of 1. Currently, the initial difficulty (for the first 100ms) is 8192, because we had to choose one "initial difficulty" due to the way the stratum protocol works.

Unfortunately, this is a low priority given the number of tasks that we have to do. We have some ideas about the performance issues, and are working on them right now. I've asked Chris to delay responses to customer service requests to 2-day response times so that we can focus on the performance issues.