Slashdot Mirror
OnLive Latency Tested
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."
And with the bandwidth this service uses, you'll hit your ISPs "unlimited" cap in what, 6 hours? A day?
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
The statement is silly because latency isn't directly related to bandwidth. Switches, bridges, repeaters, modems, routers and other such devices all add latency. If FiOS reduces the number of these in the chain, the latency will be reduced. I'm not saying it necessarily does - just that it could provide better latency without having more bandwidth because of other factors.
As an early adopter (read: 1-year free trial ;) the service works fine (6Mb cable conneciton). For twich games you will notice a little sluggishness, but overall, its not difficult to adjust. Essentially, all the games play like a good latency online game. The only thing i'm not sure I like at the moment is the some of the minor artifacting you'll see due to the video compression. Again, this only really comes into play if you stop and look for it, during action you'll not notice it too much as you'll be busy paying attention to other things ;). Though right now, I cant say for sure how this service will perform in the future, as you apply for entrance into the service currently. Once anyone can join whenever they want, its hard to say how quickly OnLive will adjust to increased congestion.
I love to slaughter the english language.
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"...
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.
Admit nothing. Deny Everything. Make Counter-accusations.
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.
In the UK there aren't many options at all. Eurogamer.net is UK-based, hence the mention of BT.
My company don't want the expense of using leased line and other specialist stuff, just an ordinary thing that can work like a home package over an ordinary phone line. The FASTEST damn thing we can have is a single or multiple ADSL2 lines. We have basically unlimited funds for such things and often specify overkill-measures (i.e. 3 or 4 ADSL2 lines from seperate suppliers rather than 1 leased line). We get 20Mbps sync and a little less real-world speed. We are approximately 10 metres from the exchange. We are in an affluent and well-populated area of London.
In terms of what the average home user can have, only Virgin media fibre really beats the other offerings but that's highly variable and although you are told "up to 50MBps", the infrastructure isn't there to give you that as usable bandwidth.
To be honest, I'm impressed they managed to get what they did considering the state of UK broadband. Of course, you can pay stupid money and get serious pipes put in but that's hardly a "real world" scenario for the average home user. It's not unimaginable, though, that a true gamer might have the best a home user can be offered - which in the UK is a 25/50Mbps fibre service.
It is bad, because we are talking about input lag, not response lag. And while it might be OK for Joe the console player, but it is unacceptable for competitive PC players, who tweak every single input device in order to lover lag.
Love many, trust a few, do harm to none.
Remember they don't just send the inputs there. They have to get the display back again.
If each frame is 100Kilobytes and they need 30fps to look smooth that's approaching the limit of 25Megabits/s (=3.125Megabytes/s).
I'd just like to add that I'm a Virgin Media customer with the 50meg connection he speaks of and I quite regularly max the hell out of it, at peak times. 6MB/s downloads are no problem.
However, he's right in that some areas have massive congestion problems and will suffer from issues, but unlike DSL, it wont have anything to do with how far away you are, if you're in a Virgin supplied area, you can get the 50meg.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
Less than 5ms is nonsense (a simple framerate calculation , but Digital Foundry did quite a few input lag tests.
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.
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.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
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.
-Woof woof woof!
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.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
It's not about consoles only. Your PC has the same problem. An average input lag of 5ms is impossible because when you take a game that renders at 60fps, every frame is roughly 16ms on the screen. If you push a button, then your action won't be visible until the next frame. So I'd say that at 60fps you'd have an average input lag of 8ms and that's not taking into account factors like game code processing the input and updating the gamestate or the lag caused by your LCD display.
(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.
This number of 150 ms latency may be true but it very likely does not mean at all what you think it means - it is not to be compared to the network latency that multiplayer games often report. The latency you normally see in a game is just the network latency - the amount of time it takes for a small packet to go from your computer to the server. The 150 ms latency includes the time it takes for a packet to go to the server, for the game to process that packet, and then send a frame of video back to you. So the server has registered your action long before the 150 ms are up. Also, normal lag does not include the time it takes for the game to process your command, which can be even more lengthy than your network latency, but that time is included in the 150 ms. Unless you are aware of these things, then the 150 ms number is completely meaningless to you and if you compare it to the latency number from some game you've played before then you are doing it wrong.
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.
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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Nope. But some, obviously:
http://www.verizonbusiness.com/uk/products/internet/fios/
Were you trying to suggest that Verizon only do business in the US?
Almost all games have at least 4 frames of controller response lag, some games much more. At 60 fps, that's at least 67 ms of essentially unavoidable latency before the image even gets to the display.
It breaks down like this: one frame to read the controller, one frame to process the control, one frame to draw the response, one frame to display the buffered image.
TFA largely glosses over that fact, but they do link to a previous article that address this phenomenon. Here are some other ones.
Programming Responsiveness
Measuring Responsiveness in Video Games
Some examples from one of the above links:
+0 Meh
No fast action game will work with that latency - the graphics might be smooth but the input response is like playing at five frames per second.
There'll be some games which work in this format but they won't be first person shooters or driving games - think flash games but multiplayer and in 3D.
Is it worth subscribing and being nickle-and-dimed for every minute you're on there instead of playing all the free flash games on the web? That's what they're betting the company on.
No sig today...
Latency is DIRECTLY related to bandwidth (in the sense bandwidth is determined by latency). That's how TCP's rate control algorithm works. It has a "window" of outstanding packets that it's sent and for which it's awaiting a response. It won't send more until it's had a response from the earlier ones. Therefore, latency and window-size together determine bandwidth. And window-size is fixed...
Of course it's possible that rate-throttling happens along the way for other reasons (i.e. giving lower bandwidth than what TCP's rate control algorithm would allow). But I believe this happens less often than one would expect.
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.
"His name was James Damore."
No it's not. It takes the game engine 60+ ms before it starts sending data that's updated with the new action to the screen. So on top of that 60ms, we have another 40 - 80ms of display lag. All of Eurogamer's Digital Foundry tests were done using a CRT monitor that has no lag of it's own.
Also, it doesn't matter which part of the lag comes from game code being processed and which part comes from your LCD crystals needing time to get updated. For the user, the lag he experiences is the combination of the two.
In the Digital Foundry blog, input lag is defined as the time between button press and when that action is visible on-screen. This is especially important and interesting in the context of OnLive, because other factors weigh in there as well (like network lag). Even if the delay caused by the OnLive servers themselves is 0.00001 ms, then 200ms added by the network makes things very unresponsive.
OnLive seems to be a DRM pusher's wet dream:
1) You can't play without constant internet connection.
2) Can't trasnfer saved data to an offline version of the game.
3) You are renting the game and thus you own no physical copy of the game which you can resell or lend to others to use.
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?
"His name was James Damore."
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager