Prohashing Mining Pool Forums

Here's today's status:

• 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 few performance enhancements we did do only scratched the surface of what can be done. The more we look at the system, the more it confirms my belief that it's almost always better to optimize in software, rather than buying hardware to resolve a problem. I recall how, in 2006, there was a stored procedure in a SQL server database that used cursors to perform its operations. It took 45s to produce the schedule of radio commercials for a single station, and the network had thousands of stations. The bosses were ready to buy 10 servers to parallelize the process so that it would take only a few hours instead of over a day to do this scheduling. I told them to give me a week and I was able to rewrite the stored procedure to replace the cursors with huge SQL queries. The system could now generate one schedule in 300ms, rather than in 45s, saving the company an enormous amount of money in hardware.

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.

Which is why we all call Cryptsy, Craptsy. They couldn't run a wallet server to save their lives. Unbelievable that up until a few months ago, they didn't have a DR wallet server as a hot-ready device.