OnLive Latency Tested 204
The Digital Foundry blog has done an analysis of recently launched cloud gaming service OnLive, measuring latency across several different games. Quoting:
"In a best-case scenario, we counted 10 frames delay between button and response on-screen, giving a 150ms latency once the display's contribution to the measurement was removed. Unreal Tournament III worked pretty well in sustaining that response during gameplay. However, other tests were not so consistent, with DiRT 2 weighing in at 167ms-200ms while Assassin's Creed II operated at a wide range of between 150ms-216ms. ... OnLive says that the system works within 1000 miles of its datacenters on any broadband connection and recommends 5mbps or better. We gave OnLive the best possible ISP service we could find: Verizon FiOS, offering a direct fiber optic connection to the home. Latency was also reduced still further simply due to the masses of bandwidth FiOS offers compared to bog standard ADSL: in our case, 25mbps."
Bandwidth != Latency (Score:1, Insightful)
Head - Desk... (Score:3, Insightful)
Latency was also reduced still further simply due to the masses of bandwidth FiOS offers compared to bog standard ADSL: in our case, 25mbps.
Damn it, kids, Latency and bandwidth are not the same thing and anybody who makes that mistake should be forced to use a "1Gb/s" connection via fedex.
Yes, in the case of something like OnLive, which is basically streaming mouse/keyboard events one way and video the other, things will look substantially worse if frame N hasn't finished downloading by the time frame N+1 is ready for transfer(and then either has to be dropped, or delays frame N+1 even more than your connection's latency would); but having a fat pipe does not "reduce your latency". It is correct to say that 25mb/s FIOS is probably about the most generous test that is also remotely realistic for more than a tiny number of their potential customers; but the bandwidth thereof does not "reduce latency"...
Re:And that means...? (Score:5, Insightful)
150-200 ms latency in a modern FPS is nearly unforgivable. I played TF2 a lot for a while and if I ever had more than 40-70 ms latency the hit detection would start to suffer and you'd get shot through walls or just not hit.
I expect a system like OnLive might work better with strategy games and other types of games that are not nearly as fast paced as most modern shooters are.
Stupid (Score:2, Insightful)
You had a good business model. A lot of people would be happy to play games that can be played with lag without noticing (I spent hours on Puzzler World, Max and the Magic Marker, Crayon Physics, World of Goo, Age of Booty, all sorts of games that aren't that affected by lag). You could easily have had a Wii-like console in every home that delivered as powerful a game as necessary, against as many players as necessary while needing no fancy installation, discs, etc. and most importantly NEVER needing an upgrade. Specifically, I would compare the system to those arcade machines that let you play, say, 20 minutes of Super Mario World or some other Nintendo games. You pay a flat fee and can swap between games as much as you like during that time without having to install demos, or buy them all. Brilliant idea.
Instead you didn't listen to the only criticism of the idea (enormous lag is inevitable - yeh cannae break the lawsa fisics...), wouldn't heed it, denied there was any problem, etc. and thus in the first, purportedly "ideal" real-world test, your founder's press statements were found to be orders-of-magnitudes out. As such, you've killed the interest from people who *knew* that all along and who would be asked their opinions on it by other people. If you'd just said "the affect won't ruin the majority of games", or "the latency isn't something we can do anything about but we don't expect it to affect the titles we offer, and the kind of customers we're aiming at", then nobody would have cared and if their granny bought the system they would have played on it too. But the stupid claims did not hold up and, thus, we're waiting to discover what the next lie is... *do* you have an accord with BT to get onto the UK broadband backbone? Do you have top-name titles properly licensed and ready-to-go? Do you have the capability to scale the service with the number of users? Do you have the hardware ready? Do you have something that you can sell if the system was to go live as quickly as possible?
You spoiled your image with bullshit. On an ideal test, a quite basic but fast-paced game that plays well locally gets up to 250ms of lag. Optimised or not, ideal conditions or not, that's just never going to sit well with people, even if they have a 60ms lag on their TFT monitors and don't realise it (http://www.tftcentral.co.uk/images/input_lag_graph.jpg). All I see is the "250ms" and think - damn - when I play CS online I think of anything over 80ms as "laggy". And that's just a one-way property, my lag to the server. God knows how a server performs when ALL players have a few hundred milliseconds of lag. I think 90% of your CPU time in that case must be input smoothing and path prediction.
It's just a pity that your failure to be honest will tar the rest of your business' life and that of any similar systems that might arise in the future.
Re:And that means...? (Score:4, Insightful)
Anywhere from 60ms to over 100ms is common. Apparently gamers start to notice input lag at 166ms. Also, input lag and network lag shouldn't be confused with each other. The ping values you see in your game aren't 1-on-1 comparable to the input lag rates reported here.
To be honest, the 150ms input lag surprises me in a positive way. It's much lower than I had expected. For a game like UT3, 150ms is probably way too much and apparently that's one of the faster games, so OnLive's input latency is probably still too high for most games.
Re:Pointless (Score:3, Insightful)
Cheap, dead-simple "Game rental", buffet-style. Pay per hour, not per game.
You can play any of hundreds games, now. No purchase, no download, no install, no cracking, no registering, easier than torrents. You just start a game and play it. And if you don't like it, switch it off and play another, you lost maybe half a dollar trying it out, not fifty bucks at a store, not thirty bucks and three hours downloading and installing from Steam, not three hours downloading and installing from piratebay. You just have it as if it was already installed on your PC, all included in rental fee.
200ms input latency (Score:4, Insightful)
Wen you see "I am connected to a server, and I have 200 ping with this server", that is not input latency. You can have 10ms input latency with a server that give you 200 ping. Things are computed clientside. So this will be much less playable than your average 200ms server.
Re:Oh For Fuck Sake (Score:3, Insightful)
yeah... that's an essential problem.
Network latency: You aim, almost immediately crosshair covers enemy head, you shoot, with bad lag the server will inform you you have missed, the enemy was not there.
Input latency: You aim. It takes 150ms for the crosshair to start following your aim. You finally get to aim at the enemy's head and click. The enemy moves, you move to follow, but since your reaction is delayed by 150ms it's now that your shot (and miss) and you will start following the enemy in 150ms.
ARGH. Totally unplayable.
Re:And that means...? (Score:4, Insightful)
(Older) PC games can be run at higher framerates because the hardware can handle it, so that might potentially decrease that 8ms average, but 5ms is only achieved with a 100fps framerate (when you assume 5ms as average, if you assume it's the slowest it'll ever be then you need 200fps).
Again, your LCD display has an inherent delay of 40 - 80 ms as well. The idea that 40ms input lag turns a game unplayable is a grave error. I mean, the article already points out that 60ms is basically as low as input lag on a non-LCD screen goes.
150ms doesn't mean 150ms in this case (Score:3, Insightful)
What they should have done to get a meaningful comparison is to do the exact camera setup thing they did, but also do it for a game running locally and then over the net. Only then can you meaningfully compare the numbers and know that you got it right.
Re:"masses of bandwidth"? (Score:1, Insightful)
I suppose there may be a connection if the bandwidth isn't enough to cover the constant streaming, but that'd mean the latency would slowly increase until it was unplayable; which obviously wasn't the case.
As you stated, it's probably a case of higher bandwidth needing better infrastructure; the better infrastructure providing an improved latency.
Re:"masses of bandwidth"? (Score:5, Insightful)
Let's assume you have a hop where distance/c = 10ms and packet's length/bandwidth = 10ms. This means, the head of a packet arrives in 10ms, the tail in 20. No routers or bridges save for the most unaware repeaters will handle the packet until it arrives completely. Only then they will examine it and start sending it forward.
Thus, the final latency will be:
a) distance/c, plus
b) time spent in queues, plus
c) time needed for the bodies of packets to arrive.
To reduce a), you need to be closer to your destination. To reduce b), you need an ISP who oversells less. To reduce c), you need bandwidth on all hops.
Re:And that means...? (Score:3, Insightful)
Your sibling post already indicated that most games require at least 4 frames (at 60fps) before input is translated to the screen.
But that is irrelevant to the subject of input lag. Thats input lag + display lag, which is different.
Between input and display is game mechanics, and it is all about game mechanics and initiating them before the other guy.
Re:Works Just Fine (Score:3, Insightful)
Maybe (I won't get tempted in an OS debate), but the average end user doesn't care/know whose fault it is. All they know is they got the disconnected message that they won't get if they buy/pirate the game, so in the end, OnLive loses because users won't sign up.
Re:And that means...? (Score:3, Insightful)
For the user, the lag he experiences is the combination of the two.
The fact is that people with lower input latency have an advantage even when the total round-trip latency remains unchanged. The latency-to-display is a red herring... humans compensate for latency-to-display by leading the target.
If players A and B both have latency-to-display of 200ms, but player A has a 0ms input latency and player B has a 200ms input latency, who the fuck do you think wins?
Re:And that means...? (Score:3, Insightful)
You're assuming the input thread is tied to the display thread, I assure you in games where input matters, the input thread and display thread are not one and the same.
UT3 doesn't tie the two together, it is entirely possibly to provide UT3 with multiple inputs per frame and have it respond to all of them. The same is true on console games as well, a prime example is Forza.
WTF? Your might, I assure you mine doesn't. I have bought a new LCD monitor in the last decade though so that might have something to do with it.
Your entire post is made based on assumptions that are wrong or only true for games that don't actually need twitch input, perhaps you should let people who actually write games talk about how they are written.
Comment removed (Score:4, Insightful)