Giving Steam In-Home Streaming The Good Old Gamers Try
Steam's in-home streaming service just had its official launch, and with some configuration, it has the technical capability to be run as a users personal cloud gaming service. The premise is simple enough, rent a VPS (virtual private server), install Steam, create a VPN (virtual private network) connection with Hamachi, and stream games to a capable PC with reasonable bandwidth.
The server will provide a platform for hosting the games to be streamed. This makes it a good option for certain users for a few reasons. VPS providers typically offer several options for their machines with a range of prices with scalable hardware with little to no actual configuration from the user. Another upside is that VPS hosts often have higher network priority and bandwidth over standard consumer offerings.
The VPN through Hamachi will serve to connect the host machine to the remote client. To circumvent Steam's restriction of both computers having to be connected to the same network, Hamachi creates a virtual LAN connection even going as far as installing a driver for its virtual NIC (it's also quite handy for remote file sharing without having to set up a vulnerable externally-visible server).
Before getting into cloud streaming, let me first say that Steam's in-home streaming is a miracle of modern technology. Setup and playability is far above any other streaming service I've used in the past. This is largely because both the host and client machines are on the same network and latency stays within single digit milliseconds for the most part, though obviously your mileage may vary depending on how up to date your networking is and whether you are on a wired or wireless network.
Steam In-Home Streaming Testing
This is the setup that I used to try out Steam In-Home Streaming:
Streaming Desktop Computer:
- Custom built gaming PC running Windows 7
- Intel Core i7 2600k Processor
- NVIDIA GeForce GTX 670 SLI
- Dual-band Wireless N
- Gigabit LAN
- HP Chromebook 14 running Kubuntu 14.04
- Intel Celeron 2955U
- Intel HD Graphics
- Dual-band Wireless N
Both machines were updated to Steam's latest beta client and the client machine instantly recognized the host machine. All settings were left at default with the exception of enabling the hardware decoding to take advantage of Kepler's GPU encoding.
With the host and client machines set up, let's see how in-house streaming performs in practical application.FarCry 3 with wireless Host and Client (click to enlarge)[/caption]
[caption id="attachment_142613" align="aligncenter" width="645"] FarCry 3 with wired Host and wireless Client (click to enlarge)[/caption]
In Steam's streaming settings, users can enable an option to show streaming performance. In the top image, there's quite a bit of compression artifacts, screen tearing and latency made the game unplayable, and the game was maxing out at around 25fps at the Chromebook's native resolution of 1366x768. However, once switching the host machine to a wired connection, image quality was near perfect and latency was low enough for Steam to throttle the framerate up into the 50-60 range. Aside from the actual performance, there was a slight issue with Ubisoft's Uplay DRM. The login screen was up on the host machine without showing on the streaming computer, once returning to the host machine and logging in, the game picked up on the streaming machine as it should.Supergiant's Transistor ran almost flawlessly[/caption]
Transistor ran particularly well with only the occasional lag spike due to the use of a wireless connection and would most likely function perfectly with a wired host and client machine.
Testing then went in an interesting direction. Steam allows users to add other applications to their library. After adding Battlefield 4, launching through Steam on the host machine loads the Battlelog page for finding a match, but on the client machine, nothing happens. The client just launches Battlelog pages in the host machine's default web browser. Starcraft 2 similarly had issues launching. Blizzards game launchers are typically a patch window that starts the game. On the client machine the entire Windows 7 desktop of the host machine was visible, Starcraft 2 started on the host machine but only a black screen and a cursor was visible on the client. A few other more simple games and applications launched properly though, the original release of Cave Story, a few emulators, and even Notepad++(so even desktop applications are fair game for streaming).
Sidenote: There's supposed to be controller support for in-home streaming, but I had no response from mine. Perhaps using a Linux client is the cause of this, though my operating system was definitely showing that it recognized the controllers. Several games were tested with both an Xbox 360 controller and a generic USB controller, with neither being recognized by the host machine. Though it's likely to be added soon as the difference between transmitting keystrokes on a keyboard and button presses on a controller is not too drastically different.
Ultimately, in-home streaming is great if you have a network backbone that can support a reliable 10-20Mbit/s stream. Wired is absolutely preferable, but with the dual-band 802.11n wireless cards in our test systems the gaming experience was near-unplayable. Steam recommends using a wired network for the best gaming experience and we'd have to agree with that. If you wnated to try this on a wireless network we highly suggest using an 802.11 AC router that has a strong signal. (our recommended router)
Testing Steam In-House Streaming Limits With Hamachi
Now that we know in-house streaming generally works pretty well, it's time to stretch its limits. Using LogMeIn's VPN software Hamachi, it's possible to bridge the connection between two machines that aren't on a single local network. Hamachi has an official release for Windows and OSX as well as a command line beta client for Linux. Hamachi setup is pretty straight forward: make a network, create a password, join network with desired machines. So what kind of requirements are necessary for streaming a game from your host to a remote client?[caption id="attachment_142623" align="aligncenter" width="640"] Transistor's Stream Data[/caption]
Note the Incoming bitrate above. In order to push out 60fps @ 720p remotely, the host machine going to need ~13Mbps in available upload bandwidth. Or you have the option to do a significant level of network configuration to try and pass the stream at a higher priority or at one of Steam's built in bandwidth limitations, ranging from 3-30Mbps.
Sidenote: The image above also shows that Steam prioritizes input latency over display latency, and even with a fair amount of button-mashing, the Outgoing bitrate is staying below 100kbps. Hence, for this experience on a remote machine, the remote client will require at least a 13Mbps download speed and should be fine with even a 1Mbps upload speed.
With Hamachi setup and installed on the host and client machine, the client machine was moved to another network approx. 10 miles (or 16km) from the host. The first immediate issue was with the Linux Hamachi client, though it connected to the VPN, the Steam Linux client (that had previously recognized the host machine while testing on the same network) was not connecting to the host through Hamachi. However, upon switching to a Windows-based client machine, the host was recognized through Steam. Unfortunately, it looks like Hamachi's Linux Beta is a Beta for a reason.[caption id="attachment_142638" align="aligncenter" width="640"] Windows Client Stream[/caption]
Transistor was started on the new Windows client machine once the Hamachi/Steam connections were made. Unfortunately, thanks to Comcast, our host machine's upload speed is a paltry 5Mbps. As such, Transistor launched, but only to a black screen. Although unplayable, this means that the Hamachi method does work, and the latency is actually not far above the in-home streaming latency (again, largely dependent on the end users current network situation).
To circumvent my bandwidth limitations, I turned to cloud hosting.
Renting an NVIDIA GRID Server from Amazon Web Services
NVIDIA has several partners that offer VPSs which utilize their GRID technology. Amazon Web Services was chosen for testing based on their low price($0.76/hr) and the ease of setup. In the AWS marketplace, Amazon offers a GRID instance powered by 8 Sandy Bridge Xeon cores, 15GB of RAM, 64GB hard disk storage(expandable for $.05/month), and a Kepler GK104 GPU with 4GB of VRAM and 1,536 CUDA cores (essentially a 4GB GTX 680). Amazon also provides a decent amount of bandwidth with speed tests ranging from 100-240Mbps down and 30-70Mbps up![caption id="attachment_142640" align="aligncenter" width="645"] NVIDIA GRID on AWS[/caption]
Keep in mind, charges will be accrued for the time that the server instance is powered on. So an end users options would be to turn the server on/off per each gaming session, or rack up the full cost of ($0.76*24 hours*30 days) coming out to a brutal $550.00 bill for a month.
Sadly, it quickly became clear that this was not going to be an easy process. Amazon has these instances locked down like Fort Knox in the name of security, with limited permissions given to the end user. After two hours of configuration and installs, Steam and Hamachi were finally setup and ready to go. The Windows client was set up and the machines were properly recognized through Steam. With FarCry 3 installed on the server, the client attempted its first launch.[caption id="attachment_142635" align="aligncenter" width="645"] Server Error[/caption]
However, the system reported that the screen was locked. After realizing the instances Remote Desktop window was still open and closing it, the server's connection to Hamachi dropped. For some reason, the server disables only the Hamachi virtual adapter while not connected via RDP. Since the Hamachi connection and drivers aren't actually applied to physical hardware, there's no power options involved. I can only assume that the problem lies in the ports that Hamachi uses being curiously closed only while RDP isn't open.
Final Thoughts on Steam In-Home Streaming
Ultimately, if your goal is to stream your entire PC library to a machine on the go or other off-network locations, the truth is that it's entirely possible! From our testing with Amazon's Web Services though, it seems as though the best option is to use your own private machine with Hamachi rather than spend the kind of time and money it would take to roll a personal cloud gaming server. With the rate that consumer level service is growing towards gigabit cable, and the current cost and complications of getting a functioning remote implementation of in-home streaming, it's unlikely that the setup attempted here will ever be a more viable option that simply wiring a home network, upgrading network hardware, and upgrading in bandwidth.
To sum up our findings here:
- Off-network play is possible via Hamachi (on Windows and OSX).
- Non-Steam games are streamable.
- 10-15Mbps is a likely minimum for upload bandwidth of the host machine.
- Conversely 10-15Mbps is a recommended minimum download speed for the client machine.
- Users are obviously more likely to experience latency issues through WiFi or remote Hamachi streaming.
- There seems to exist no cost-effective way to create a private cloud gaming server.
That last point is not to suggest that cloud gaming is unrealistic in general. Steam In-Home Streaming and PlayStation Now, are clear indicators that there's market interest in cloud gaming. But in my opinion, it seems like there's still a few innovations in encoding, decoding, and latency management that will need to happen before people start replacing their local gameplay setups with cloud-based solutions.
If you have any thoughts about Steam In-Home Streaming be sure to leave them in the comment section below.