OnLive Gaming Service Gets Lukewarm Approval

Vigile writes "When the OnLive cloud-based gaming service was first announced back in March of 2009, it was met with equal parts excitement and controversy. While the idea of playing games on just about any kind of hardware thanks to remote rendering and streaming video was interesting, the larger issue remained of how OnLive planned to solve the latency problem. With the closed beta currently underway, PC Perspective put the OnLive gaming service to the test by comparing the user experiences of the OnLive-based games to the experiences with the same locally installed titles. The end result appears to be that while slower input-dependent games like Burnout: Paradise worked pretty well, games that require a fast twitch-based input scheme like UT3 did not."

Comments

Yet another infomation-free summary...

[Anonymous Coward]

The guy logged in using credentials 'borrowed' from an authorised beta tester, from more than twice the recommended distance from the server, acknowledged multiple high latency (due to distance) notifications, and the best he could do is damn the service with faint praise.

Re:Yet another infomation-free summary...

[Anonymous Coward]

". After all, playing on the internet isn't as quick as a "LAN frag fest", and yet the vast majority of gamers, even of twitch-heavy games, are playing on the internet, not on LANs."

With tons of client side prediction and faking trying very very hard to hide the client-server lag.

With OnLive, you can't do that - it just sends some inputs and gets some video back.

I mean, this could work under optimal, super fast network connections, but I'm pretty sure ensuring you have such a connection would be so expensive that this is a solution to a problem that doesn't exist - it is always cheaper to spend the money on client side hardware instead. I'm sure stupid venture capitalists will keep pumping money into this with idiotic projections how bazillion people will pay X dollars per month or hour or whatever that will somehow cover those network infrastructure costs.

I doubt it will and few years from now OnLive goes bust taking a big pile of money with it, but hey, you never know... can't do impossible stuff without trying.

Re:As expected

[mseeger]

Hi,

If say the speed-limit on a motorway was 70mph, and there was no congestion on the road; why would adding in extra lanes to the motorway increase how fast I get to my destination?

You get the car analogy wrong. A packet of 100 bytes is not similar to a single car. It consists of 800 cars (bits). So if you increase the number of lanes more cars can travel. Each car travels still the same speed (of light) but by allowing more cars at the same time, the delivery (packet) distributed over 800 cars gets delivered faster.

The time a packet takes to get transmitted is roughly: packetsize/bandbidth.

Say you have a 10mbps line and a 1000bytes packet. This will take 8000 bit / 10.000.0000 bit / s = 0,00008 s or 0,8ms (one way). So the latency through the line will be roughly 1,6ms. If you got to 100mbps ethenet or even gigabit ethernet, the time will go down by factor 10 each step.

But there are some side effects: Sometimes packets are packed into larger packets to fill the line better. This will increase the latency. When the speed of the line is high, the time the OS needs to send/receive the packets gets more influence on the latency. Also the latency may occur in your providers network because he overbvooks the service (selling access for more cars than the lanes allow and therfor creating congestion).

To see wether your line is the chokepoint use Traceroute to see where the latency happens. If the latency already occurs close to you, a faster line may improve the latency. Also look for features from your provider as "fastpath".

CU, Martin

P.S. This is a very short overview of the topic. A complete coverage would come as a book. BTW the books have already been written: Richard W. Stevens: TCP/IP Illustrated.