Onlive

[Shannow]

claiming it's impossible is just as stupid as claiming that people will never be able to fly

Show me at least a single flying human and I will stop calling OnLive a hoax forever.

http://www.youtube.com/watch?v=yge311sFhC8
Does this count?

 

[Xi]

My point of the "flying human" was that airplanes eventually came into existence. So while people don't fly like superman, they eventually did fly in the air. Just in the same way that not understanding a way to solve input lag and network latency does not mean there is no way to do it.

I hav no technical knowledge for how it is done, my point is that you cannot prove it's impossible, just like I cannot prove that it's possible. However, I can prove that at least a few companies and industry minds believe it can be possible. They also have funding, a functional system to showcase, and backing from major publishers. That tips the burden of proof in favor of "It's possible" more so than it's "Impossible."

Possibility often defies the perception we have of reality, but just because you cannot perceive a possible way, do to input lag and latency, does not make it impossible. In fact, it seems likely at this point even if the outcome is mostly unknown. Will it be well received, will it work well enough to give up our expensive PCs and switch? Who knows?

 

[Xi]

http://arstechnica.com/gaming/news/2009 ... erence.ars

MIT is playing host to Technology Review's EmTech conference, which focuses on up-and-coming companies and the new technology they're bringing to market. Steve Perlman, the founder and CEO of the OnLive gaming service, was given the chance to demonstrate his company's cloud gaming service, and took some time to explain the technology backing it. OnLive is gaming's answer to cloud computing: the applications run on hardware in a server farm, while users only need low-end hardware (including OnLive's own mini-console) and broadband Internet to connect in and play. The service will have some limitations, however, and your experience may vary with network speed.

For starters, Perlman gave some indication of the network requirements for it. Anyone with a 1.5Mbps connection should be able to run the service at standard definition; 5Mbps will be required for HD content. Although bandwidth will be critical, low latency connections will be necessary to avoid hitting the user with perceptible lag. OnLive has found that the server has to be within about 1,000 miles of the end user in order to avoid this. As such, it will be launching the service with four server farms.
Another impressive tech demo

For the purposes of his demo, Perlman connected to a server farm in Virginia. MIT clearly has access to some pretty significant pipes, but the quality of the demos, which included some time showing off an arena in Crysis, was very impressive, given that it was running on a standard MacBook Pro. All sorts of environmental features, from bubbles generated while swimming to crabs scuttling along the beach, were fluid, and provided a very immersive experience. Perlman joked repeatedly about his poor gaming skills as he rushed to show the audience as much as possible before one of the experienced beta testers blew him away.

He also gave a short rundown of the service's additional features, like the ability to save clips of games that can be shared with others. There's also an arena, where people can enter a game environment that someone else is playing and watch how they experience the game. Although these are presented as end-user features, Perlman pointed out that they could provide significant benefits for game developers that could follow along as users flail through problem areas or expose bugs in the software.

Perlman was willing to talk briefly about the hardware that powers things at the server level. The basic functional unit is a standard PC motherboard. Casual games get by on built-in video, while they'll be using motherboards with high end hardware from NVIDIA and AMD for the current generation of games. The only custom hardware is a single add-on board that handles both compressing the video for transmission to the end users and smoothing over the inevitable network hiccups.

Beyond the broadband connection, all the end user needs to be able to do is handle input from controllers and display video, neither of which is especially demanding. That goes a long way towards explaining why OnLive can get away with a miniconsole that appeared to be somewhere around the size of a portable laptop hard drive.
PC gaming's audience could be broadened

The pitch to the gaming audience is obvious: no more platform exclusives and a step off the perpetual upgrade treadmill. Whatever you happen to be using, it'll be good enough for OnLive's service. But Perlman also pointed out that there are significant advantages for game makers. A single game can now run on any platform out there, greatly increasing the audience and eliminating porting issues. Since the actual software never goes out to the end users, piracy is essentially a nonissue. Perlman also noted it could kill the secondhand game market—although users might not appreciate that, the publishers will.

The porting process is also extremely simple. Perlman said it typically takes OnLive three weeks and one engineer to handle the process, most of which involves eliminating dialogs and keyboard commands that assume the user is running the game locally on their own hardware.

So far, OnLive has nine major game publishers, including EA, THQ, and UbiSoft, on board.

Will it actually work? The basic principles seem solid, and Perlman was apparently involved in developing the QuickTime video platform, so he appears to have the right experience to put things together. But the ultimate determinant may not be the technology that OnLive has control over. Instead, the local ISPs and home network may have a tremendous impact on whether the games are even playable, much less immersive.

You can sign up for beta access to the service right now, although OnLive gently told Ars that journalists are not, at the moment, being extended invitations.

 

[Overweight Manatee]

Monitors with input lag of 40-50 ms or more are considered unbearably bad for gaming. You want to add in another 100-200ms on top of that? It won't be remotely playable. Is the speed of light barrier going to make an exception for onlive gaming?

 

[Xi]

Monitors with input lag of 40-50 ms or more are considered unbearably bad for gaming. You want to add in another 100-200ms on top of that? It won't be remotely playable. Is the speed of light barrier going to make an exception for onlive gaming?

Although bandwidth will be critical, low latency connections will be necessary to avoid hitting the user with perceptible lag. OnLive has found that the server has to be within about 1,000 miles of the end user in order to avoid this.

 

[Berekän]

The question is not "Is it possible?", it is "Should we allow it?"

 

[vrok]

This is a pretty good troll thread. Copy paste some more PR announcements please.

 

[Overweight Manatee]

1000 miles still gives you far too much input lag. More then 15-30ms and things will be very bad. Sorry, there are fundamental limits to the internet that you can't change.

If you know how, use a remote desktop program to connect to another computer and try to play something over even a few miles. It has a very perceptible lag. Its a fundamentally unworkable solution. Onlive will have to wait until we have figured out how to breach the speed of light.


Even if it did work, the onlive centers would have to be so concentrated that it wouldn't be a cloud system, just a dedicated nearby server. One that you have to pay for with your money, along with paying for the company and housing for the servers and tons of other BS. No benefit over owning a computer.

 

[Xi]

All you people without any solid technical knowledge, who are also debating the tech, make me laugh. You know nothing of how they do it. If such limitations were too great, they'd have canned the project long ago. Yet, here we are years later, millions in funding, and a functional beta test under way. Release isn't far off.

 

[ecliptic]

When did this place just become a troll-farm? Oh well.

 

[Black_Willow]

About seven years ago.

 

[Elzair]

OnLive reminds me of all those "Game Channels" in the early-mid '90s. They all died, and OnLive will likely die too.

 

[Gerrard]

 

[Xi]

MIT's review of the technology that powers OnLive.

http://www.technologyreview.com/blog/emtech/24151/?a=f

Watch the video. It explains how they're able to maintain at most an 80ms connection with the user.

 

[MetalCraze]

My point of the "flying human" was that airplanes eventually came into existence. So while people don't fly like superman, they eventually did fly in the air.

No your point is just silly. There were things that fly in the nature and planes are built by the same aerodynamic principle. There are no things however that travel faster than the speed of light.

Just in the same way that not understanding a way to solve input lag and network latency does not mean there is no way to do it.

No there is no way to do it. You can't go faster than optic fiber will let you - and provided you have some mythical way of sending data faster - you will be needing to install that system all over the world or at least US for starters. Noone involved in OnLive-hoax has so much finances or technological means to do so.

I hav no technical knowledge for how it is done, my point is that you cannot prove it's impossible, just like I cannot prove that it's possible.

I can easily prove that it's impossible, any at least somewhat tech-savvy person can.
To give you at least more or less the same experience as you would've had directly on your PC OnLive will need to receive input from you and send you one full uncompressed frame every 15ms without errors. Now let's say you want to play the game in 1920x1200, 32 bit color depth. That's 4 bytes per pixel. 1920x1200x4 = 9216000. That's 9 megabytes every 15 milliseconds or 540 megabytes every second. That will require you to have 4 gigabits/second channel with a latency 15 ms or less just to see FullHD. And that's only for images. Add to all that stuff like other service data, audio data and whatnot. Why uncompressed? Because when compressing you will lose quality (meaning it will be worse than the image in a game installed on your PC) and you will need very very fast CPU for decompression (which will be able to decompress the image in less than 1ms as not to cause an additional lag) - which kinda beats the whole OnLive point of not having superPC at home. Now add to that that OnLive will have to provide services to a million of users at any given moment at a speed of 4+ gigabits/s per user with a latency of <15 ms. They will also need a cluster of a million (let's say $1000 PCs provided they will get offs from nvidia, intel for buying en masse or whatever etc) - that's $1 billion just to build cluster. They will also have to hire shittons of people to maintain it and spend hundreds of millions of dollars constantly upgrading it. Where will they get such technology or money?

