Status as of Monday, June 4, 2018

[Steve Sokolowski]

Good morning!

• I think that my strategy this week of focusing on mining server issues rather than moving immediately onto new algorithms is paying off. I discovered an issue that causes coins to go into error frequently because some exchanges have unreliable APIs. We're going to make a release later today to allow these coins 20 minutes of exchange API unavailability before declaring them in error, which will reduce the number of disconnects for static coin miners and the number of work restarts for dynamic miners.
• The 2% profit increase that was passed onto customers, as a result of fairer payouts to part-time large miners, was in effect for its first day yesterday. You can see the difference in the "1MH/s expected payouts" chart for all algorithms between Saturday and Sunday. Notice how the break between our profit and the LTC line has increased. I hope to increase that by another 1% a few days from now once we have more confidence in the data.
• The "live coin status" chart shows incorrect bar lengths for some coins. This is a known issue caused by the profit improvements and it will be fixed later in the week. The problem is caused by the way we reduce the amount of data that is sent to customers in that chart, to conserve bandwidth. The backend uses the full set of data and therefore is not affected by this issue.

[accumulus]

Did you guys do another quick reboot about 20 minutes ago today at apx. 3:45pm ET? I noticed all my machines went to No valid shares yet before returning to calculating hash rate, and finally back to getting the hash rate calculation, (usually starts low and slowly improves to the normal hash rate for each type of machine). Just checking.

Thanks!

[Steve Sokolowski]

Did you guys do another quick reboot about 20 minutes ago today at apx. 3:45pm ET? I noticed all my machines went to No valid shares yet before returning to calculating hash rate, and finally back to getting the hash rate calculation, (usually starts low and slowly improves to the normal hash rate for each type of machine). Just checking.

Thanks!

Something started using a lot of WAMP CPU load around that time, so we restarted the servers. It's still going on, so we're continuing to investigate. However, the mining servers seem to be running fine because prices are still getting through when the CPU load dies down.

[CSZiggy]

why bother, no one cares.

[Steve Sokolowski]

If I connect 1000 web pages, does each instance get a copy of the WAMP data sent, does each one update every second? Does having more webpages accessing create a larger load? Can you guys limit WAMP updates to like 1 time per minute or something? Turn off all the rest of the commands so people can't continually ask for updates. Hit refresh 1 million times.

Set it to update the data it broadcasts at the top of every minute. All the rest of the refreshes and loads see that last update. If its updating so much that its drawing too much CPU or causing other issues, why does it need to be shown as often? Other sites don't even broadcast, if you want to see an update you have to refresh the page to see update info on coins and values.

Other than cherry-picker bots that static mine the top coins so autopool people can't benefit from them, why does the WAMP info even matter to miners? If you removed it in the next update and people could no longer see it on the main webpage, would it affect profits or mining at all for the autopool?

The cause of this problem appears to be the miner updates. When there is a new litecoin block, we often need to quickly send work to all miners, and publish all the updates to all the miners. Sometimes there are 20,000 messages sent in 0.3s.

Tomorrow, after we confirm that the algorithm-specific ports are working, I'm going to look into how we can reduce that issue. The best solution might be just to have additional realms so that the update data can be parallelized more effectively.

[CSZiggy]

why bother, no one cares.

[Steve Sokolowski]

At the top of the forums is WORKER: ##### stat.
is that the number of accounts or the number of miners connected to the pool?

If there are only 21K miners on the pool, why do 20K of them need to know about litecoin blocks?
Aren't there some miners on SHA, X-11, equihash? 20K of the 21K workers are only doing scrypt?

Shouldn't the new litecoin block message only be sent to those that were working on litecoin?
The pool has 20K workers just doing litecoin?

The miner updates are only received by users who have subscribed to them, so that isn't the issue. The problem are publishing the updates so that the WAMP server can determine who is subscribed, and sending all the new block templates to the litecoin miners when a new block occurs. With so many miners changing work at the same time, these two things take a long time and I'm not aware of any way around it.

However, I was able to reduce the number of general_updates that were sent. It turns out that the hashrates at the top of the forums were updating once per mining server rather than once every time a block arrived, which means that 8 times as much data, or about 1000 subscription receipts, was being received by users. The approximate numbers that can be obtained by choosing one of the 8 nearly simultaneous publications are good enough for use by customers. I already released that change and it should reduce general CPU load and bandwidth usage, even if it doesn't resolve the issue of large numbers of work restarts required when a litecoin block arrives.