Status as of Sunday, September 10, 2017

[Steve Sokolowski]

Good afternoon! The purpose of today's update is to review what was included in yesterday's release and what will be included in a new release tonight. Here's what you should see:

• Miners who enter invalid difficulties with d= will now be disconnected. There was previously a bug where they would remain connected and either be able to submit invalid shares or not be credited; I don't know which happened.
• The performance of the mining server was improved by a realization that we only need to reassign users who were mining the coin that had a stale block, in the case of a stale block, rather than all users. An additional improvement is that coins that are fully assigned are not considered in the assignment loop, saving 80,000 operations per round of assignments.
• The maximum difficulty of the pool was increased to 2^20 and will be increased further to 2^21.
• Because miners are being reassigned to new coins less frequently, work restarts will interrupt miners less frequently.
• Because CPU load is lower, coin assignment completes much more quickly, resulting in less latency and therefore fewer stale shares.
• There were some portions of the server where the coinbase transactions of the blocks were being copied repeatedly. I reduced the number of copies of this data by referencing a single copy in a lookup table. That means that there is less CPU usage spent copying strings, and a greater chance that the single copy can be stored on the processor's cache.
• The feature that limited our share of a coin's network to less than 50% was removed. Now, the limit will be determined by the target block time of the network times a configuration value. We'll start with assigning no more hashrate to coins than to make their blocks occur twice as frequently as the coin's target. If no other pool is mining the coin, that means that the coin's difficulty should never more than double during one difficulty adjustment due to us alone. This change will reduce the number of operations required to be checked during coin assignment.
• hashingpro reported that he couldn't connect to his accounts. We determined that the cause of the problem was that he was using lowercase letters, when his accounts were capitalized. This new release corrects that problem.

The second release will occur this evening.

We've also received a number of support tickets about declining profits. That should be expected, as that's how mining works. One of the issues I think is being missed is that it's September now, and miners provide free heat. Most people in the world live in the northern hemisphere. Our miners, for example, are only profitable above 13 cents during the summer, 9 cents during the early Fall and late Spring, and at 3 cents the other six months of the year, because less gas is used for heat as a result of the miners.

[jaybizz]

Just throwing it out there, but I was seemingly fine as far as stales/rejects are concerned, until the hashrate spiked to over 2K for scrypt. Again, as others have asked as well, it'd make sense to see how performance is actually being impacted before taking on more hashrate.

[hashingpro]

• Miners who enter invalid difficulties with d= will now be disconnected. There was previously a bug where they would remain connected and either be able to submit invalid shares or not be credited; I don't know which happened.

Steve, does that mean that the error code:

"This miner is submitting shares too frequently. Its static difficulty is too low, and therefore is being ignored."

should have been kicking the miners off and ignoring them instead of ignoring the difficulty and automatically switches the worker to vardiff?

[GregoryGHarding]

• Miners who enter invalid difficulties with d= will now be disconnected. There was previously a bug where they would remain connected and either be able to submit invalid shares or not be credited; I don't know which happened.

Steve, does that mean that the error code:

"This miner is submitting shares too frequently. Its static difficulty is too low, and therefore is being ignored."

should have been kicking the miners off and ignoring them instead of ignoring the difficulty and automatically switches the worker to vardiff?

no he means difficulties lower than minimum static, or difficulties not divisible by 2

[Steve Sokolowski]

• Miners who enter invalid difficulties with d= will now be disconnected. There was previously a bug where they would remain connected and either be able to submit invalid shares or not be credited; I don't know which happened.

Steve, does that mean that the error code:

"This miner is submitting shares too frequently. Its static difficulty is too low, and therefore is being ignored."

should have been kicking the miners off and ignoring them instead of ignoring the difficulty and automatically switches the worker to vardiff?

No, this error is working exactly as described. You're using a static difficulty that is too low, so it is ignored and a higher variable difficulty is set.

The variable difficulty targets one share per minute, but your miners are configured to submit shares at least 120 times more frequently than that. The best way to eliminate this error is to use d=2^20 or 16, depending on algorithm, so that you submit shares less often. You'll still make the same amount of money. Or, you can do nothing and allow the error to persist, which will use variable difficulty and you'll still earn the same amount of money.

[JoeTheMiner]

Steve,

Just wanted to let you guys now that everything appears to be working great now for me. Keep up the good work!

Thanks,
Joe

[Searing]

I show 97.25% eff yet 1/2 my stuff is bouncing to backup pool (litecoinpool.org) so kinda confused on that % unless it is pool wide
3000mh of Titans and 1000mh of L3's (250mh) and 5 L3+'s (2500mh) total 6500 mh

it seems to be mainly L3's and 1 titan ..go figure

edit: guess that is less then the 1/2 I stated but still annoying and no way to tell what and why