The many faces of latency creep The insiduous creep of gadget and software lag. The insidious nature of latency creep -------------- <100ms = instant according to: http://en.wikipedia.org/wiki/Comparison_of_latency_and_bandwidth --------------------- Take yourself back to the 90s, when digital TV was but a It started off innocently enough, as time lag was rarely an issue with hardware of old. Everything from changing TV channels a couple of milliseconds spent here, a few there. http://en.wikipedia.org/wiki/Latency_(audio)#Audio_latency_in_live_performance overdrive input lag lots of vitriol has been spewed forth slippery sloppy ----------------------- turning into a flame war ======================== ----------- http://forums.devshed.com/c-programming-42/elapsed-time-accurate-to-1000th-second-615953.html?pp=15 With CRT monitor: 20ms human response on average (take top 20% of results) + 10ms to take account of refresh rate and other gubbins. Thus, 30ms would be reported on average. With 30ms lag LCD monitor: 20ms human response on average (take top 20% of results) + 10ms to take account of refresh rate and other gubbins + 30ms input lag of LCD monitor: ===================== guitar hero, yes compesate helps, but will still feel disconnected. and shmups need the fast reactions whatever. ==================================== http://getyourwebsitehere.com/jswb/rttest01.html - reaction test. ==================================== http://www.eurogamer.net/articles/gdc-why-onlive-cant-possibly-work-article http://hardware.slashdot.org/story/04/09/27/0016253/Does-Your-LCD-Play-Catch-Up-To-Your-Mouse http://www.bluegartr.com/threads/86413-OnLive-48-Mins-Video-Demonstration - internet lag around 100ms http://gettys.wordpress.com/what-is-bufferbloat-anyway/ - what is buffer bloat anyway? http://www.bit-tech.net/hardware/monitors/2009/02/06/the-dark-side-of-overdrive/1 - The Dark Side of Overdrive http://hardware.slashdot.org/story/09/02/06/1652226/Input-Lag-Or-Why-Faster-Isnt-Always-Better - Input Lag, Or Why Faster Isn't Always Better http://games.slashdot.org/story/10/07/08/051248/OnLive-Latency-Tested?from=rss + http://www.bluegartr.com/threads/86413-OnLive-48-Mins-Video-Demonstration http://en.wikipedia.org/wiki/Input_lag http://hardware.slashdot.org/comments.pl?sid=1359743&cid=29333609 - funny slashdot post dissing killzone ===== "All you need is a PC with a dual output graphics card, a screen you suspect of lagging, a second display with little or no lag, a decent digital camera and a stopwatch application (alternatively, you can use the embedded input lag stopwatch in Lagom). Simply configure the two monitors in clone mode, fire up the stopwatch app and begin taking pictures." ============================== In this case, digital decoding is probably mostly to blame, but even with analogue signals, this TV took 1 second to switch). Clocks in at 0.5s ============================ Dave Reed was shouted down and ignored over a year ago when he reported bufferbloat in 3G networks (I’ll describe this problem in a later blog post; it is an aggregate behavior caused by bufferbloat) ==================== http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/ I terms of technical insight and investigative ability this was a HUGE hit out of the ballpark. Way out. You not only got a home run, you hit it over the stands, past the parking lot and it’s bouncing over the highway as we speak. Internet history in the making. No question about it at all. Beyond belief you deserve the gratitude of, well, anybody with high speed internet access to the internet. --------------- Certainly the ISP’s share the responsibility for the problem with equipment vendors; the monomaniacal focus on bandwidth has cost us all tremendously, and we need to change the conversation from solely bandwidth to some bandwidth/latency metric to make progress. ------------------ Telling everyone “they are stupid”, or “they screwed up”, when it’s “we were complacent”, and “we all screwed up” won’t be at all helpful; it is why I chose the title I did for this posting. At some point late in this process of blogging, I’ll show bufferbloat in application software as well, just to complete the journey. It’s “we” who have made/are making this mistake. ------------------- See Nagle’s RFC 970 “On packet switches with infinite storage”. Even in 1985 the early roots of this problem were visible. --------------------- No perceptible delay to all human interactions requires less than 20ms (rubber banding is hardest) semi tolerable rubber banding needs less than 50ms typing needs to be less than 50ms to be literally imperceptible typing echo needs to be less than 100ms to to be usually not objectionable echo cancellation gets harder as well (the best echo cancellation needs to be done as close to all participants as possible, even the latency over a broadband link is undesirable). then there are serious gamers, where even a millisecond may be an advantage and the difference between life and death don’t even get me started about the financial loonies that got us into our current economic mess --------------------- I still can’t consider 20ms base jitter “good” however: that’s at the lower level of human perception, and gamers (and stock traders) care about latency differences to even an order of magnitude beyond 20ms. It’s still much higher than it “ought” to be from first principles. Latency is also something you never get back, and to get acceptable latency for a given application, you have to add up all the latencies; e.g. vertical retrace on the display, queuing delays in all switching/routing, delays in server/peer processing, speed of light, etc. You have to attack all sources of latency/jitter in the entire system, end to end. Speed of light means we’re almost always starting off behind; we should always be minimizing latency as much as we can. --------------------- The fundamental issue is that most practicing engineers think that losing any bits is bad; whereas the Internet was designed presuming that packets could/would be lost at any time and would indicate congestion was occurring. And with memory having become so cheap (in most places; I know the really high speed networking folks still have problems), we’ve been frogs in heating water. ===================== “sluggish”, “unresponsive”, “floaty” or “sloppy”. A better game might be referred to as “tight” or “responsive” ========================== http://www.urbandictionary.com/define.php?term=rubberbanding ==================== good links: http://www.gamasutra.com/view/feature/1942/programming_responsiveness.php http://www.gamasutra.com/view/feature/3725/measuring_responsiveness_in_video_.php http://www.measurepolis.fi/alma/ALMA%20Human%20Reaction%20Times%20as%20a%20Response%20to%20Delays%20in%20Control%20Systems.pdf http://www.eurogamer.net/articles/digitalfoundry-lag-factor-article http://www.gamasutra.com/view/feature/1942/programming_responsiveness.php?page=3 "Responsiveness, Not Reaction Time" --- http://www.useit.com/papers/responsetime.html - recommends 0.1s for 'instant' http://www.prad.de/new/monitore/specials/inputlag/inputlag.html http://smtt.thomasthiemann.com/ http://www.behardware.com/articles/632-1/lcds-images-delayed-compared-to-crts-yes.html =============== "response time" (also called "lag", "controller lag", or "input latency")