Verbaltech2 - BitShares Witness Report

Sorry folks, a couple of days late this month on this report. Regarding hindsight of the BTC HF, dammit, rather than pulling out of Bitcoin I should have been all in to gain some BCC. Oh well. At least I averted a potential catastrophe. Here is the market summary since last month: (all prices via CMC): BTC=$4567.95, BTS=$0.139, STEEM=$1.36, PPY=$6.18.

This month I began to focus on improving my skills at python programming. There's nothing unusual about the python language really, it's just a matter of familiarity with the various libraries available and putting in the hours to gain experience with it. I'm programing a simple Internet Radio application as a starting project, and I also dug into bts_tools code to discover why I was having difficulty getting it to work on the testnet server. I submitted one minor pull request to @wackou's github as a result. I will next turn my attention towards pybitshares by @xeroc, with an aim to implement automatic failover protection. Other BitShares witnesses claim to have coded such protection, but I have some concerns I need to find a way around. Will be a good case to test on the testnet.

I also ran an experiment on one of the 32GB BitShares server nodes to see if I could re-enable full history to support a public API service. That entailed removing the track-accounts and partial operations options and restarting / resyncing the node with the blockchain. I should have taken a pic of the memory stats to include in this report but it didn't occur to me at the time. However I determined I will need to upgrade the RAM on all of my nodes, or at least 2 of them, to provide full transaction history for a useful API service. Now that the BTC HF is behind us and stability in BTC is good (for now at least), I can evaluate upgrade options. I've yet to find a good provider of dedicated servers in the Australian / Singapore region.

With full history enabled RAM usage on a 32GB node was just barely enough. I observed swap utilization during the replay to get re-synced, and more than 30GB thereafter according to "top" and wackou's bts_tools. I played around with the config settings but I couldn't find a way to reduce RAM use significantly. I think at least another 8GB is necessary and I would probably go to 48GB to provide a wider margin of reliability. If you are a BitShares witness I'd appreciate any input you can provide on your server's RAM use, and whether you run a public API node. At least I have the load balancing in place, but I haven't published the URL for it and won't until I upgrade the RAM in at least 2 servers.

The testnet server is humming along, running on the BitShares testnet as well as providing a Peerplays node running on the live, production PPY chain until they announce a PPY testnet. I am also running 2 separate instances of bts_tools on that server and have seen no problems.

That's about all I have to report this month, so here are the graphs of all the nodes in operation for BitShares:

France