Any person with at least some brain mass will say: nowhere.

Now the idea of MMORPG-like DRM where only scripts are being processed on the server with special hardware protection (that OnLive modem) sounds much more real.

 

[coldcrow]

Actually it is easy to see how they will do it. There are several algorithms and experiments for how the brain constructs images out of sensory input with the result that the brain doesn't need full frames to construct a fluent experience.
That will reduce the traffic by a significant amount. What I don't really understand is how they will cope with the input lag. A usual yery good connection to a server has a delay of about 20ms. That is a 40 ms input lag which is imho detectable.

 

[Armacalypse]

All you people without any solid technical knowledge, who are also debating the tech, make me laugh. You know nothing of how they do it. If such limitations were too great, they'd have canned the project long ago. Yet, here we are years later, millions in funding, and a functional beta test under way. Release isn't far off.

Says the guy who seriously considers faster-than-light tech, developed to apply for gaming. Maybe it's better to save up for a technological singularity Xbox instead, what do you think?

MIT's review of the technology that powers OnLive.

http://www.technologyreview.com/blog/emtech/24151/?a=f

Watch the video. It explains how they're able to maintain at most an 80ms connection with the user.

Hey guise, we worked seven years on spaceman technology. We PROMISE there won't be lagg (only 80ms or so but that doesn't count...).

