Status as of Sunday April 16

Hi Everyone,

We appreciate your patience staying with us during this release. We fixed a lot of bugs today, but are a few remaining issues. We will be working all day on Monday to fix them.

• The server is not reporting hashrate correctly. This bug does not affect earnings, as earnings are based on the actual shares submitted, but it may result in more conservative coin choices. Fixing this bug is our first priority.
• The mining server does not work with NiceHash. The reason is that NiceHash disconnects when the initial difficulty is too low, but we must have a low initial difficulty for X11 miners to be able to connect. This is a more difficult problem to solve, and we are trying to plan a solution that balances the needs of X11 miners and NiceHash miners.
• The block explorer and some of the historical charts do not display any data. When we released X11 mining, we also deployed a new database with new hardware. Importing the remaining data such as the block explorer data will take a few days. There is about 2TB of data to copy, and we hope to have the block explorer back online by the end of the week.

I will also be crediting miners for the missing shares on Sunday morning. Payouts on Monday morning will be delayed for a few hours so that I can monitor the system and fix any errors when they go out.

We will provide status updates throughout the day tomorrow. As always, please reach out to us if you have any additional questions or problems. Thanks again for your support.

Chris, pool rejects have risen significantly but appear to only affect certain miners. I've rebooted miner, switch and router to no affect so I'm thinking the issue is not latency related but poolside daemon (are per miner connections sticky?). My overall poolside hashrate has dropped by at least 15% and the efficiency of what remains has fallen below 94% so I've flipped to my secondary while you continue to work on resolving these problems.

Update re: Nicehash issue with password arguments -

Member named spauk in the other thread pointed out that it's now necessary to explicitly set a=scrypt before it will accept the d= value. In other words, allowing it to default to scrypt causes it to also default to var. def regardless of settings.

Tested and confirmed to work for me as well.

vinylwasp wrote:Chris, pool rejects have risen significantly but appear to only affect certain miners. I've rebooted miner, switch and router to no affect so I'm thinking the issue is not latency related but poolside daemon (are per miner connections sticky?). My overall poolside hashrate has dropped by at least 15% and the efficiency of what remains has fallen below 94% so I've flipped to my secondary while you continue to work on resolving these problems.

What type of rejected shares are these? Do you have an error message?

Any idea when the static diff will be fixed?

dustind900 wrote:Any idea when the static diff will be fixed?

It should be fixed now. Let me know if there are any issues.

Doesn't look like a smooth release. Did you thoroughly test it in a test environment? I suppose you should not have this many issues if you dry run in an exact copy of your production environment. Just my $ 0.02

biscayne wrote:Doesn't look like a smooth release. Did you thoroughly test it in a test environment? I suppose you should not have this many issues if you dry run in an exact copy of your production environment. Just my $ 0.02

We did, but we knew there would be problems. The major problem is that there are so many models of miners, and they all have different characteristics. We tested on a few types, and those worked, but there was no way to test them all. The combination of all these different systems working together is what causes these problems.

But fortunately, I hope that you're satisfied now, as I think the mining server is running smoothly. As to the payouts, that's just Chris being absolutely sure that the system is working before issuing them, not a sign of a problem.

Steve Sokolowski wrote:

vinylwasp wrote:Chris, pool rejects have risen significantly but appear to only affect certain miners. I've rebooted miner, switch and router to no affect so I'm thinking the issue is not latency related but poolside daemon (are per miner connections sticky?). My overall poolside hashrate has dropped by at least 15% and the efficiency of what remains has fallen below 94% so I've flipped to my secondary while you continue to work on resolving these problems.

What type of rejected shares are these? Do you have an error message?

Sorry for the delay in responding Steve, UTC+12 and 200 mile roadtrip today meant I'm only reading your reply now. You seem to have fixed it but my cgminer logs were showing lots of 'stale' shares if that helps now?

vinylwasp wrote:

Steve Sokolowski wrote:

vinylwasp wrote:Chris, pool rejects have risen significantly but appear to only affect certain miners. I've rebooted miner, switch and router to no affect so I'm thinking the issue is not latency related but poolside daemon (are per miner connections sticky?). My overall poolside hashrate has dropped by at least 15% and the efficiency of what remains has fallen below 94% so I've flipped to my secondary while you continue to work on resolving these problems.

What type of rejected shares are these? Do you have an error message?

Sorry for the delay in responding Steve, UTC+12 and 200 mile roadtrip today meant I'm only reading your reply now. You seem to have fixed it but my cgminer logs were showing lots of 'stale' shares if that helps now?

So the issue of lower hashrate was resolved, but you see stale shares? What password arguments are you using?