Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Networking PC Games (Games) The Internet Games

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."
This discussion has been archived. No new comments can be posted.

OnLive Latency Tested

Comments Filter:
  • by _merlin ( 160982 ) on Thursday July 08, 2010 @07:19AM (#32837436) Homepage Journal

    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.

  • Re:Head - Desk... (Score:5, Informative)

    by JustinRLynn ( 831164 ) on Thursday July 08, 2010 @07:28AM (#32837516)
    Yep, you're absolutely right in that bandwidth and latency aren't the same. However, when used by TCP in latency sensitive environments, common asymmetric connections can quickly saturate their available upstream bandwidth. This means that they're not able to ACK incoming packets, effectively increasing their link latency and reducing its throughput. So, in reality, total throughput is a combination of link latency and the ability to quickly respond to the protocol stream to keep the bits flowing. This is why QoS for TCP is so important on heavily utilised asymmetric connections.
  • by ledow ( 319597 ) on Thursday July 08, 2010 @07:36AM (#32837576) Homepage

    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.

  • by SpazmodeusG ( 1334705 ) on Thursday July 08, 2010 @07:49AM (#32837682)

    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).

  • by neokushan ( 932374 ) on Thursday July 08, 2010 @07:51AM (#32837700)

    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.

  • by ledow ( 319597 ) on Thursday July 08, 2010 @08:25AM (#32838030) Homepage

    Nope. But some, obviously:

    http://www.verizonbusiness.com/uk/products/internet/fios/ [verizonbusiness.com]

    Were you trying to suggest that Verizon only do business in the US?

  • Re:Head - Desk... (Score:4, Informative)

    by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Thursday July 08, 2010 @08:42AM (#32838160) Homepage Journal

    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.

    A highly saturated connection will, in practice, have higher latency. Therefore, bandwidth and latency are related. HTH, HAND.

  • by Joce640k ( 829181 ) on Thursday July 08, 2010 @09:01AM (#32838440) Homepage

    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.

  • by ljw1004 ( 764174 ) on Thursday July 08, 2010 @10:06AM (#32839382)

    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.

  • by Eraesr ( 1629799 ) on Thursday July 08, 2010 @10:24AM (#32839668) Homepage
    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.

What is research but a blind date with knowledge? -- Will Harvey

Working...