If my monitor suddenly got 80ms delay for even a moment I'd flush it down the toilet.

 

[MetalCraze]

Actually it is easy to see how they will do it. There are several algorithms and experiments for how the brain constructs images out of sensory input...

Yay! So you will be able to play OnLive in your imagination!

 

[Xi]

http://www.onlive1.com/showthread.php?t=155

 

[Xi]

http://www.joystiq.com/2009/06/03/impre ... th-onlive/

In summary, the thing works. Games load and play fairly quickly, we didn't have any hardware on-hand other than the microconsole and their controller, and no physical media like game discs or files. Although the speeds indicate almost full usage of a low-end cable modem connection, which are below normal DSL levels, so you're probably going to use cable if you plan on getting on this service. OnLive is in the process of rolling out a closed beta, and we're hoping to be a part of the open beta later this summer. Stay tuned. Or live. Either way.

 

[MetalCraze]

I see you are opening the magic world of PR bullshit from prestigious gaming magazines for the first time in your life.

 

[Black_Willow]

Actually it is easy to see how they will do it. There are several algorithms and experiments for how the brain constructs images out of sensory input...

Yay! So you will be able to play OnLive in your imagination!

Isn't this the point of the whole thing? That's what Xi is doing.

 

[Xi]

 

[Xi]

Chris says, “the thing that might fundamentally change the industry, for the artist to get more control, is if the artist community could become more proficient at business and control the money.” I’m happy to say that we’re all moving in that direction and OnLive is the platform that can make that happen.

 

[Xi]

To the user, OnLive is exceptionally easy to use: The latest high-end titles are available on PC and Mac (via a small browser plug-in) or on TV (via the OnLive MicroConsole). Games startup instantly. There is no physical media, no downloads, no patches, no updates, and no high-end hardware is needed to play the games. Pretty much any XP/Vista PC or Intel-based Mac will work. And, you never need to upgrade your PC, Mac or MicroConsole™: you’ll continue to be able to play increasingly higher performance games on your existing PC, Mac or MicroConsole.

