A Technical Deep Dive

Hi Folks,

I'm considering shutting the service down due to lack of interest, but before then I'll try putting it forward once more since I still do think some folks would find value in it.

Let me start with that I've hosted missions with the Flying Kiwis squadron for over a year now, about 3 times a week each for about 3 hrs a session averaging around 15 pilots. The average bill I get each month from Amazon is about $60 (which TFK have graciously shared passing the hat around). I'm ok with this when I compare to just renting a physical machine at $100. If I were my own customer though this figure would be closer to $20. The difference is the fixed operating costs, which would be offset by more folks using this service, or would come down if I stopped trying to share this service.

ready-room.net is hobby project. In my opinion this market is too niche for it to be a serious venture. It would be nice though to pay a little less for my own DCS hosting, and potentially get a few bucks back as well for my efforts.

Way back I thought I saw an opportunity for this kind of service when I noticed there were always a large number of servers in the lobby with no pilots. This is just a waste of resources and we can do better. The other thing was that TFK (The Flying Kiwis) typically hosted in Christchurch. Awesome for all the folks in Christchurch, but being in Brisbane it was not so great for me. Looking at https://www.submarinecablemap.com/ my signal would have to travel via Sydney and Auckland to get there and back. So I decided I'd host in Sydney and ask the Kiwis to meet me in the middle.

I think folks might be reticent with the thinking that AWS compute can't compete performance wise with a physical machine. There are some challenges to running DCS in this environment and I've had a few false starts, so I'll do my best to explain with a technical deep dive. The basic dimensions of compute resources are cpu, memory and io (disk / network). The relative demands an application will have for each of these resources to reasonable extent depend on how the application has been programmed. Getting the most from compute given an application consists of running the application, observing what resources are being used and making changes to suit. For example if cpu is being used near 100% of the time, we can add more cpu resource until the application no longer has enough work to keep the cpu occupied at that level. After that point there is no additional value in adding more cpu.

Anyway I learnt fairly quickly that the limiting resource was actually disk io. In DCS we experienced stuttering, which could be correlated with spikes in disk activity. The default disks in AWS are a type of network disk, i.e. they aren't co-located with the memory and cpu in the same chassis, but are still local to the datacenter and connected via the local network. Swapping to SSD storage local to the chassis was all that was required. I've experimented with different compute sizes, but regardless of the size DCS never seems to make full use of the available cpu or memory. So the smallest compute that comes with local SSD storage has turned out to be the most economic option.

Network disks are the default because they are easy to connect to any compute in the datacentre. The impact of using local SSD storage instead is that the data lives only as long as the compute resource is provisioned. In other words DCS needs to be installed from scratch each time. Because the DCS installer sources compressed data via torrent download, installation from scratch via the installer takes around an hour. Partly from the time to download and partly from the time to uncompress.

The strategy used to reduce installation time is to maintain the uncompressed game assets in the local datacenter, and then directly copy to the local SSD when the compute resorce is provisioned. In conjunction with inspecting the .miz file and copying only the terrain data required for the mission, this strategy brings installation time down to a few minutes. With a few minutes to provision a compute resource and start windows, a few minutes to install DCS and a few minutes to start DCS, the total time to stand up a DCS mission is kept to about 10 minutes.

Maintaining the uncompressed game assets is a fixed cost, and is a few bucks per data center, per DCS version, per month. The other fixed cost is the web service at ready-room.net that accepts the .miz file and starts the mission at the requested time in the requested datacenter.

So if you're looking to host DCS for your group in a central location to lower ping, or your dedicated server is expensive and you're looking for a more economic alternative - consider trying ready-room.net

Cheers,

Noisy

Tags

• aws
• hosting