Status as of Sunday, April 26

[Steve Sokolowski]

I've spent a lot of time the past few days knocking off bug after bug:

• Interestingly, Chris found a driver that was incorrectly installed that was causing 10% lost packets. The driver had been present since the site was founded. We don't know what effect the lost packets had on mining, but it had to have caused some major problem. It could have been responsible for the strange disconnects kires was reporting.
• We finally got the issue with miners losing money because they were assigned to coins that were too easy for their static difficulties. There are some daemons that are so easy that the share difficulty is higher than the block difficulty. Now, miners who want to mine difficult shares won't be assigned to those coins. The cause of this problem? In computers, 2048 / 65536 is not 0.03125 as would be logical; it is zero, because the result is an integer, rounded down.
• The issues with shares being lost due to floating-point arithmetic is now resolved. Chris will reimburse miners for the periods of time when hashrate declined.
• We now think that the system is stable enough to begin advertising. Please report any bugs that remain. There are a few known issues: the block reward is slightly off on some coins, but that only affects payouts by around 0.01%; it will be fixed soon. Some proof-of-stake coins are losing blocks, so they are disabled, and the trader fails to execute some trades due to balance issues, which causes us but not you to lose money. There is a memory leak that only requires a restart every week, so we might not even fix it. Our focus for the next few weeks continues to remain with stability and accurate accounting.

[Steve Sokolowski]

We're done with fixes for today. Unfortunately, since I can't reproduce any of the errors locally, I often have the restart the mining server. Hopefully, these sorts of restarts will be done this week.

[kires]

I don't want to jinx it, but from what I've seen so far, this last fix has done the needful, at least as far as my miners are concerned. My hashrates are right where they ought to be, and I've gone ahead and pointed both miners here. At the moment, they're both running with no secondary pools, just so I can get 24 hours worth of data for comparison. Tomorrow morning I'll add the backup pools and see what happens. I think the monogamy bug is fixed, but I'll let you know what I find. Also, if you want an interesting illustration of the past few days worth of fixes and their effects, then check out my hashrate chart. It's pretty obvious where various things changed.

[Steve Sokolowski]

I don't think it was your miners. I think that the bad driver installation caused disconnects for almost a year. I wouldn't be surprised if we spent 500 hours doing things that weren't necessary solely because of this driver issue.

I noticed that the work restart time on your miners is down to less than 1s now, which means that you rarely mine suboptimal coins anyway. While there are users who have long work restart times, your problem was probably never caused by work restarts at all.

[kires]

There ought to be a cliche, some pithy version of: The more time and energy you spend diagnosing an issue, the simpler and more facepalm-inspiring the root cause turns out to be.

[kires]

The monogamy bug is not resolved. I re-added the backup pools this morning when I got up, and was planning to let them go for 12 hours like that. But my hashrates were so hilariously bad and unstable that I removed the backup pools a little over an hour ago, at which point they seem to have recovered nicely. So having backup pools in place does awful things to my hashrate... I can only guess whether this is something on your end or a BFGMiner issue. On the one hand, I can't imagine what could be going on server-side that would shred my hashrates when a backup pool is in place client-side. But on the other hand, I don't see the issue when I've got ghash (either ltc or multi) set as my primary with this pool as backup.

[Steve Sokolowski]

I'll add this to the list of things to try to debug tonight or tomorrow.

If it is a bfgminer issue, then it should be easy for us to reproduce with our own test miner. Hopefully it isn't a combination of your miner with bfgminer, which would be very difficult to resolve.

bfgminer is an extremely poor piece of software. It doesn't follow the stratum specification and there are many patches that need to be made to deal solely with its bugs.

[Chris Sokolowski]

I noticed while reading the Ubuntu bfgminer manual (http://manpages.ubuntu.com/manpages/tru ... ner.1.html) that there is an option in the configuration:

--failover-only
Don't leak work to backup pools when primary pool is lagging

Can you try this config parameter in bfgminer and see if the issue resolves itself?

[kires]

The short version is 'thanks; it worked perfectly'. Restarting the miners to enable that option isn't even discernable in the hashrate chart, and they're running like they mean it. Thanks for pointing that out to me. I'd seen it before, but had (foolishly) assumed that it was the same as setting them to failover as opposed to load balance via the web interface. Live and learn. Speaking of which, while mucking about in it's config files, I found an option to use cgminer instead of BFGMiner. I'll probably give that a shot tonight, but for now I'm just going to be glad that they're running as well as they are.

[Steve Sokolowski]

Hi Chris,

Could you add this tip to the documentation, check in the changes, and release a new version of the website? That way, other bfgminer users will know how to fix this.

Thanks,

-Steve