But to achieve this level of simplicity, “behind the scenes” OnLive is an immensely complex computing system. It’s a type of computing system called a “cloud computing” system, because computing occurs in a data center within the Internet (aka “the cloud”). But, OnLive is a cloud computing system that is quite different. In this post, we’ll explore one of those differences: how in a typical OnLive session you use many different computers (called “servers” because they are in data centers), and how you seamlessly transition from one server to another.

When you are using OnLive, while it seems like you are using just one immensely powerful server that is constantly providing a non-stop video experience, nothing could be further from the truth. Actually, from the moment you start up OnLive you are using many servers working together in a myriad of different ways, sometimes with a server dedicated to your use, sometimes sharing a server with other users, sometimes using several servers at once, and sometimes a combination of some or all of the above.

For example, let’s consider a typical user who tried out OnLive at the Game Developer Conference and played for five minutes (say, navigating the user interface, playing a few games, snapping and watching Brag Clips™, and spectating other users playing). Given that range of activities, the user easily used more than a dozen servers at different times. Just to identify a few: some OnLive servers ran (i.e. “hosted”) particular games, other OnLive servers hosted the user interface, and others handled the distribution of spectating video streams and Brag Clips.

As the user transitioned from one experience to another (e.g. clicking in the user interface to start a game), OnLive would “hand off” the user from one server to another, transferring the “user state” (e.g. all the data unique to that user, including the live characteristics of the Internet connection) from the user interface server to the game server, while switching the live compressed HDTV video/audio from the user interface server to the game server. And, all of this occurred on a video frame boundary. So, from the point of view of the user, it seemed like the video was just continuing onward from the user interface video to the game video as if it was running on the same server. In actuality, it was seamlessly handed-off from one server to the next.

And, when using OnLive, you are using even more servers than just the ones you transition to. For example, massive spectating (when you watch lots of thumbnail video windows of live games being played) is tapping into “IP Broadcasts” (i.e. data broadcasts over OnLive’s internal networks) of the live video generated by many different servers hosting many other users. And, when you play back a Brag Clip, yet another server is handling that for you. So, one question you might ask is, why does OnLive go to all of this trouble to transition users around from server-to-server? There are 4 main reasons: 1) many things (e.g. massive spectating) simply can’t be done with one server, 2) it allows us to always provide users with state-of-the-art performance, 3) it dramatically lowers our cost of operations, and 4) it dramatically reduces power consumption.

For example, if a user decides to play a very high-performance game, the user will be transitioned to a very high-performance server that can handle the game. If the user is running a lower-performance game, then the user will be sent to lower-performance server (OnLive has many classes of servers), and, in the case of many games, we can have more than one user share a single server without any impact on gameplay (“real-time virtualization”).

Every six months or so, we install new servers with the latest GPU and CPU technology, able to run the latest most advanced games. But the older servers are still fine for running lower-performance games (or, say, the OnLive user interface), and users never know what server(s) or shared servers are hosting their games. Needless to say, this not only gives gamers access to the very latest gaming hardware, but it also dramatically reduces OnLive’s costs of operation since, at any given time, many users are playing games (or in the OnLive user interface) and require less than state-of-the-art performance. And, from a user’s point of view, the experience is always fast and high quality because each game plays on a server providing the level of performance required. But of course, behind the scenes, OnLive transitions the user seamlessly from server-to-server, leaving the user with the perception of simply having one incredibly high performance and flexible computer.

Finally, OnLive consumes far less energy by only providing each user with as much computing power as is needed for the particular task the user is doing. Not only is this good for the environment (particularly if the user is using an OnLive MicroConsole in the home, which only consumes about a few watts), but it also further reduces OnLive’s costs of operation. Good deal all around.

So, OnLive not only provides you with far more computing power than any single computer or console when you do need it, OnLive provides you with far less computing power when you don’t. Gameplay is always state-of-the-art, but cost of operations and energy consumption is minimized.

I hope you found this OnLive tech overview interesting. As you can imagine, designing and building this technology was really fun. It’s rare to have a chance to design a mass-market system based on a completely different view of computing, yet one that provides an experience to the user where all of the complexity and tricky engineering is invisible.

More cool tech postings to come…

—Steve Perlman, OnLive Founder & CEO