Status as of Monday, March 23
Posted: Mon Mar 23, 2015 9:36 am
Good morning! Here's today's status:
- There is a memory leak in the mining server, which I fixed in the next release. Until then, we may have to restart the server once per day to resolve the issue. The cause of the problem is that I had incorrectly assumed that blocks for all coins continue to advance at around their average block times. However, it turns out that there are some coins where the blockchain never advances, because nobody is mining that coin. Because we need to store all the dogecoin blocks associated with the current block in case someone was mining that stale share, these dogecoin blocks stay in memory indefinitely, or at least until every single coin gets a new block. Since there is always at least one coin whose blockchain is stuck, it continues to accumulate old dogecoin blocks and the software runs out of memory. The fix is to only hold the last 10 dogecoin blocks in memory for any coin, which should be more than enough for even the highest latency miners.
- While working on the work restart code, I discovered that there can be significant delays in the mining server that delay processing of work from miners. I had thought that orphaned blocks were unavoidable, but it's possible we can increase profitability by reducing CPU usage of the mining server. I'm working on this now at the same time as Chris is testing the work restart code.
- I completed the code to predict work restart times over the weekend, and it is now in testing. The code now sends difficulty 1 shares for a period of 30s when a miner initially connects, and then starts normal mining. The median response time of the difficulty 1 shares is taken as the work restart time for that miner. The work restart time accounts for network latency, so it is never zero.
- After we have the work restart time, we then determine what proportion of the mining time will be spent on work restarts. That time, in general, is around (0.69 * block time - work restart time) / (0.69 * block time). This is the "work restart penalty." With our miners, we ended up with a value of 0.995 for Monacoins, or 0.5% less than optimal, but kires's miners are vastly less efficient. We then adjust all the expected payouts individually for each coin.
- One interesting fact we discovered is that the work restart time for the coin a miner is currently mining, assuming that there is not a new block, is zero, which results in miners switching coins less frequently.
- If the coins are listed in the same order of profitability regardless of work restarts, this miner receives no penalty and is assigned the same coin. If the miner is inefficient, then it is assigned the best coin for itself and is penalized the difference between the pool's most profitable coin and the coin the miner is mining. The sum of everyone's penalties is added together and then distributed equally across all the miners. Therefore, the best miners receive a bonus that causes them to earn what they would if they were mining now. The worst miners receive some penalty, but they are still assigned to the best coins for themselves, which are always better than just mining straight litecoins.
- The database has several new columns to track the work restart time, the work restart penalty, the pool's average work restart penalty, and each share's penalty or bonus. These columns required about 15 minutes each to add to Dev, so the downtime for the release will be around 1h.
- We are targeting a release of March 28.
- After this release, we will spend several weeks on optimization. The goal will be to get the pool as stable as possible, as fast as possible, and to subject it to abuse and security intrusions to ensure that it can handle at least 500GH/s on this server. Then, using some advice gained from JiveTonto, we will probably focus on the user interface.
- Some users suggested merge mining Viacoins, but we determined that doing so does not make economic sense. Profitability would increase by less than .01 cents, and that assumes that Viacoins are here to stay and won't be gone before we can even implement the feature. If that changes, we'll change our minds. To give a comparison, that's the amount of money that can be earned by reducing orphan rates by just 0.025%.
- We are looking at ways of cost-cutting to extend our capital a few extra months. We identified food costs and bandwidth as the two most important ways we can contribute to this. We are currently paying for a lot of bandwidth to the server, most of which is not needed. We'll reduce the bandwidth and increase it back later if a problem is encountered.
- We did not get to use kires's miners over the weekend because we weren't ready for them, but Chris will probably test with them today to see how bad the work restart problem is with Titans.