- We are now spending all of our time on stability, performance, and profitability enhancements. This weekend, we concentrated on profitability.
- The first profitability improvement will be dealing with markets where there is low depth. In the past, profitability would be promised that was unattainable in some cases because sell orders get pulled by the time the mined blocks confirm. Now, the depth of a market is measured against both a dollar value and the average size of the last blocks, and markets are placed into error if both metrics indicate that the market is too shallow. This provides further protection against those bots that, for unknown reasons, are always placing worthlessly small buy and sell orders.
- The second profitability improvement dealt with the possibility of daemons forking. This problem is almost entirely limited to Cryptsy. Because of their poor customer service, their blockchains often fall behind by thousands of blocks. In the past, $100 of coins might be mined but be unable to be sold because Cryptsy's blockchain was behind. Cryptsy rarely replies to tickets, but this fix will detect when Cryptsy's chains aren't confirming our blocks and error Cryptsy out until they resolve their problem.
- We resolved a problem where blocks were not submitted for a coin on one of the new servers. This cost about $50 in losses Friday, but those losses were not passed on to customers.
- We stopped the system from trying to execute sells when the trade value was so low that most of the trade would be eaten up in fees.
- We modified a stored procedure that is called one time per second so that it requires one disk write instead of two, in an attempt of reducing transaction log size.
- We realized that the orderbooks were being gotten twice (for buys and sells) when they only needed to be gotten once, with the other type of data being cached in memory for when it was needed later.
The other problem with hardware that I always try to avoid is that unlike software, hardware is difficult to maintain. We have our code and can fix bugs in our optimizations and deploy it remotely. When you have a lot of hardware, at least one of the servers is likely to be failing at any time. Broken processors or network cards don't print out error messages on their motherboards. You don't have access to the code or any internal workings of hardware. You have to be at the physical site to deal with broken hardware. And hardware is a one-time improvement, while software, once improved, can be improved again.
In fact, most of the exponential advance in computing over the past 30 years has been due to improved software, not primarily due to improved hardware. Even though CPUs are in a lull now until the next process comes out in 6 months, software continues to improve at a rate far faster than Moore's law.
