Deployed new code

We deployed the new code and were finally able to get it to run successfully and to perform well. After some discussion, we decided that the system is good enough to move forward with this release and to fix its issues, rather than to revert from now on.

The major issues seem to be related to rejected shares. I have a fix for this problem and am testing it now, so it should be fixed in a few hours. While the number of rejected shares may appear alarming, there are very little, if any, losses due to the problem.

I'm glad the new code was deployed, but I'm not able to actually mine. I can connect, and the pool is alive according to BFGMiner, but I'm not able to actually get shares submitted. Once BFGMiner gets past the 'configured successfully' messages, I get a procession of:

[2015-04-20 01:57:46] Stratum connection to pool 0 interrupted

which has itself been uninterrupted for about the past ten minutes, so I'm going to give up for now and check back again later. LEt me know if there's anything I can do differently from my end.

It's an interesting issue because I already tested this code with your miners and it worked fine. I'll point Steve to this post in the morning and he'll investigate. Perhaps it's failing over because of the initial work restart testing phase. If you remove backup pools, does it connect to our server within two minutes, which is the longest it could possibly take your slower miner to complete the work restart testing phase?

The other thing is that I see no shares submitted on your account since 8AM EDT. We only deployed the code at 5PM EDT. Were you getting the errors in the morning or only just now?

Oddly enough, it wasn't failing over. It was connected to ProHashing just fine, it just was neither mining here nor failing over to Ghash. Just now I removed ghash as the backup pools so only Prohashing remains (which I did not expect to make a difference, as it wasn't actually failing over) and it seems to be working properly now. Moving Prohashing to the top of the list on the other miner but leaving backup pools in place resulted in the same behavior as last night, with the 'just pretending to mine'. So now both miners are pointed at Prohashing with no backup pools in place, which is working but is not really a viable long term scenario, imho. I love the work restart optimization, but I'll be glad when the monogamy bug is taken care of.

Ah, that last thing was because that morning I noticed that due to the restart issue, my effective hashrate seemed to be down to about 2/3 of what it oughta be, so I had them pointing at GHash's LTC pool until I saw that the new release had been rolled out to prod.

[edited for comma abuse]

Also, the breathtaking reject rates I'm seeing are just the work restart optimization working as designed and the stats reporting being too technically precise to be really accurate in practical terms, right?

For now, I wouldn't worry about reject rates, because there is a bug. Worry about acceptance rates. If the accepted shares are what you would expect, then you are being paid for the number of accepted shares you are submitting, regardless of how many rejects the system is calculating. Is your accepted hashrate what you expected? I'll post more about this in the "development" forum, so go over there in a few minutes.

For all users, we are working on diagnosing and resolving the issue of being unable to connect. In the meantime, you can try Kires' solution of removing backup pools from your configuration until we fix the issue. Let me know if this solves the issue for you as that could help us diagnose the problem.

I think I've traced down the issue to being exclusive to bfgminer. I can't connect our miner to the pool using bfgminer, but cgminer works fine. I am going to work with Steve to modify our code to get our miner to connect using bfgminer, and I'm inclined to believe it will solve your issue as well.