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

204 comments

  1. Color me surprised by Anonymous Coward · · Score: 0

    The end of another vaporware company. That is all.

  2. Usage caps by KiloByte · · Score: 5, Interesting

    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.
    1. Re:Usage caps by RuBLed · · Score: 1

      I for one wants OnLive to succeed. It would be almost like how MMO games "provided" us DSL back then. (at least in our country) This would provide faster broadband services although ISP's could just jack the prices up for these "premium" services instead. The latter is what I fear would probably happen.

    2. Re:Usage caps by Ferzerp · · Score: 1

      And I want a flying car and a teleporter, but that doesn't meant I would go out and buy something that didn't work because I like the concept of what they claim they want to do.

      Wishful thinking becomes dangerous to the point where you are tempted to sink money in to something that so obviously will not work.

      We would all *love* the free energy pseudoscience crazies to actually make good on their claims, that doesn't mean it is a worthwile endeavour that we should waste money on.

    3. Re:Usage caps by IndustrialComplex · · Score: 1

      And I want a flying car and a teleporter, but that doesn't meant I would go out and buy something that didn't work because I like the concept of what they claim they want to do.

      Wishful thinking becomes dangerous to the point where you are tempted to sink money in to something that so obviously will not work.

      We would all *love* the free energy pseudoscience crazies to actually make good on their claims, that doesn't mean it is a worthwile endeavour that we should waste money on.

      And I'd like people on Slashdot to pay attention to the context of the people they reply to. Of course there are technical hurdles that may or may not be surmountable.

      The point wasn't that he was worried a technical issue would stop this, but a policy issue in the form of bandwidth caps.

      It really would suck for a new service to fail not because of any real technical limitation but the greed of third parties.

      --
      Out of modpoints but really liked a post? 1BDkF6TtmmeZ3yqXbz9yhdYVqRYnwFoXDj
    4. Re:Usage caps by ILuvRamen · · Score: 1

      I doubt it because their calculation results in 66.6 FPS so 60 I guess and there's no way in hell they're sending 1280x1024 at that framerate. What is it, like 320x240 resolution? They need to do a real study about this probably terribly inept service that includes all stats compared to a locally run game.

      --
      Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
    5. Re:Usage caps by Anonymous Coward · · Score: 0

      Meh, it's just another way to pay for a game you'll never own.

    6. Re:Usage caps by hairyfeet · · Score: 3, Insightful

      I think the real point is like everything else in this world it comes down to $$$. Company A develops app that uses a LOT of bandwidth and requires that Company B do massive upgrades. Company B has already decided NOT to roll out new lines, even though they are reaching saturation by other companies like Youtube and Hulu, and instead imposes caps so they can keep their profits high. Now what are the odds that company A is gonna stay afloat? Most likely 0%.

      You do NOT bet the farm on a company that requires a symbiotic relationship with other companies if the other companies aren't gonna play along. Last I heard even Verizon is slowing down the rollout of FIOS, and most of the regional teleco/cableco companies are simply gonna jack their prices or rollout caps, such as the 36Gb a month I'm currently dealing with on cable. Now since OnLive will blow through that cap in probably less than a day, and at $1.50 a Gb for going over could easily cost more than all my other bills combined if my kids got into a frag session, what are the odds anyone in my area will keep their service? Again most likely 0%. That is why OnLive is doomed to failure, not because of any conspiracy, but simply because they didn't accept the reality of the infrastructure in their plans.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    7. Re:Usage caps by KDR_11k · · Score: 1

      100 hours if we're talking about Comcast's 250GB limit apparently, they measured 2.5GB/h. The video stream isn't very high quality though.

      --
      Justice is the sheep getting arrested while an impartial judge declares the vote void.
  3. First post! by Anonymous Coward · · Score: 0, Troll

    Only took 137 ms.

  4. "masses of bandwidth"? by Eunuchswear · · Score: 1

    Latency was also reduced still further simply due to the masses of bandwidth FiOS offers compared to bog standard ADSL: in our case, 25mbps."

    Maybe you want to look for a better ADSL provider. 25mbps is not much faster than a good ADSL2+ line.

    --
    Watch this Heartland Institute video
    1. Re:"masses of bandwidth"? by _merlin · · Score: 5, Informative

      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.

    2. Re:"masses of bandwidth"? by ledow · · Score: 3, Informative

      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.

    3. Re:"masses of bandwidth"? by Eunuchswear · · Score: 1

      We get 20Mbps sync and a little less real-world speed.

      So, like I said, your ADSL line is a little bit slower than his "masses of bandwidth" FiOS line at 25mbps.

      --
      Watch this Heartland Institute video
    4. Re:"masses of bandwidth"? by Eunuchswear · · Score: 1

      In the UK there aren't many options at all. Eurogamer.net is UK-based, hence the mention of BT.

      Get a lot of Verizon FiOS installations in the UK?

      --
      Watch this Heartland Institute video
    5. Re:"masses of bandwidth"? by neokushan · · Score: 2, Informative

      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
    6. Re:"masses of bandwidth"? by Anonymous Coward · · 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.

    7. Re:"masses of bandwidth"? by KiloByte · · Score: 4, 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.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    8. Re:"masses of bandwidth"? by ledow · · Score: 2, Informative

      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?

    9. Re:"masses of bandwidth"? by Eunuchswear · · Score: 1

      Well, yes, I was.

      Didn't know they were selling that in the UK.

      --
      Watch this Heartland Institute video
    10. Re:"masses of bandwidth"? by Dexy · · Score: 1

      Virgin have a horrible throttling policy though, which, while it doesn't affect 50Mb customers, would make gameplay hell once the threshold is reached for anyone else.

    11. Re:"masses of bandwidth"? by mattsday · · Score: 1

      Agree here - I'm on the 50mbps service and usually see 40-45mbps without many issues.

      --
      Now there's one hoopy frood who really knows where his towel is!
    12. Re:"masses of bandwidth"? by Anonymous Coward · · Score: 1, Interesting

      Your simplified view does not really account for reality:

      - "Most unaware repeaters" are quite frequent on long-distance optical links. Do not ignore their influence!
      - You will find that technologies like DSL may induce quite a bit of latency due to features like interleaving, this latency may overshadow anything mentioned in a) to c)
      - The influence on first-hop bandwidth is usually marginal. With current bandwidth (assume 16Mbit/s) and usual packet length for games (assuming 200byte), this will give you 100 MICROseconds.

      Also I just have to add my favorite quote regarding bandwidth and latency: Never underestimate the bandwidth of a truck full of tapes hurling down the highway (Andrew S. Tanenbaum)

    13. Re:"masses of bandwidth"? by TheThiefMaster · · Score: 1

      The tests Eurogamer did were in the US, over Verizon FiOS (to give "OnLive the best possible ISP service we could find"). OnLive's not yet available in the UK.

      It still sucked.

    14. Re:"masses of bandwidth"? by GigaplexNZ · · Score: 1

      My company don't want the expense of using leased line and other specialist stuff <snip> We have basically unlimited funds for such things and often specify overkill-measures

      I don't follow.

    15. Re:"masses of bandwidth"? by ledow · · Score: 1

      Yeah, me neither. :-)

      But we end up with lots of mass-supported stuff like ADSL broadband and then perform juggling acts between them with our own equipment. They find them more reliable and easier to deal with than specialist hardware that only one company can play with. Hell, most companies that offer us "faster business" packages basically run two/three phones line and do ADSL2 over them, so it's just the same thing but more "independent". And when something goes wrong, it's easier to threaten to walk away from an individual supplier.

    16. Re:"masses of bandwidth"? by neokushan · · Score: 1

      Sadly, there are very few ISPs who don't have some kind of "fair use" or "traffic management" policy. Generally, it's a tossup between monthly bandwidth restrictions (which don't often exceed 30 or 40GB per month) that incur additional charges if you hit them, or traffic management as Virgin does it.
      Swings and roundabouts, really.

      --
      +1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
    17. Re:"masses of bandwidth"? by uncledrax · · Score: 1

      Ya that actual statement in the article doesn't make sense at face value, but this AC brings up a semi-valid point that if the the OnLive user is banging into an ISP's over-sub limits, then the end user will perceive higher-latency as TCP does the whole 're transmit thing' or UDP packets get dropped at a rate-limiter.. or in the best case, the packets funnel through a QoS Queue or something.

      I guess it's time Onlive hops subscribes to more use of NDT services (like the Google approved Measurement Lab)

      --
      ----- The internet has given everyone the ability to have their voice heard equally as loud.. even if they shouldn't be
    18. Re:"masses of bandwidth"? by ljw1004 · · Score: 2, Informative

      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.

    19. Re:"masses of bandwidth"? by Guspaz · · Score: 1

      They certainly wouldn't use TCP for something so latency sensitive, and it seems logical that they'd have designed their system to tolerate packetloss.

      In terms of QoS queues, they're already making peering arrangements with major ISPs (BT seems first) in order to get preferential treatment.

      I'm not sure why everybody thinks the latency EuroGamer is reporting is so high; it's not much different from LOCAL latency that EuroGamer reported for console games:

      http://www.eurogamer.net/articles/digitalfoundry-lag-factor-article

      http://www.eurogamer.net/articles/digitalfoundry-vs-console-lag-round-two-article

      If 150ms of latency is acceptable for an FPS on a console, how come it's not acceptable for an FPS on OnLive?

    20. Re:"masses of bandwidth"? by nabsltd · · Score: 1

      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.

      Verizon is one of the few Tier 1 networks from which end users can buy direct ISP service. FiOS runs on the "business" network, as far as I can tell.

      After the my router, and the Verizon router for my subnet, there are at most two hops inside Verizon for any traceroute (including to onlive.com). So, the fact that Verizon is so directly connected to all other networks does reduce latency as much as possible.

    21. Re:"masses of bandwidth"? by desertfoxmb · · Score: 1

      Latency was also reduced still further simply due to the masses of bandwidth FiOS offers compared to bog standard ADSL: in our case, 25mbps."

      Maybe you want to look for a better ADSL provider. 25mbps is not much faster than a good ADSL2+ line.

      I'm on the FIOS 35/35 plan. Depending on the server I'm connecting to I get between 12 and 30 mbps up and 25 and 100 mbps down on FIOS without my neighbors interfering with my speed during the day. Can you say the same on ADSL2+?

      --
      Fred
    22. Re:"masses of bandwidth"? by KiloByte · · Score: 1

      200 bytes? Here, we have a stream of full-MTU packets making frames of around megabit each.

      Those "unaware repeaters" are indeed frequent on optical links, but they don't count as hops. Usually, you measure the number of hops as the number of machines capable of routing that reduce TTL by one and may return pings.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    23. Re:"masses of bandwidth"? by desertfoxmb · · Score: 1

      That's with a server, four pcs and two gaming consoles connected to the internet on my home network by the way.

      --
      Fred
    24. Re:"masses of bandwidth"? by Anonymous Coward · · Score: 0

      That is misleading at best. If you have 1. a very fast connection and 2. high latency and 3. a small window, than latency will in fact lower the bandwidth available with TCP. However, modern operating systems use the TCP window scale option, which increases the maximum window size to something that will, in most networks, enable you to (almost) use your maximum bandwidth with TCP.

      (Don't like to undo my mod points, so posting as AC)

    25. Re:"masses of bandwidth"? by Doug+Neal · · Score: 1

      It won't be anything like residential FiOS connections in the US. It's the same kind of fibre leased line service you can get from any telco if you're a business in a city, based on SDH or metro ethernet, with a price tag to match. We're still some way off residential FTTH in the UK. Some areas have it but it's still very rare and very early days.

    26. Re:"masses of bandwidth"? by nedlohs · · Score: 1

      And TCP is the only protocol in existence, right?

    27. Re:"masses of bandwidth"? by BitZtream · · Score: 1

      In 1989, that was true.

      store-and-forward switching has been 'low end' for years.

      Layer 2 and 3 cut-through switching has been pretty standard on anything but shitty routers and switches for years.

      The dinky switch you have in your home is more likely a hub, with switches between 10 and 100mb (and Gb possibly) so it doesn't do store and forward either.

      The only store and forward packet switching your going to see now is for the SYN packet, after the routers have the paths cached for a flow, thats done.

      All you need to route/switch is the header, which is only a couple handful of bytes and not the whole package.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    28. Re:"masses of bandwidth"? by gotem · · Score: 1

      if you're in a Virgin supplied area, you can get the 50meg.

      no problem slashdot has a mass supply of Virgins

    29. Re:"masses of bandwidth"? by KDR_11k · · Score: 1

      Wouldn't a hub instead of a switch join the collision domains and have all kinds of bad effects on the network?

      --
      Justice is the sheep getting arrested while an impartial judge declares the vote void.
    30. Re:"masses of bandwidth"? by numbski · · Score: 1

      So - a 6 foot cross cable between two machines with gigabit interfaces has exactly the same latency as two machines with a maximum length cross cable? Same throughput?

      How about two machines with a similar media connection that allow for much greater distances?

      BTW - most real-time stuff happens with UDP, not TCP. :P

      --

      Karma: Chameleon (mostly due to the fact that you come and go).

    31. Re:"masses of bandwidth"? by Anonymous Coward · · Score: 0

      None of which matters, since games haven't used TCP since about 1985.

      UDP doesn't wait for outstanding packets.

    32. Re:"masses of bandwidth"? by twidarkling · · Score: 1

      Did you notice they said right in the summary "once the display's contribution to the measurement was removed"? That means it's on top of the standard input lag, and your second link is about motion controls. No one's legitimately expecting motion controls for something like an FPS beyond novelty. Look at MS's line up. It's basically a clone of Nintendo's casual motion titles. So, 150ms lag, plus the 50+ms from the lag your system already generates. You're now a fifth of a second behind what you're doing, and that's in a *best* case scenario.

      --
      Canada: The US's more awesome sibling.
    33. Re:"masses of bandwidth"? by Eunuchswear · · Score: 1

      Depending on the server I'm connecting to I get between 12 and 30 mbps up and 25 and 100 mbps down on FIOS without my neighbors interfering with my speed during the day. Can you say the same on ADSL2+?

      That's rather good. So the "35" means what exactly? Not mbps for sure.

      (By the way "without my neighbors interfering with my speed during the day" is true for ADSL too. Only cable or wifi have problems with neighbours.)

      --
      Watch this Heartland Institute video
    34. Re:"masses of bandwidth"? by SupremoMan · · Score: 1

      Very true. I remember playing an MMO back in the day (Ultima Online) where latency was very important due to the way the game played. I got a cable connection that gave me 13ms latency, with only 9 hops to the server. Needless to say I raped face.

    35. Re:"masses of bandwidth"? by Anonymous Coward · · Score: 0

      You are not talking about latency. You are talking about TCP windowing, which is affected by latency during the negotiation. Latency may peak due to bandwidth restrictions (latency will peak as bandwidth becomes scarce). However, whether a dial up connection or a 1 Gb fiber connection, if there is no restrictions on bandwidth, you are likely to see equal latency to any destination on the Internet. (Ok chances are a 1 Gb fiber connection is feeding directly into an ISPs central offices or collos which would eliminate some latency, but you get the idea).

  5. And that means...? by iamhassi · · Score: 1

    Is this bad or livable? From what I recall of first person shooters a 150-200ms lag isn't bad, but your review just gives the raw numbers and never says if the games were still playable or not.

    --
    my karma will be here long after I'm gone
    1. Re:And that means...? by mykos · · Score: 1

      That is just your input lag. Normally, you experience very little input lag (less than 5 ms) on your own computer. Then you have to add your network response time on top of that. You're looking at 1/3rd to 1/2 second before you actually respond ingame. Say goodbye to all multiplayer that isn't turn-based.

    2. Re:And that means...? by f3rret · · 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.

      --
      Admit nothing. Deny Everything. Make Counter-accusations.
    3. Re:And that means...? by Anonymous Coward · · Score: 0

      in the client and server open source game Sauerbraten, you can set up a server and play across europe in 50-90 ms. If the game doesn't trust much the client to avoid cheats more network load and lag than games like sauerbraten is inevitable but I'd rather risk cheaters and play smooth. YMMV

    4. Re:And that means...? by The+MAZZTer · · Score: 1

      Actually TF2 isn't bad compared to other games. Source has lag compensation that actually tries to adjust the game temporally based on a player's lag... in short, it figures out where everyone was from that player's POV at the moment they shot and uses that to figure out if the player hit with his shot, etc. I've played online games where even 70-100ms ping is unplayable (I'm looking at you, D.I.P.R.I.P.) but TF2 can remain smooth at 150, and playable at 200-300ms (though the lag becomes noticeable then as people can more easily seem to hit you around corners... in actuality they're hitting you where you were 300ms ago).

      On the other hand, unless you compile code into the game itself to compensate for input lag in a similar fashion, I expect any game would be similarly frustrating over 50ms lag or so.

    5. Re:And that means...? by SpazmodeusG · · Score: 1

      The latency from where the game is running to the multiplayer game server will be very low. So you won't get bugs that are normally attributed to that sort of thing. As far as the games concerned you'll have a terrific ping to nearby game servers.

      The input and display lag isn't even knowable by the game for the remote desktop trickery they are doing. Instead you get a game running perfectly smoothly on the datacenters computer with your inputs being completely out of sync with the display.

    6. Re:And that means...? by Xest · · Score: 1

      Put it this way, 150 - 200ms is worse than I used to get playing Quake 1 on a 33.6kbps dialup modem.

      I used to achieve around 120 - 140 on dialup to UK servers. ISDN was around 60 - 80ms, ADSL around 20 - 40ms.

      So in other words it sounds terrible in this day and age. Almost certainly bad enough to make games like Guitar Hero or other games that need rapid responses completely unplayable on this kind of service if they ever tried to offer it.

    7. Re:And that means...? by KovaaK · · Score: 1

      Keep in mind that there's a difference between input latency (which this story is talking about) and multiplayer network latency that you are talking about. In the case of multiplayer games, there is generally enough code on the client-side to predict what your screen will look like so that it feels snappy to you. Regarding getting hit through walls, that happens because the server doesn't think that you are behind the corner yet, so you are still a viable target to your opponent. The original quake didn't have any of the movement prediction, so there was movement input lag when you played online - thus when you thought you were behind cover, you really were. It still let you move your mouse without waiting for the server to agree that you were facing the new direction (every modern FPS does this as well as let the client predict movement before waiting for the server to agree). OnLive, on the other hand, will affect both movement input and mouse control input with this increased latency.

      Basically, a good LCD HDTV can add 40-80ms of input lag, and hardcore gamers such as myself complain about that (justifiably so). OnLive adds this same kind of latency. If it really is 150-200ms before multiplayer network latency, it is indeed useless for playing multiplayer games online.

    8. Re:And that means...? by alexhard · · Score: 1

      I think you're overstating the difference the lag compensation of tf2 makes. It kinda makes the 70-100ms interval playable, but anything above that is still very noticeable and extremely frustrating unless you're playing a camping engie.

      --
      Infinite time means everything that can happen, will. You being you is absolutely incidental. You do not exist.
    9. Re:And that means...? by Krneki · · Score: 2, Funny

      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.
    10. Re:And that means...? by Anonymous Coward · · Score: 0

      "hardcore gamers as myself". Get over yourself, you are a dying market.

    11. Re:And that means...? by Eraesr · · Score: 3, Insightful

      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.

    12. Re:And that means...? by Anonymous Coward · · Score: 0

      Wrong. 5ms is faster than achieved, but >40 ms is very poor for gaming system (I see the article talks mostly about consoles).

    13. Re:And that means...? by Razalhague · · Score: 1

      Basically, a good LCD HDTV can add 40-80ms of input lag, and hardcore gamers such as myself complain about that (justifiably so). OnLive adds this same kind of latency. If it really is 150-200ms before multiplayer network latency, it is indeed useless for playing multiplayer games online.

      I wouldn't be at all surprised if OnLive started putting servers for multiplayer games right in their datacenters, giving you very little network lag to compensate for the input lag.

    14. Re:And that means...? by Eraesr · · Score: 3, Insightful

      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.

    15. Re:And that means...? by Anonymous Coward · · Score: 0

      Why do you assume that by using the label "hardcore gamer" that he was elevating himself?

      Seems to me like you need to chill out.

    16. Re:And that means...? by twistedsymphony · · Score: 1

      Personally I think the lag is unacceptable unless approved by Korean Starcraft Players.

    17. Re:And that means...? by Anonymous Coward · · Score: 0

      Joe the console player is the target audience.

      No, Joe the very light console player is the target audience.

      Anyone else would get a better deal buying the system and games out right.

    18. Re:And that means...? by Purity+Of+Essence · · Score: 2, Interesting

      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:

      Games that run at 60 fps:

      PS3 System menus: 3/60ths
      Guitar Hero 3 (XBox 360): 3/60th
      Ridge Racer 7: 4/60ths
      Virtua Tennis: 4/60ths
      Ninja Gaiden Sigma: 4/60ths
      PixelJunk Racers 4/60ths

      Games that run at 30 fps:

      Genji: days of the Blade: 6/60ths
      Tony Hawk's Proving Ground: 8/60ths
      Blacksite: Area51: 8/60ths
      Halo 3 (XBox 360) : 8-10/60ths
      EA's "Skate": 10/60ths
      GTA-IV: 10/60ths
      Harry Potter: 10-14/60ths
      Heavenly Sword: 7-18/60ths

      --
      +0 Meh
    19. Re:And that means...? by Yvanhoe · · Score: 1

      Input lag of 150-200 ms is simply not playable. Remember that a laggy server hide the latency through interpolation and let's you have a short latency for your input.

      200 ms is the kind of reaction time you can have at 5 fps. Of course their image goes at 30 or 60 fps, but if you want to see what a lag of 200 ms represent, witness how difficult it is to play at 5 fps.

      --
      The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
    20. Re:And that means...? by Bakkster · · Score: 1

      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.

      Isn't this service intended for 'Joe the console player', and not for competitive PC gamers? In other words, it's an entirely reasonable trade-off.

      I think the issue here is all the 'hardcore' gamers who worry about this kind of stuff were never the target market, because they're 'hardcore' enough to put tons of money into their own rig. The recreational player just wants the cheapest method that's acceptable, and that's what the service is aimed for. Of course, it's mostly the hardcore gamer who posts on forums, not the recreational ones, so it's nothing but hate in the internet echo chamber.

      --
      Write your representatives! Repeal the 2nd Law of Thermodynamics!
    21. Re:And that means...? by Anonymous Coward · · Score: 0

      To me, this is unplayable. It isn't just lag in the reaction of objects in the world around you, it's lag in the reaction of your input including menu interfaces. To get an idea, you'd have to play a game at 200 ping that does not have any client side prediction at all. The original Quake (not QuakeWorld) is a great example of this. It was considered almost completely unplayable at anything higher than 150 ping by most players. You literally could not successfully jump across some gaps to get powerups/weapons.

      The reason people say FPS games work fine at 150-200 ms these days is because those FPS games have massive client side prediction. The client just pretends that your actions are instant until it gets a message from the server that contradicts your actions, and then performs some action to resolve it. Generally the server will also look back in time a short amount to determine if your actions 200ms in the past were valid based on the game state at that time instead of the current game state.

      And there's pretty much no way they can resolve this lack of client side prediction because the entire point of the service is *not* to have all this data or the executable on the client. It'll probably be fine for RPGs and slow paced RTS games or strategy games, but when it comes to shooters or platformers this amount of lag is completely unacceptable and unplayable except by the most casual of players or the simplest of games.

      Carmack gave a speech a while ago where he mentioned OnLive and said that the only reason he thought some games would be playable was because their engines already handled input poorly and had 50-100ms of internal lag that would help mask the effect.

    22. Re:And that means...? by B1oodAnge1 · · Score: 0, Troll

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

      You don't seem to realize that if an average PC gamer is maxing out at 60 fps then he is complaining constantly about the lag and making plans to build a new system.

      60fps is bare minimum for a decent experience in a non multiplayer game, and unplayable against other humans.

      --
      RUGBYRUGBYRUGBY
    23. Re:And that means...? by Anonymous Coward · · Score: 0

      With a stopwatch.

    24. Re:And that means...? by Ruede · · Score: 1

      yeah and high ping bastards have an advantage....
      great... that is why i hate the source netcode.

      anywhere around the world ppl started to get better internet connections.... (56k died out.) but valve decided to make the game playable for those suckers that had to keep a 56k modem.

    25. Re:And that means...? by Eraesr · · Score: 1

      To be honest, that's quite the hardcore specialist's attitude towards framerate. Calling 60fps "unplayable" goes even further. I think that's an elitist attitude. 60fps is well playable. Maybe higher framerates are preferable, but 60fps is decent, even for multiplayer. I remember playing Quake 3 with 25 fps on my Voodoo 2 and it was awesome.

      It's all quite besides the point though. Your sibling post already indicated that most games require at least 4 frames (at 60fps) before input is translated to the screen. That's still 60 - 70ms. I doubt that rendering at 100 frames per second will reduce the 60ms input lag. Add 40ms LCD display lag and BAM, you've got an 100ms delay. Quite a different story from 5ms, no?

      My initial post was to point out that under normal circumstances, a 5ms input delay is impossible because it simply takes longer to render a single frame at 60fps.

    26. Re:And that means...? by Rockoon · · Score: 2, 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.

      --
      "His name was James Damore."
    27. Re:And that means...? by Yamata+no+Orochi · · Score: 0

      60fps is bare minimum?

      You've lost your damned mind. Maxing out at 60 fps wouldn't have anything to do with "lag," you or the people you're referring to are completely clueless.

    28. Re:And that means...? by Anonymous Coward · · Score: 0

      >a good LCD HDTV can add 40-80ms

      It's not a good one for gaming if that's the case.

      A good one should add max 2*16 (60fps refresh) ms lag (less if it's 120hz or more internally)

    29. Re:And that means...? by Eraesr · · Score: 2, Informative

      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.

    30. Re:And that means...? by bondsbw · · Score: 1

      Something else I noticed about OnLive: because all the game servers are at the same location, you don't get traditional multiplayer lag (you know, where the guy you're shooting suddenly appears behind you and beats you down.)

      A recent article claims that OnLive actually works better for FPS games like UT3, where textures are not very high resolution. The latency is more noticeable for games like World of Goo, where the cartoon graphics are high resolution and there is not enough action to distract you from the latency.

      I wish I could find the article, but I can't anymore. Regardless, my experience matches those claims.

      --
      All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
    31. Re:And that means...? by Nugoo · · Score: 1

      Aren't those the kinds of games you can play on a crappy computer anyway?

      --
      I explicitly release the above into the public domain.
    32. Re:And that means...? by perryizgr8 · · Score: 1

      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.

      PWNED!

      --
      Wealth is the gift that keeps on giving.
    33. Re:And that means...? by perryizgr8 · · Score: 1

      the latency you see listed next to server names is only the network lag. almost 40-100ms is added on top of that by your system. so actually, 150ms of total lag in on live is quite good.

      --
      Wealth is the gift that keeps on giving.
    34. Re:And that means...? by Gyske · · Score: 1

      What it also lacks is a comparison with locally installed games, using the same test setup and method. They could easily do the same tests with locally installed games and publish the differences in measured latency. That would have been far more informative and would make the results easier to interpret. It would for one have prevented the confusion between network latency and the total latency between input event (keyboard press) and the display of its result (movement on display screen), which was measured in this test.

    35. Re:And that means...? by __aailob1448 · · Score: 1

      Again, your LCD display has an inherent delay of 40 - 80 ms as well.

      Incorrect. Modern LCD display have delays of 20 ms or less, especially using game mode (minimal image processing). And they usually list 8ms or less latency on the box, which is a lie.

       

    36. Re:And that means...? by Anonymous Coward · · Score: 0

      Input lag should be between the time you push the button, and the time your character begins to act on it -- which could be before rendering, especially in this case given the latency on the return trip.

      You won't get immediate feedback on the results, but if you're running up to an edge and timing your jump then only the latency before the game begins to execute your command will really impact whether you make it or not.

      Of course, this is also much harder to time accurately.

    37. Re:And that means...? by Rockoon · · Score: 2, 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?

      --
      "His name was James Damore."
    38. Re:And that means...? by Amphetam1ne · · Score: 1

      Indeed, I remember playing Quake 2 on dialup with 150-200 ping... This feels like the service has been built with the assurance that the associated technologies that it's going to be relying on will have caught up by then. This type of gaming service might just about be viable in 3-4 years, but only to the city dwellers. I can't see it ever working properly out in the rural areas where carriers just don't see enough return against upgrades due to sparse populations.

      --
      I only buy pepper spray that's been tested on anti-vivisectionists.
    39. Re:And that means...? by PingSpike · · Score: 1

      I assure you that source games are quite unplayable on 56K connections in any useful capacity. And that's ignoring the nightmare that required and frequent game and steam updates thrust upon the user every time they try to fire the game up.

      You are not being killed because your ping is to low.

    40. Re:And that means...? by PingSpike · · Score: 1

      Certainly, but wouldn't that benefit only apply to players in your same region? That seems like it would greatly limit the number potential players to play the game with.

    41. Re:And that means...? by BitZtream · · Score: 2, 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.

      Again, your LCD display has an inherent delay of 40 - 80 ms as well

      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
    42. Re:And that means...? by atsolberg · · Score: 1

      I am an Onlive member and the two games I have are UT3 and Splinter Cell: Conviction. My ping to the Chicago server (i live in Minnesota) is 55ms on pingtest.net. Surprisingly the game really decided if it is playable or not. With UT3 I experience almost no lag and is very playable, with SplinterCell the lag is so bad I can't get past missions that don't allow me to sneak around instead of go full frontal attack.

    43. Re:And that means...? by hvdh · · Score: 1

      Which models? I measured display latency of several large recent monitors (Dell 3007WPF, 3008WPF, some 24", HP 30") and all of these have >= 40ms input lag.

      Measurement was done with special hardware: a USB microcontroller device which gets a software signal when frame buffer
      content is changed (different gray levels) and an optical sensor put on the screen which triggers when the intensity changes.
      Measurement error is within +-2ms.

    44. Re:And that means...? by KDR_11k · · Score: 1

      Digital Foundry concluded that console games often have input lag in the 100+ms range (especially since many games on the HD consoles only run at 30 FPS). That includes the full delay from input to on-screen action, even on the PC you won't see 5ms often because the delay includes not just the transfer delays but also the processing, first the signal must goto the game, then it has to be incorporated on the next simulation frame which you only see on the next render frame and that gets additional lag if you have an LCD screen (which I don't).

      --
      Justice is the sheep getting arrested while an impartial judge declares the vote void.
    45. Re:And that means...? by KDR_11k · · Score: 1

      I'm using an ADSL connection and rarely get pings below 100ms even to servers in my own country, for more obscure titles I may have to connect to other countries and then it gets to 200ms or worse. Games without lag compensation are almost completely unplayable (and with obscure titles laggy servers often mean everybody has a bad ping and needs to lead targets even though the game wasn't designed to require that) and firefights turn into blind spraying as you hope your bullets ever line up with the enemy. With lag compensation you aim, shoot and maybe see the result later but sniper rifles and such don't become useless. Believe me, I've seen plenty of games where I wasn't the only one who had trouble with lag and those games become hilarious/pathetic when they require precision shooting.

      --
      Justice is the sheep getting arrested while an impartial judge declares the vote void.
    46. Re:And that means...? by B1oodAnge1 · · Score: 1

      Did you not mind the sluggish response in Vista either?

      There is a distinct feel to a game (or any other software that controls the mouse pointer) when there is too much input lag: it feels like the pointer is at the end of a long flexible pole.
      It gets to where you are pointing just after you pointed there, and it is extremely hard to get precision accuracy with it.

      I realize not everyone is bothered by input lag, and that's perfectly fine, but those who are bothered know exactly what I'm talking about.

      --
      RUGBYRUGBYRUGBY
    47. Re:And that means...? by Anonymous Coward · · Score: 0

      While I haven't measured the frequency, I must say my demo play of Batman: Arkam Asylum was pretty good. I have a 1080p monitor and running things at 720 was still more than acceptable. It played well and responsively and I didn't really feel any lag (This may simply be due to the fact I am on university internet, and my university sits about 2.5 miles from the OnLive HQ, so most likely I'm fairly close to one of their centers.). Ironically the game did glitch out on me once or twice while playing a demo of Shatter, which did look very nice at 720p. I'm not sure what this means. My PC is fairly robust, and I can play most games at 1080p on high settings without a glitch, so the system does work as advertised (from close distances and fairly stable connection), but does suffer some minor half-second glitches surprisingly on certain games.

    48. Re:And that means...? by Anonymous Coward · · Score: 0

      dude, don't bother. he's hardcore on games like an self-proclaimed audiophile. you can tell cause his name has numbers in it.

      Boom! Fatal1ty!!!!!!!!

    49. Re:And that means...? by BikeHelmet · · Score: 1

      Anywhere from 60ms to over 100ms is common. Apparently gamers start to notice input lag at 166ms.

      I notice input lag in the sub-30ms range. That's why I disable triple buffering and set Prerender limit to 0, to force my games to spit frames right into the buffer that draws the screen. At 60fps, I want my input lag to be as close to 16.67ms as possible. There's already lag from my LCD changing all the pixels, and lag from my brain registering the change. I don't need any more.

      There's a hilarious side effect to this. In some games you can actually shoot near where someone was and score a hit. In TF2 I've headshotted people by firing where their heads used to be. Some games opt to include a 1-2 frame hit detection grace period - I've heard that on consoles, where TVs often have nasty input lag, it can be as high as 6-10 frames. If you're aware of it for the games that have it, you can put it to very good use.

    50. Re:And that means...? by MobyDisk · · Score: 1

      I'm reading the second article, "Measuring Responsiveness in Video Games" and it is a really cool experiment. But I think the conclusion is exaggerated. Take a look at the section "CALIBRATION AND MEASURING" where the 3 pictures are. He concludes that the PS3 menu is taking 3/60 of a second to respond, yet the measurements he has show between 1/60 and 2/60th.

      The timeline:
      1. The first frame is rendered.
      2. The user presses the button some time after this.
      3. The camera takes a frame.
      - At this point, he conclused that if the screen updated, it would be 0/60th lag, but of course, that would be impossible. Agreed.
      4. The camera takes a frame. Nothing has changed.
      - At this point, we have between 0/60th and 1/60th of lag, depending on how far into the frame the user was when they pressed the button.
      5. The camera takes a frame. The screen has updated.
      - At this point, we have between 1/60th and 2/60th of lag.

      Basically, the software had a 1 frame latency. In the edge case where the system was in the middle of processing a frame when the user hit the button, so the button state had not updated, it took 2/60th - 2 frames. This is basically optimal.

      The reason for the incorrect conclusion is demonstrated in the first article. It shows the simplest loop as:
      1. Input()
      2. Logic()
      3. Rendering()

      The author seems to assume that these 3 steps happen in different frames. Input is usually handled asynchronously on a totally different clock. The button state is latched immediately, and copied into local state during the Logic() call. So it isn't 3 frames of latency there. Worst case is 2 + whatever the display has.

      P.S. Just to restate, I'm not disagreeing with the measurements. The fact that some games have 14 frames of latency is clearly something with the game engine, not the hardware limitations. That is quite sad, and strange that the user doesn't notice it.

    51. Re:And that means...? by B1oodAnge1 · · Score: 1

      rofl, nice -1 disagree mod there ;-)
      I'm far from a hardcore gamer, I just like things to happen right when I tell them to happen, and not just after.

      --
      RUGBYRUGBYRUGBY
  6. Impressive by mrsurb · · Score: 1

    Getting that sort of latency within "1000 miles of its datacenters" is quite impressive.

    1. Re:Impressive by Anonymous Coward · · Score: 0

      I agree. But "impressive" does not necessarily imply "good enough".

    2. Re:Impressive by Hatta · · Score: 1

      1000 miles is nothing when you're traveling at an appreciable fraction of the speed of light. What matters more is the number of routers, switches, etc. etc. between endpoints.

      --
      Give me Classic Slashdot or give me death!
  7. Works Just Fine by Zediker · · Score: 5, Interesting

    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.
    1. Re:Works Just Fine by Anonymous Coward · · Score: 0

      Then again, I'd be hard-pressed to bad-mouth anything that I've gotten a one-year free trial on.

    2. Re:Works Just Fine by Krahar · · Score: 1

      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.

      What would be cool is if they could track your eyes using a webcam and increase the quality at the part of the screen you are looking at. Won't help if your eyes are twitching all over the place, but if there is anything you want to see in full quality, just look at it during the latency of those 230 or so milliseconds and the artifacts will disappear where you are looking.

    3. Re:Works Just Fine by Zediker · · Score: 1

      well, nothings stoping anyone else from signing up and getting a 1-year free trial as well. ;)

      --
      I love to slaughter the english language.
    4. Re:Works Just Fine by should_be_linear · · Score: 1

      And it will only get better: with increasing number of cloud-gamers, ISPs will start deploying OnLive servers on sites close to customers, decreasing latency dramatically. Another point that might improve in time is HW latency (modem / ISP routers, ...) which might be improved now that it is important for some BFUs and finally, OnLive might end up being property of Google, therefore spread much faster to remote locations near potential customers.

      --
      839*929
    5. Re:Works Just Fine by Anonymous Coward · · Score: 0

      Nothing except my integrity and burning desire to see OnLive die a death so horrible that its investors are bankrupted and nobody ever tries this bullshit again.

    6. Re:Works Just Fine by gnieboer · · Score: 2, Interesting

      Also an early adopter, and I've found it varies widely by game. DiRT 2 was unplayable with that lag.

      Some of the games worked fine, and IMHO the best thing it's got going for it is the ability to instantly play 30 minute demos of any game they've got, no need to install/uninstall more stuff on the home machine just to see if a game is worth it.

      I also got kicked out several times due to "network issues" one night that was very frustrating (despite being on a reliably 16mbps connection->gigabit LAN). I think those factors, if not addressed, will prevent common user adoption (Win7 decides to background download some new service pack and hogs too much bandwidth and you're done with no understanding of why).

    7. Re:Works Just Fine by MattSausage · · Score: 1

      Ummm.. are you serious?

      Why is Onlive such a dangerous thing for you to hate it so much? You prefer upgrading your PC every 6 months?

    8. Re:Works Just Fine by revlayle · · Score: 1

      Or is justifying the last 800 bux he/she just spent :)

      Now, I am not a big fan of their pricing plans (beyond the free trial) - but everything else seems kinda cool, if it works.

    9. Re:Works Just Fine by Yamata+no+Orochi · · Score: 0

      (Win7 decides to background download some new service pack and hogs too much bandwidth and you're done with no understanding of why).

      Your fault, not theirs.

    10. Re:Works Just Fine by Anonymous Coward · · Score: 0

      You prefer to be nickel and dimed for a service where you don't own the games?

    11. Re:Works Just Fine by Anonymous Coward · · Score: 0

      What would also be cool is if they used tachyons or something, so that the game would reach you 35 minutes before your input. That would eliminate the lag.

    12. Re:Works Just Fine by gnieboer · · Score: 2, 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.

    13. Re:Works Just Fine by BaronAaron · · Score: 2, Interesting

      I've also been playing with the free trial.

      I have a standard 6mb cable connection and the latency hasn't been an issue for me. Been playing various first person shooters and it's all been rather smooth.

      I think the coolest feature is the "Arena". It's a live video wall that let's you browse and view other player's gaming sessions. It's actually fairly entertaining watching other players play the games, and it gives you a good idea if you'd like the game. It's also an impressive technical feat to be able to see 20 or so live play sessions on your screen at once.

    14. Re:Works Just Fine by djdanlib · · Score: 1

      That's actually kind of interesting. Your eyes only show you max detail in a limited circle, so if you had a big monitor that you sat fairly close to, you'd save a lot of bandwidth that way.

      I would never expect to see such a solution implemented though, because the benefits would seem to be dwarfed by the cost of creating such a beast.

    15. Re:Works Just Fine by Krahar · · Score: 1

      Costs? The video is already being compressed online just for you. Eye tracking software is already available. It only requires people to have a webcam, and you don't have to use it if you don't have a webcam. The only problem is the 150ms latency, so the quality spot wouldn't keep up if you are moving your eyes continually.

    16. Re:Works Just Fine by Yamata+no+Orochi · · Score: 0

      That's true, but the preferences set in your operating system on your computer are exclusively the responsibility of the user. If it's detrimental for Windows to download updates without telling you, you should not have selected that option when prompted at install.

    17. Re:Works Just Fine by Anonymous Coward · · Score: 0

      "you should not have selected that option when prompted at install."

      As if your average person ever installs their own OS. The majority eithr buy a box from a major vendor, bring it to a place to get it repaired, or have their j-random person who "knows computers" to do it.

      As gnieboer says, they won't care, and problems with be attributed to Onlive...

    18. Re:Works Just Fine by soppsa · · Score: 1

      It's shitty tech, and anyone who thinks it will scale efficiently is deluded.

    19. Re:Works Just Fine by MattSausage · · Score: 1

      I'm pretty sure I heard people say the same thing, except replace 'scale efficiently' with 'ever work at all with current tech'.

      And it may be many things, but Onlive is doing something very few people, including myself, ever thought was possible, that is NOT 'shitty tech'.

  8. Bandwidth != Latency by Anonymous Coward · · Score: 1, Insightful

    Bandwidth and latency are not the same thing. Increasing the bandwidth to 25Mbps will not help latency at all.

    1. Re:Bandwidth != Latency by Anonymous Coward · · Score: 1, Interesting

      In theory they are separate, but for example I upgraded my connection to 4x the previous bandwidth, and to my surprise the latency dropped down by half.

    2. Re:Bandwidth != Latency by SpazmodeusG · · Score: 3, Informative

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

    3. Re:Bandwidth != Latency by Anonymous Coward · · Score: 0

      Wouldn't the majority of the packets be the video frames that OnLive sends as a response to your button presses? Those are quite large...

    4. Re:Bandwidth != Latency by Krahar · · Score: 1

      They also have to send you back frames of video.

    5. Re:Bandwidth != Latency by msauve · · Score: 1

      It doesn't work the way you think it works.

      From Onlive's site: "OnLive recommends a wired 5 Mbps connection to the Internet..." They haven't released any technical info on their proprietary video compressor, so it's not clear where your numbers come from.

      In any case, even if the full difference in serialization delay is considered (~12 ms), that is minor in comparison to the measurements.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    6. Re:Bandwidth != Latency by icebraining · · Score: 1

      Wrong. Latency is affected by the throughput, because it's the sum of the time it takes to be transmitted plus the time for that data to traverse the network equipment between the nodes.

      Where precision is important, one-way latency for a link can be more strictly defined as the time from the start of packet transmission to the start of packet reception. The time from the start of packet transmission to the end of packet transmission at the near end is measured separately and called serialization delay. This definition of latency depends on the throughput of the link and the size of the packet, and is the time required by the system to signal the full packet to the wire.

      Besides, if the link is congested, queuing delays will occur, as the packets will have to wait for the previous to be sent. This is important for OnLive, as it uses plenty of bandwidth to transmit the video feed.

      Reducing network congestion by getting a "fatter pipe" always help reduce latency.

    7. Re:Bandwidth != Latency by msauve · · Score: 1

      Your point being? ADSL provides on the order of 12 mbps downstream bandwidth, so the difference in serialization delay is less than 1 ms, even for large packets.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    8. Re:Bandwidth != Latency by msauve · · Score: 1

      I'll just add that the video is on the downstream channel, where the difference between ADSL and FiOS is 12:25 mbps. That's a difference of about 0.5 ms in latency for large packets. I was talking about the upstream channel, where game inputs would be sent. These are the small packets, so still under 1 ms.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    9. Re:Bandwidth != Latency by KiloByte · · Score: 1

      12ms -- for every single hop. Sure, the routers upstream have a better link than you so it will be less than 12 for those hops, but you still suffer a separate delay for every routers on the way.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    10. Re:Bandwidth != Latency by msauve · · Score: 1

      12ms -- for every single hop. Sure, the routers upstream have a better link than you so it will be less than 12 for those hops, but you still suffer a separate delay for every routers on the way.

      No, it's not "12ms -- for every single hop." That just shows you don't understand how packet switched networks operate. Did you even try to think this through?

      The comparison is between ADSL and FiOS. Those are "last mile" technologies. There's no reason to assume that the routers upstream would have any performance differences, based simply on which technology they used to connect subscribers. The only difference is between ADSL and FiOS, which is what I covered.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    11. Re:Bandwidth != Latency by Krahar · · Score: 1

      To display a frame you have to wait for that frame to have been transferred to you. We have to know the size of a frame to know the impact, but I'm guessing it's non-trivial. In your comment you seemed to only be accounting for the communication of key presses from the client to the server. I'm pointing out the much larger amount of information flowing the other way, and the transfer of this information was included in their latency measurements.

    12. Re:Bandwidth != Latency by KiloByte · · Score: 1

      No, it's not "12ms -- for every single hop." That just shows you don't understand how packet switched networks operate. Did you even try to think this through?

      And how exactly a packet switched network would introduce a hop? For that, you would have to inspect the packet, decide where to route it to, and decrease TTL.

      The comparison is between ADSL and FiOS. Those are "last mile" technologies. There's no reason to assume that the routers upstream would have any performance differences

      I don't expect a difference between ADSL and FiOS of the same bandwidth -- but it's not an insane assumption to guess that the ISP which sells 25 times as big pipes to every customer will also have bigger bandwidth on its upstream routers. The last mile accounts just for a single hop which, while indeed tends to have a significant effect on latency, is far from being the biggest factor.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
  9. Head - Desk... by fuzzyfuzzyfungus · · 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"...

    1. Re:Head - Desk... by JustinRLynn · · Score: 5, Informative

      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.

    2. Re:Head - Desk... by qbnstephen · · Score: 1

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

      It's great to see somebody has their head screwed on right today.

    3. Re:Head - Desk... by Krahar · · Score: 1

      Bandwidth can reduce latency all other things being equal. If you need to send a packet of 5kb then the latency of that packet will be lots of things that are independent of the bandwidth, but it also does include the time it takes to transfer the data in the packet itself over the wire, and higher bandwidth reduces that time. Not that it is going to be a lot of time for a 5 kb packet, but there can indeed be an impact of bandwidth to latency.

    4. Re:Head - Desk... by MichaelSmith · · Score: 1

      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.

      Its not just the kids. I had the corporate IT department tell me they would fix their latency issues by compressing the link, and if that didn't work they would put another compressor in series with the original one.

    5. Re:Head - Desk... by Krahar · · Score: 1

      Actually I'm guessing that video frames are a lot larger than 5kb. If they are e.g. 1 mb then the time to transfer may even be more than the latency of the connection itself, depending on your bandwidth. So the latency as measured by the time from pressing a key and the man on your screen doing something is most certainly impacted by bandwidth in many cases. This effect is not limited to when the game can't finish sending a frame before the next one is ready, because even when that doesn't happen you still have to wait to receive the frame before it can be displayed.

    6. Re:Head - Desk... by fuzzyfuzzyfungus · · Score: 1

      If people would just stop using large font sizes in emails, their compressor definitely would have done the trick...

    7. Re:Head - Desk... by drinkypoo · · Score: 3, Informative

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    8. Re:Head - Desk... by icebraining · · Score: 1

      Latency = transmit time + time to transverse the wire.

      Throughput ("having a fat pipe") does affect the first factor. Of course, if the second factor is multiple orders of magnitude larger than the first (like with your Fedex example), reducing the first will be irrelevant, but that's always true with any optimization.

      But that's not the usual case in a normal internet connection, and improving the first factor can and does improve the latency visibly.

    9. Re:Head - Desk... by Anonymous Coward · · Score: 0

      Just for fun: 0.2s * 25mb/s / (8 bit/Byte)= 625kB.

      The frames can not be larger than that. Actually, they probably are half of that or so...

    10. Re:Head - Desk... by chrysrobyn · · Score: 1

      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.

      If that's the stance you take, one might suggest you be forced to use a 150bps connection with a 1us latency. No, latency and bandwidth aren't directly related, but one who believes that the other is completely irrelevant in all situations has been misled. In this case, we're dealing with full frames of video being compressed and sent back to the customer. I wouldn't necessarily believe my 5MBps RoadRunner would be a neutral test for that situation. I don't usually get more than 400KBps for whatever reason, and when I'm pushing that much my other connections (ssh) experience additional latency. If the video is 300KBps, I'd think FIOS would indeed be a better test because of the additional bandwidth.

      It's been a while since I worked in a data center, but time was we tried to keep ethernet saturation below 20%. Higher than that and performance went down noticeably.

    11. Re:Head - Desk... by MikeBabcock · · Score: 1

      Of course they're not the same.

      That said, when your link is transmitting at full speed and you try to throw another packet down the pipe, you get queueing delays and/or packet drops resulting in delays.

      Those delays add up to effective latency.

      Sure, one device may still be exactly 24ms from another device on the wire, but if there's no room for that extra data, you have to wait longer for it to get there.

      Latency doesn't just mean actual wire latency of a specific packet. It has a nice English definition that allows it to be used in sentences to mean "I've got high latency on this video chat because my bandwidth is too low to handle it". That is to say, the a/v is encoded at 1.5Mb and you have 1.0Mb transmission available, you're going to be waiting for the data to show up.

      No, its not the same thing as a ping time, but its the layer 7 bit that matters to the user.

      --
      - Michael T. Babcock (Yes, I blog)
    12. Re:Head - Desk... by Yamata+no+Orochi · · Score: 0

      The point he was trying to make was a semantic one. I'm positive he realizes bandwidth and congestion thereof can affect throughput and "latency," but strictly speaking, bandwidth and latency ARE separate measurements ENTIRELY. Latency has a very strict definition in addition to its in practice definition.

    13. Re:Head - Desk... by Gyske · · Score: 1

      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.

      Indeed, but one should never underestimate the bandwidth of a truck full of tapes!

    14. Re:Head - Desk... by BitZtream · · Score: 1

      but having a fat pipe does not "reduce your latency".

      Yes, it does, most certainly, the laws of physics do require it to do, and I'm still ignoring link saturation/collisions or protocol overhead/processing on the link ends.

      A packet of equal size takes longer to travel down a slower pipe as all the bits are literally 'bigger' on slow pipes. A bit at 10mb (on an ethernet 10mhz carrier) takes 1/10,000,000th of a second to transmit. A bit at 100mb (on an ethernet 100mhz carrier) takes 1/100,000,000th of a second to transmit. It it completes transmission literally 10 times faster. It doesn't go down the wire any faster, it just takes less time on the wire to do the same thing, which results in lower latency.

      Does it matter? No, the difference is already so far below anything a person can detect that it doesn't matter, unless you happen to be using a dialup line.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    15. Re:Head - Desk... by Anonymous Coward · · Score: 0

      I haven't checked yet, but I would guess that OnLive uses UDP rather than TCP in some form, since you can also watch others playing their games. It would be an unnecessary burden on (what I'm assuming are) a VM running the game to maintain TCP connections to the player and anyone watching the player. I would assume that the player's input is also UDP, since by the time TCP would do any error handling, the player's movement would have been negated anyway.

    16. Re:Head - Desk... by Caustic+Soda · · Score: 1

      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.

      1Gb/s via almost any means is nearly certain to be faster than what I currently have. Damn you Australia and your Telcos!

    17. Re:Head - Desk... by noodler · · Score: 1

      I think they use UDP...

  10. Not too shabby by kinnell · · Score: 1

    I've played WOW with that kind of latency at times, and while it's not ideal, it's definitely playable without becoming frustrated. It may not work well for some games, especially for people who are serious about PVP, but it seems like a reasonable service. Considering the technology they're using, I'd say they're doing pretty well. As a mac user, I'd give it serious consideration.

    --
    If I seem short sighted, it is because I stand on the shoulders of midgets
  11. Stupid by ledow · · 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.

    1. Re:Stupid by Velex · · Score: 1

      I don't think you understand how capitalism works. It's the engineers who are trying to make this happen who are the incompetent dumbshits, and so stupid and uneducated compared to these CEOs. The CEOs are geniuses who are only hampered by how illiterate their engineers are.

      --
      Join the Slashcott! Stay away entirely Feb 10 thru Feb 17! Close all tabs to prevent autorefresh!
  12. Pointless by Anonymous Coward · · Score: 0

    I still don't get what OnLive offers to the consumer instead of just catering to industry participants. They seem to only be trying to push "See? We're on par with what we have currently!" instead of "We're actually offering something more to the consumer than existing solutions". The whole low-end devices argument is crap, wireless is going to be slow and unreliable, pretty much making OnLive irrelevant for small devices. Having it on today's computer seems kinda pointless, leaving only set-top box type solutions which seems fairly niche' in the first instance seeing as you're only going to get these latency numbers in certain areas anyway, that combined with existing solutions/competitors makes this failware.

    1. Re:Pointless by SharpFang · · Score: 2, 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.

      --
      45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
    2. Re:Pointless by fuzzyfuzzyfungus · · Score: 1

      What I don't really understand(though what might be part of why they don't seem to offer anything all that compelling to the customer) is how the economics of their operation stack up.

      With something like storage, or web hosting, there are fairly large and obvious gains to centralization and specialization. In the case of storage, the economics of not having a local copy are stupid, when a 1TB drive is $99; but unless your data are super extra secret, especially enormous, or you are atypically skilled, getting backup by buying 1 1 millionth of some professional data warehouse's capacity and sending incrementals over the internet is clearly sensible. Web hosting even more so. A tiny slice of some gigantic datacenter with multiple redundant enormous pipes is way cheaper than replicating that at home.

      Video games, though, don't seem to offer the same arguments. Unlike, say, making good backups, which is a comparatively rare skill, console gaming is pretty seriously accessible. Worst case, you bribe some local 16 year old with a six pack to make it work. So there is no argument from skill specialization. Consoles have already carved out a "gaming appliance" market, and(particularly for casual games, flash games, and the like) using the PC that already needs to be working for internet access and word processing for a bit of gaming on the side isn't much harder.

      There is also no efficiency of scale argument: In something like storage, a fancy data-deduplicating, zippy-special-compression, etc. storage setup, as available to the pros, can handle rather more customers than a simple comparison of its total capacity to the sum of all the customer's data would suggest. Most home-user data are either in the form of unique; but fairly tiny and compressible, stuff like text documents, or fairly large; but far from unique, things like downloaded movies and songs. With games, though, that effect is much smaller, if present at all. Console games are generally designed to be at the limits of their hardware, since those limits are fixed. You might, if buying in gigantic bulk, convince the console maker to provide you with their console in "processor card" format, allowing you to aggregate things like PSUs and mass storage; but, even in that ideal world, you are still buying as much silicon as joe gamer.

      Games are also relatively "bursty" which is bad. Because of latency/speed of light issues, you cannot aggregate demand across the globe, or even across more than a handful of time zones. So, everyone your datacenter serves will be on almost the same schedule. During peak hours, like shortly after kids get out of school, you'll need to be able to support almost as many instances as you have customers. During off-hours, you'll just have a few inverted odd-shift workers and the like. Unlike batch number crunching, an hour starting at 4am is nearly worthless to most of your customers.

      Then, of course, you come to the fact that "cloud gaming" inevitably incurs certain additional costs: bandwidth and video compression hardware. You'll see some bandwidth savings, since none of your customers will be downloading game or demo binaries from you, and because you will be able to keep multiplayer games, in some cases, occuring between multiple users within your datacenter; but the fact that you are sending 720p video constantly, to each one of them, will erode that pretty quickly. You also have to pay for, and power, whatever silicon is pumping out that video.

      This, I'm assuming, is why OnLive is charging a subscription fee just for the right to show up and buy stuff, and why the games they are selling access to are not, generally, forecast to be much of a discount over their retail counterparts.

    3. Re:Pointless by illumin8 · · Score: 1

      Cheap, dead-simple "Game rental", buffet-style. Pay per hour, not per game.

      I've tried OnLive, and yes, it is simple, but their game rentals are in days, not hours. I wish they had a pay per hour service, but unfortunately right now the game publishers are killing the service before it even started. Every game has a different rental price. For example, Borderlands costs $8.99 for 5 days or $5.99 for a 3 day rental, while Batman: Arkham Asylum is only $6.99 for 5 days or $4.99 for a 3 day rental. The publishers even have arbitrary restrictions like "this game may be played on PC clients but not Mac;" even though the OnLive client runs fine on Mac.

      I will give them credit: most games have a free 30 minute demo mode which lets you play 30 minutes for free. This is a great way to try out new games and find out if they suck or not before potentially buying them in a store. I would not buy a game here though - If OnLive goes out of business, and I can't see how they're going to make much profit, to be honest, all my games I've ever purchased are GONE permanently.

      When the "1st year free" offer runs out, I'm not going to resubscribe. $50 a year just to be able to pay full retail price to buy games stored in a digital locker that I can't even download to my own PC, and can only play at 720p with compression artifacts? No thanks.

      --
      "When the president does it, that means it's not illegal." - Richard M. Nixon
  13. Bandwidth != Latency by msauve · · Score: 1

    Latency was also reduced still further simply due to the masses of bandwidth FiOS offers compared to bog standard ADSL: in our case, 25mbps.

    No, it wasn't (at least not significantly). The difference in latency between a 1 mbps link (ADSL upstream) and a 25 mbps link (which is due to serialization delay) is about 12 ms for large (1500 byte) packets. Since the vast majority of packets sent in this sort of application would be small ones (having only to convey simple info like "button 1 pressed"), it would actually be well under a millisecond. Compared to the measured results, this is insignificant.

    --
    "National Security is the chief cause of national insecurity." - Celine's First Law
  14. Oh For Fuck Sake by QuantumG · · Score: 1

    How many people on this thread are going to confuse network latency with input latency... hint: you have no experience that prepares you to understand these numbers.. just play the god damn game and quit the service if you don't enjoy it.

    That's why they're handing out 12 month trials.

    --
    How we know is more important than what we know.
    1. Re:Oh For Fuck Sake by SharpFang · · Score: 2, 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.

      --
      45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
    2. Re:Oh For Fuck Sake by dtml-try+MyNick · · Score: 1

      Anoying yes, unplayable no.

      When I started playing fps's online, UT classic mostly, 150ms latency was pretty much the norm. Anything lower was considered a extremely good connection.

      Most players just compensated for the lag by aiming slightly off.
      Predict / anticipate the direction your opponent is going and adjust you aim according to that direction and the latency. Problem fixed.

      --
      Life starts at the end of your comfort zone.
    3. Re:Oh For Fuck Sake by Anonymous Coward · · Score: 0

      Did you even read the fucking post you just responded to? YOU'RE TALKING ABOUT NETWORK LATENCY. Input latency is not the same experience.

    4. Re:Oh For Fuck Sake by uncledrax · · Score: 1

      Actually he is alittle.. given the input is via the network.

      But looking at it.. the '150ms' was both the time it took for the input to go from the controller to the home box, be encoded, network out to the OnLive server, handle the input, render the scene, network the scene back to the users home, decode, and display on screen.

      So assuming everything else takes 0ms, that'd be around 75ms of 'input lag'.. obviously this is greatly flawed and overly simplicist.. but during that 75ms: Your scene is still being updated, and you can continue to provide input (that is.. track your target).
      75ms should be -well- within the tolerances of ANY online game..

      As with dtml above, I used to play UT99 with mid-200 pings and it played pretty darned smooth still, with only a rare issue with 'shooting someone that wasn't there' issues.

      --
      ----- The internet has given everyone the ability to have their voice heard equally as loud.. even if they shouldn't be
    5. Re:Oh For Fuck Sake by IKnwThePiecesFt · · Score: 1

      Oh my god, you obviously do not understand the conversation. Load up a shooter, and move your mouse. Now imagine a full fifth of a second later the view on the screen actually starts to move. That's what this would be like. That is not even remotely the same thing as your UT experience you're referring to. Imagine you're trying to lead the target but you can't because you have no 1 to one connection of how fast your crosshair moves compared to how fast you move the mouse.

    6. Re:Oh For Fuck Sake by SharpFang · · Score: 1

      If you want to hit with 150ms reaction latency, you lead the target -a little-.
      If you want to hit with 150ms input latency, you lead the target -a lot-. Approximately three times as much as with reaction latency. This is like 450ms lag.

      Thing is: with input latency, you aim at a point, your client receives your mouse input (time zero) and displays crosshair at that point (time zero), click. Client sends signal to server (time 150ms) later the point is calculated and if the enemy got there, you hit them, you receive the reaction another 150ms later but it is just a report on what happened.

      Now try the same with this toy. You aim your mouse at a point in the game. It is sent to the server (150ms), the server renders the image and sends it back to you (150ms) and you get the image displayed. You click and your shot is sent to the server for processing (150ms). Now if the point you pointed at 450ms ago (and saw 150ms ago as it looked 300ms ago) has an enemy on it -now-, it will count as hit. And you will see the hit in 150ms.

      Also, with reaction lag you visually lead the crosshair ahead of the enemy in realtime. With input lag, you lead an abstract invisible point with your mouse, your crosshair reacts with a lag to that, and -then- you have to lead the lagged crosshair ahead of the enemy like that.

      --
      45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
  15. Best part of OnLive - instademos by D+J+Horn · · Score: 1

    I too got in on the 1 year free trial to check it out. My connection is pretty average, 7meg verizon DSL, but being in the middle of nowhere I ping 150~200 in every game I've ever played, so I had pretty low expectations.

    I was very pleasantly surprised when I gave it a shot. There is definitely noticeable latency, but I only really feel it when moving the mouse cursor around. Button based actions seem fine. I probably wouldn't play a twitchy FPS on it, but just about any other game doesn't feel strange at all. Playing Arkham Asylum with a gamepad feels great.

    I have no intention of buying any games for it though - my only machine is a nice desktop so I have no need to. That being said, I am loving OnLive for the ability to launch it up and instantly play a demo of any game in there. No downloading, no installing, no waiting AT ALL. Not only that but the demos aren't specially packaged portions of the game - they are simply 30 minutes of access to the full retail game. This has already led me to make several purchases that I was on the fence about.

    So in the end, having seen it for myself, I think OnLive is pretty cool and does have its uses. It's certainly not going to replace PC gaming as we know it, but I think this cloud based tomfoolery has a place in our future.

  16. 200ms input latency by Tei · · Score: 3, 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.

    --

    -Woof woof woof!

    1. Re:200ms input latency by nmg196 · · Score: 1

      > You can have 10ms input latency with a server that give you 200 ping.

      I presume you meant those numbers the other way round? There is no way to get a lower input latency than the physical one the connection is running over, but it's easily possible the other way round.

    2. Re:200ms input latency by Tei · · Score: 1

      No, I exactly mean what is written.

      You input is taken into account locally, so the screen can be updated after 10ms, heres your input latency.
      But this change is "fictional", since the information is on the internet, traveling to the server, so the server don't know (yet) that you have rotated the camera/jumped/stuff.

      --

      -Woof woof woof!

  17. Forget the strategy games. by Tei · · Score: 1

    Lag with any "mouse" cursor is horrible, so all strategy or table games that need a cursor will be painfull to play with this.

    --

    -Woof woof woof!

    1. Re:Forget the strategy games. by Drakkenmensch · · Score: 1

      Anyone who has experience working with remote desktop applications knows how awful remote mouse response can be. Just imagine playing Starcraft through PCanywhere.

  18. 150ms doesn't mean 150ms in this case by Krahar · · Score: 2, Insightful

    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.

    1. Re:150ms doesn't mean 150ms in this case by Anonymous Coward · · Score: 0

      It'll be the same.

      Normal games with 150 latency process the input the exact same way. When a local game gets a response from the server, *then* it will update your local screen. No different delay than from receiving the screen image from the server.

    2. Re:150ms doesn't mean 150ms in this case by anstice8 · · Score: 1

      Not true. Many games update your location and refresh the screen long before you receive the "ok" for having moved. The server will only do something if you're hacking and have moved too fast in too little time. The reason for this is exactly what makes these "cloud" games unbearable, people don't want to wait 150ms to see their screen refresh after having pressed a button, they want to see the result asap and the server's keeping track of everyone and making sure no ones cheating. That's why in some games when you're sure you've headshotted someone and see them run off without injury, it's because of lag and you shouldnt start yelling "HACKER HACKER HACKER". So in the end the delay is extremely different. Games played locally atleast give you the impression theyre in real time, cloud games couldn't give you that impression without living next door to the data center.

    3. Re:150ms doesn't mean 150ms in this case by Krahar · · Score: 1

      As the other poster pointed out, there are games that update your position immediately, before getting an OK from the server. However, that's not the point in my post. The point in my post is that games frequently have a display that will tell you your latency, and I believe that this number is usually just the time it takes to send a ping from your computer to the server. So a game that would get 150ms latency in this test may only report 40 ms latency inside the game (I obviously just made up that number). In that case it is misleading to compare 150ms to 40ms, since actually those two numbers might indicate the same performance for the game since they aren't measuring the same thing.

  19. Beta Tester by se7en11 · · Score: 1

    I was able to get a beta testing account setup about 3 weeks ago. Most of the games play surprisingly well. But for the ones that require fast response times - Dirt, Unreal Tournament - there was just too much lag. Unreal Tournament was practically unplayable since it felt like you were running at 10fps. But for games like Lego Harry Potter, it works great. :)

  20. Can't see this taking off... by Fross · · Score: 1

    200ms input lag is huge. Really huge. The sort of amount that makes you feel like your computer is about to die. Bear in mind this isn't network lag, this is the amount of time it takes to react to your mouse moving, to change your direction with mouselook, etc.

    Supposedly it might get better the bigger connection you have. However, if you have a 5-10M connection as they recommend, it's simpler and probably quicker to download the whole game off Steam, or a torrent or whatever.

    The only way I can see this working is for people with very high quality net connections, and no decent rigs to run the games on (just enough to stream the audio/video). I'm not an expert but that seems a very specific and counterintuitive demographic.

  21. A $100 graphics card will beat this... by Joce640k · · Score: 2, Informative

    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...
  22. Re:"masses of bandwidth"? - poster is inaccurate by kangsterizer · · Score: 1

    ADSL maximum is 8mbit over copper and 12mbit over ISDN.
    ADSL2+ is 24mbit maximum

    So, 25mbps is not standard ADSL, *it does not even exist.* Moreover, reaching ADSL2+ maximum theoretical speed (24mbit) is extremely unlikely. Most of us have a speed between 1mbit and 20mbit in most cases (depending on line quality, modulation type, line distance to central, etc).

    Disclaimer: that's sync speed (IP bandwidth is therefore LOWER)

  23. Re:"masses of bandwidth"? - poster is inaccurate by Eunuchswear · · Score: 1

    Like I said, 25mbps is not much faster than a good ADSL+ line.

    25mbps is not much faster than 20mbps. It's only around twice as fast as 12mbps.

    (What do you mean by ADSL over ISDN?)

    --
    Watch this Heartland Institute video
  24. Last Sentence of TFA by Anonymous Coward · · Score: 0

    Read the last sentence of TFA:

    "Latency was also reduced still further simply due to the masses of bandwidth FiOS offers compared to bog standard ADSL: in our case, 25mbps."

    WTF does that mean?

  25. A DRM pusher's wet dream by Lunix+Nutcase · · Score: 2, Interesting

    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.

    1. Re:A DRM pusher's wet dream by Zathain+Sicarius · · Score: 1

      I've got a fourth for you. They don't even let you own your save data. If you delete your account, you can say goodbye to everything you've ever done with OnLive.

      Granted, they can also suspend your account for 6 months to preserve your data for a while, but the idea behind it is still insane.

  26. the perfect antipiracy protection by Anonymous Coward · · Score: 0

    forget all securoms, safedisks, ubisoft pile of crap. this is it.
    if you do not have it in your hands, you can not pirate it. and you can not pirate the game via displayed image. simple as that.
    hats off to these guys, I thought of this solution earlier and here it comes alive.
    I'd expect many many many more games to come with this kind of protection and OnLive will be the next big thing.

  27. Lag Kills by ctchristmas · · Score: 1

    Remember the days of playing Counter Strike on a 56k dial up connection? p.s. Reload sux!

    1. Re:Lag Kills by ducomputergeek · · Score: 1

      I remember the days of playing Xwing Vs. Tie Fighter on 56k and it worked pretty darn well over 56k. However, as broadband started to take off, it actually made performance worse for some reason. Granted that was back circa 2000.

      --
      "The problem with socialism is eventually you run out of other people's money" - Thatcher.
  28. in practice... by YesIAmAScript · · Score: 1

    Yes, latency and bandwidth are different concepts. But depending on the message sent, bandwidth can effect latency.

    Latency is the time it takes for the message to start coming through. But you don't get the end of the message until a time later which is determined by message size divided by bandwidth. And you can't act upon the tail end of the message until you've received it.

    So in the case of OnLive you're talking about a frame of video. They can't draw an entire frame until they've receive the entire frame. And that point it time is determined (among other things) by the latency of your network connection plus the bandwidth of your network connection.

    You can think of latency as the minimum time it can take a piece of information you asked for to get to you. But if you asked for more than the smallest transmittable unit, then the total time it takes to get the information is determined by latency and bandwidth.

    So stop banging your head, unless you are doing so to open it up to let new information in.

    --
    http://lkml.org/lkml/2005/8/20/95
  29. Re:"masses of bandwidth"? - poster is inaccurate by kangsterizer · · Score: 1

    ISDN is some digital phone line, its very wide spread in some countries such as Germany. (Integrated Services Digital Network)

    The ITU G.992.1 Annex B ADSL standard specify the ADSL modulation that works over ISDN. It's quite "recent", from 2005.

    By poster I meant story poster ;) I realized later its also from TFA anyway. I just meant to bring more precision/information to what you wrote basically.

  30. when i was a kid playing with a stopwatch by Anonymous Coward · · Score: 0

    I used to try and get the lowest time shown by starting and immediately stopping the stopwatch. after many many many repeats i was able to get the interval to show 0.01sec, that is 1/100 of a sec. I dont know if this was correct, i accept there may have been some lag in starting the counter that may be different from the lag in stopping the counter, but still I did find that my ability to get low numbers improved after repeated training. Also i felt that my ability to discern the tiny amount of time involved improved, together with my sensitivity. I wonder how sensitive professional athletes become, I'm aware that they train the ability to work a timing trigger either intentionally or unintentionally. I wonder what the human record for this is, I dont know that i've seen it in the guiness book.

  31. WE ARE NOT THE TARGET AUDIENCE by mbourgon · · Score: 1

    Look at all the ways Onlive fails us gamers:
    * Lower resolution that our monitors.
    * Extra fees to play the game - what is this, an MMO? And for multiplayer games with PC servers, how does that work?
    * The game will Not Always Be There - they "guarantee" 3 years, from what I saw.
    * Added latency
    * Always-on internet connection required: that's why I didn't buy AC2. F them and their DRM.

    For non-hardcore gamers (I won't say "casual", since that implies Peggle and the like), this is probably a good deal. Pay $180 over 3 years, which wouldn't buy a new machine (heck, my last graphics card cost more). Buy a game, play it once, then get rid of it - why replay when there's something new coming? $5 a month extra? Sure, worth it for the ease. DRM? What's that?

    It sounded clever as hell when I first heard about it. Now that I've seen it: meh.

    --
    "Sometimes a woman is a kind of religion, she can save your soul & set you free from all your sins" - Bad Examples
  32. Latency /= Bandwidth by iliketrash · · Score: 1

    The excerpt from TFA three times confuses bandwidth with latency. I'm guessing, with that lack of rigor, that the test results are meaningless.

  33. Redundant test by billcopc · · Score: 1

    From the very moment this idiotic service was announced, we geeks simply "did the math" and predicted this outcome rather precisely. Even if they had instantaneous video compression, they still can't exceed the base latency of the network. If it's already difficult to just receive conventional multiplayer packets quickly enough, then streaming a 100-fold larger video sure as shit won't make things any faster.

    It's not like a semi-decent gaming rig costs much anymore. You don't need quad GPUs and SSD raid to play Unreal Tournament, you just need a plain $450 PC with a $150 mid-range GPU. Sure, my $7000 workstation eats four instances of Crysis for breakfast, but frankly the same games ran just fine on my previous PC which was already 4 years old (except for Crysis).

    I know this for fact, because there's a very inexpensive AMD X3 system sitting at my feet, of which I've built and sold several to cash-strapped gamers, most often with a Radeon 5770 card. They might not crank everything up to "Ultra details" I'll bet it still looks sharper and more fluid than anything OnLive could deliver, because they are unfavorably bottlenecked - that's the nature of online video streaming, you have to choose a compromise between bandwidth and display quality, can't have both.

    "OnLive: for suckers, by suckers. The first ten callers will receive a special deal on this bridge we're selling, CALL NOW!"

    --
    -Billco, Fnarg.com
  34. Re:"masses of bandwidth"? - poster is inaccurate by Eunuchswear · · Score: 1

    The ITU G.992.1 Annex B ADSL standard specify the ADSL modulation that works over ISDN. It's quite "recent", from 2005.

    That's totaly bizzare.

    In my experience ISDN is run over copper pairs - often usimg DSL as the modulation (2mbps SDSL for a primary rate line). How the hell do you run ADSL over a slow digital line?

    --
    Watch this Heartland Institute video
  35. Re:"masses of bandwidth"? - poster is inaccurate by kangsterizer · · Score: 1

    I am posting from such a line :)
    It's common in Germany, most lines are digital only. It's actually slightly faster (12mbit) than the original ADSL (8mbit)

    ISDN actually runs over copper lines, but they dont have the equipment for analog lines, it's less expensive to run the ADSL over ISDN.

    You have a splitter so that you can still use a ISDN channel (for voice usually, although you could use it for data) and the rest is used by the ADSL.

    This document explains it better and in more details if you're interested:

    http://www.giif.com/CGI-BIN/projects/current/ISDN%20_DSLPostPaperv2.htm

    It works also with ADSL2 (and probably 2+) but I don't know the standard variant name. I'm actually on ADSL2 over ISDN to be precise.

  36. Re:"masses of bandwidth"? - poster is inaccurate by Eunuchswear · · Score: 1

    Ok, now I understand.

    Annexe B specifies how to run ADSL on copper that is also running ISDN (base rate) - it runs "ADSL over ISDN" in the same sense that annexe A runs "ADSL over voice". the difference between annexe A and B is which frequencies are avoided by the ADSL connection.

    --
    Watch this Heartland Institute video
  37. CRT by BlackHawk-666 · · Score: 1

    I kept using my trust old Iiyama 19" CRT for years after most people had switched over to those shiny looking LCDs. The main reason was because it could do decent resolutions at 110hz whereas LCD were plagued with 50/60hz cycle times and dodgey screen refreshes. It also had better colours and depth to my eye, the only bad thing being it was huge and had a mildly curved screen.

    I've finally switched over to an LCD that oddly still only syncs at 60hz (what is up with that!) but which doesn't greatly impede my gameplay. It runs at 1920x1200x60hz, looks great, and draws less power.

    I don't agree with their figure of 160ms for input lag, assuming this means the time between when I smack my key and see / hear some feedback. I'd think it's much close to 50ms at a guess - 150ms lag can mean you're dead in a FPS, whether that's from your network or your screen.

    --
    All those moments will be lost in time, like tears in rain.
  38. Onlive, after trying it out by Anonymous Coward · · Score: 0

    tried out Online after I got invited to the 1 year free deal. It got turned off after 30 min. Regardless of how you describe bandwidth and input lag the service is not usable for FPS games. I'm running a 10meg connection with a good gaming pc and the game was too laggy to be played seriously. The service might work well for stratagy games or older games that dont require as much bandwidth.

    I was also supprised by the system requirements since I thought everything ran on their hardware. If everything is running on there hardware then my pc set-up should not matter. Since it does and still ran UT with at least a 2-3 second input lag it is not worth using.

    IF You are looking at the service as a cheap way to rent games but all the new releases / top sellers on the Onlive service still cost $40-50 to activate and use, and after Onlive dies all that is money wasted on a game you can no longer access.

    I also wanted to point out playing the demo of UT (full version set to lockout after a set time) the game could not find any multiplayer games to join. So now you just paid for a game and have no one to play it with, hope you like to frag bots. Unless this is on purpose and multiplayer is disabled till you buy, and if thats the case they should say so since it was not de-activated in the game.

    The service still needs a lot of work to be usable for the majority of gamers. Being I'm in Idaho I might just be to far away from a server farm to use the service as well as some.