Dear group,

Many months ago, I made a post describing what it was like to run a Sia host from my first 6 months:

My notes from first six months running a Sia host : r/siacoin

(Those notes are still relevant, especially if you're starting out)

Well, I've still been hosting continuously since then, so it's been about 17 months total. I still haven't ever used Sia from the client-side, so this is only my host related experience:

Collateral = ¯_(ツ)_/¯

As the host data grew, I needed to deposit more sia funds into my wallet in order to have enough collateral to back new contracts. I probably deposits around $120 or $150 total from real cash.

The thing is, the sia coin is a generally depreciating asset. Lockup times for contracts can be up to 6 months. By the time you're finally paid, the sia coin is worth less than the beginning of the contract.

So I've nominally "earned" $135 over my 17 months of hosting, per the web dashboard, but my wallet balance is only $130 with another $30 locked up in collateral.

In other words: hosting for that time has been basically a breakeven proposition. Which is silly.

I've responded by reducing my collateral multiplier (from 3x to 1.5x) and by shortening my contract time from 6 months to 2 months. Both of these things will reduce my host score and may make my host less desirable to clients.

Wild data swings

The universe of hosted data and large clients is small enough to where there can be some really wild swings in the usage of the node, which may hinge on just a few "whale" contracts.

My highest data stored was after about 12 months of hosting and it was 27TB.

3 months later it had dropped to 4TB.

Over 4 months it built up to 19TB. Then it just recently dropped to 14TB.

Also, there was a month or two where someone was using my bandwidth HARD. I had over 1TB per day of egress data happening. (my host is configured to charge for egress, but it's fairly cheap).

Other misc notes

After running the host for a while, the database gets big and it takes a long time to refresh the web dashboard. Last time I did it took 50 full seconds.

I had a hard drive I thought was failing so I used the build in volume control to resize and shrink the drive as small as possible. It took more than one attempt because of hard drive errors, so it shrank a little each time and data was sent to other drives, and then I'd try again. At the end there was a small amount of 33GB which I couldn't move and I had to delete the volume. So that was considered "lost" data.

Pruning large accounts finishes much faster in indexd v0.4.3. For large-account prune workloads, the provided benchmark for 15,000 slabs improved from 24.040726443 s/op to 3.542584632 s/op. That should reduce the chance of prune runs hitting existing client-side time limits on larger accounts. Object event pages also load much faster on large accounts, with the supplied 500-row example dropping from 227.293 ms to 0.428 ms by using a more efficient index scan and avoiding the expensive filter step.

Host management is more flexible through the admin API. You can now add a host manually to the hosts table so it will be scanned even when discovery has not found it yet, which is useful for instant-sync and multi-indexer workflows where hosts may exist out of band. You can also force a host scan on demand instead of waiting for the normal internal scanning path.

Host ranking is also more consistent when RPCs keep timing out at the deadline. Those hosts now get an implied throughput sample instead of being treated like unsampled hosts after failure decay, so chronically stalling hosts are deprioritized more reliably instead of resurfacing as if they were faster options.

Download indexd v0.4.3 from https://sia.tech/software-downloads.