The Insidious Creep of Latency Hell
Twinbee writes "Gamers often find 'input lag' annoying, but over the years, delay has crept into many other gadgets with equally painful results. Something as simple as mobile communication or changing TV channels can suffer. Software too is far from innocent (Java or Visual Studio 2010 anyone?), and even the desktop itself is riddled with 'invisible' latencies which can frustrate users (take the new Launcher bar in Ubuntu 11 for example). More worryingly, Bufferbloat is a problem that plagues the internet, but has only recently hit the news. Half of the problem is that it's often difficult to pin down unless you look out for it. As Mick West pointed out: 'Players, and sometimes even designers, cannot always put into words what they feel is wrong with a particular game's controls ... Or they might not be able to tell you anything, and simply say the game sucked, without really understanding why it sucked.'"
I thought things were supposed to get faster with newer technology but it does indeed look like the newer devices run slower becuase of bloated apps and firmware. Maybe this has to do with programming being "bestshored" =D nowadays.
You got the touch!
And here I thoguht I was the only one complaining that changing channels gets slower and slower with every new receiver box.
On analog it was basically instant, less than 100ms.
First digital box took half a second. Full HD box sometimes takes a whole second or more (and it's not even deterministic anymore)
That SUCKS big time!
The N900 suffers from this, alas.
I can't comprehend why the phone app isn't in memory on boot. It's a PHONE. Instead, when the phone rings you have to wait several seconds for the phone application to load.
In contrast, my wife's new HTC Z snaps and zings along with Android, even though it's "bloaty" Java / Davlik.
Whenever I use iReport there is about a sixth of a second delay between interacting with it and it doing what I asked. It's barely noticeable but still drives me insane.
I was going to read the article, but it took too long to load.
I don't personally have Satellite, but it seems that almost every satellite receiver is underpowered to run the GUI.
Slashdot's Javascript.
I miss the days where manually compensating for lag in games like Quake was unquestionable and accepted as a part of the multiplayer gaming experience. It's hard to imagine trying to cope with such a thing these days.
Linus Torvalds has rejected patch after patch after patch that would make Linux into BeOS style latency. He has rejected them all. Why?
because he wants to goose the server performance numbers. thats basically the story of the last 20 years of linux.
It actually drives me insane, it is markedly worse, I read less stories because of it (because I do not like the feel of the site so much).
I would bet most of the actual slashdot users feel (think ?) the same way. Why is there no mass appeal to change it back / forward in a more reasonable (i.e., simpler) direction ?
I have nothing to lose but my bindings.
I have definitely noticed addition latency in the UI with VS2010, and it has always bugged me. I can't be certain if it is VS itself or if the underlying WPF is to blame. My current belief, and I have no facts to back this up, is that the VS UI is simply much more complicated than the "typical" use case that was targeted for WPF, and as a result, low-to-mid range computers fail to meet a human's expectations of UI latency.
On a separate beef, why is it that so many people put up with the AWFUL latency on smartphones? Especially when browsing the web, it can sometimes become unusable. The phones get more and more powerful, but instead of making the last UI work, the designers just add more and more flashy crap instead. UI is just as slow but it looks cool in the ads.
When I don't have a real computer nearby, I can use the android browser when I need to, because I recognize the flaws and can patiently work around them. It kills me to watch my girlfriend attempt to navigate the interface of her nook color. Usually goes something like this...
1. press UI element
2. no response, press harder (because that's what humans do when a button doesn't work)
3. harder has no effect, start tapping repeatedly
4. UI finally changes, menu pops up and immediately goes away, having tapped on an unknown selection.
5. human gets mad, claims unit is broken, goes to check email on 5 year old PC.
As an added bonus, the PC doesn't require you to put your fingers in the way of what you're trying to look at.
-d
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
I had an incredibly insightful comment, but I forgot it while waiting 2ms for the comment interface to load. I remembered and forgot it again during the 10 seconds it took the preview to render.
I read about this right here in January. And February.
Seriously, how many times can you recycle the same story with slightly (and I mean slightly) different nuances, but the same frakking story?
Next thing you know, I'll be reading another story on this with the angle 'women and children affected the most'.
Slashdot is becoming the USA Today of the Internet. Isn't it time for another site upgrade?
deleting the extra space after periods so i can stay relevant, yeah.
If you don't know what those are, or how to use them, or they're just not available on your platform of choice, then you're part of the problem.
If you were blocking sigs, you wouldn't have to read this.
The first article in the summary has some silly ideas on how to fix this:
What can we do reverse the onslaught of latency in all its forms? ... First off, we can make LCD (or future OLED/QLED) monitors run at 120 or even 240 frames per second.
What?!?! 1) That is not possible and 2) That would not help. There are so many reasons for this I can't even list them all.
First, there isn't an LCD panel in existence that actually responds that fast. Those phony 240 hz screens don't actually change the pixels 240 times per second. We don't need faster displays to solve a software problem.
If the software provided a 1/60 second delay, that would be just fine. The issue is that we are not taking advantage of the refresh rates we have no - so increasing those rates doesn't help. Heck -- that's probably faster than the debouncing circuits in the controller!
Compensating for a longer pipeline by increasing clock speed doesn't help anyway, because to get the higher rate you need to increase the pipeline more...
I believe they were talking about the Visual Studio 2010 interface. If you've used something from some years back, you'll understand how insanely slow doing they've managed to draw text. I think it's all incredibly hilarious watching everyone squirm. It makes me feel better when I think I must be getting old because people seem to program without any thought involved...just library calls.
I cover how to measure buffer bloat, recreate the problem (trivially easy, in my case a single high speed upload saturates my 3 megabit uplink and ping times go from 50-60ms to 1000+ms. http://www.linux-magazine.com/Issues/2011/127/Security-Lessons-Bufferbloat/%28kategorie%29/0
Since many of these technologies transmit the data for all channels simultaneously, why not just scan for key frames and store the last key frame received for each channel?
Only a few HD channels are transmitted on each 6 MHz carrier. Scanning for keyframes on other carriers would need multiple tuners, which increases the cost of the cable box.
Uh, no ?
Taken from /. faq (if you have disabled js, trying to access some functions):
"Why does "This Function Require JavaScript?"
Welcome to the now, man!
Some elements of Slashdot's UI require the use of Javascript. In most cases we've provided backwards compatibility for the more paranoid folks in our crowd that are fearful of executing unknown code within their browsers, but sometimes it's just not practical to maintain a second UI for this. Right now this includes the customizable section menus, tagging, and a great number of user interface customization options. We know it's a potential security hazard, but sometimes you just have to jump out of the airplane to get that adrenaline rush. Try it sometime. Pack your own chute tho. "
I have nothing to lose but my bindings.
Also Java and Visual Studio tend to be used by less skilled developers and students (disclosure: i'm a student). Poor responsiveness of programs written in Java or using VS is more a factor of who is writing it than anything to do with the language / VM / IDE.
--The universe will not be altered by forum threads, even those which are very wry. --Tycho Brahe (Penny Arcade)
Sometimes in a thunderstorm you see lightning, but it can take several seconds till you hear thunder.
Pretty bad design, imho.
This isn't so much about computers doing things too slowly, or trying to compute too much. It's about computers sitting idle at the wrong times, or computing things too early or too late. It's about buffering -- which trades latency for throughput -- making it more and more difficult to coordinate those timings correctly.
In gaming you have screen lag, video card lag, render lag, input lag, and network lag. They all add up, and synchronizing their timings to make things appear fluid and lag-free is so difficult that most games end up leaving some not-so-corner cases uncovered.
Quality of gaming has been measured in FPS for so long that video drivers have been "optimized" to transparently buffer 3 or more frames if you turn vsync on. I've seen this alone destroy many unsuspecting games.
Wow, I've seen no input lag on VS2010 at all - and I run it in a VM which is hosted on my slow-ass laptop, so it's pretty starved for resoruces. I wonder what I'm doing right here?
Socialism: a lie told by totalitarians and believed by fools.
"(Java or Visual Studio 2010 anyone?"
Really? do you even know what the hell you are talking about? OR did these two think pop into your skull and you use your meaty finger to pound out some sort of text in a vain effort to stay relevant?
Replace:
Java or Visual Studio 2010 anyone?
With:
Crappy programmers.
And has anyone documented a repeatable real world test for 'bufferbloat' or is this still an academic issue?
The Kruger Dunning explains most post on
Awww, was the troll afraid to put his name to the lies?
This is one of the reasons why on all the devices and computers I use I disable animations when I'm permitted.
I think the real problem, however, is that we've grown increasingly impatient. I notice it in myself. Some application takes over 3 seconds to open and I start getting agitated, wondering what the hell is taking so long.
Think back to the earlier days of computing when it might take 30 seconds or more to get an application started. I recall on my PCjr booting up games and sitting there for a good minute while the drive ground away. That said, some games nowadays have some rather appalling load times. But look at what has to be loaded compared to those games from the 80s.
I also recall trying to play games that were more demanding than my computer could handle. I'd hit a key and get an action a fraction of a second later. I got used to it, but it's something that would be intolerable today.
Even using early versions of Windows and Mac OS was an exercise in patience, especially if something was going on in the background. And what about waiting for a simple website to load, especially over 56kbps? Hell, what about loading up text-only menus on your favorite BBS via 2400 baud?
The simple fact is that we've been spoiled and as such have grown increasingly impatient over shrinking timescales. That said, given all the computing power at the tips of my fingers I do expect everything to be instant.
"program without any thought involved...just library calls."
That's actually a good thing. Software will only progress when basic routine things are just called..
And there is a difference between using libraries and not thinking. You use know measurements and techniques to build a bridge, you don't recreate everything from scratch all the time.
The Kruger Dunning explains most post on
And then things took a turn downhill, I could speculate why but I doubt we'll ever really know.
It happened right about when you purchased a plasma TV, right? There you go.
Read what he has to say about Bradley Manning and you'll wet your kecks.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
.....I want to say it was around 2003 or so around here, when there were all sorts of discussions about "the cost of hardware and bandwidth is so cheap now, we don't need to optimize for the machine, we should instead optimize for the programmer". This came up again and again, and all the n00b programmers danced around their shiny Powermacs and sang and held hands and ratified it.
Notice how everything has exploded exponentially in size, and each revision of any bit of software has been noticeably more sluggish than the last?
This is why. Don't say I didn't warn you.
do() || do_not();
One key example I can come up with was the external folding keyboard for the Dell Axim X5 I bought as an "upgrade" from a Handspring Visor I was using for note taking in undergrad. The input delay was so bad that you could type several paragraphs before they would appear in the device. Totally destroyed the device for me, and I ended up going back to paper, as the Handspring was no longer in my possession. Not to focus on Dell, but my Inspiron 8000 had a similar problem, too. I got it as a desktop replacement when I started college, it had one of those early GeForce 2 GO chipsets, so it was capable of playing a game or two. Sadly, there was an odd latency to the internal keyboard that evaporated with an external, just bad enough to make FPS games essentially unplayable.
That's why I made him a foe in the first place. Not Bradley Manning per-se (he's a traitor, one I happen to not be all that upset with, but still), but with Wikileaks in general.
Need a Python, C++, Unix, Linux develop
What about the interface? I use it for hours on end daily on a 3 year old laptop and I notice absolute zero lag in drawing or anything else. Maybe you need to ditch the 15 year old dumpster-dived computer?
Visual Studio tend to be used by less skilled developer
Since when?
Well I only have a ipod touch 4, so it's doesn't do calls, but everything else is quick. My N900 doesn't do any UI smoothly, it looks like 24fps video.
Also Java and Visual Studio tend to be used by less skilled developers and students (disclosure: i'm a student). Poor responsiveness of programs written in Java or using VS is more a factor of who is writing it than anything to do with the language / VM / IDE.
Java and Visual Studio less skilled developers? Nope. No it doesn't.
But thank you for your disclosure, that explains a lot.
Visual Basic 4.0 starts up in three seconds on a ten year old computer. I have much more advanced IDEs on my machine nowadays, but if I just want to code up something for the fun and expect quick results, I'll still fire up VB4 from 1995.
Wow, really? Maybe you should try using notepad and vbc.exe to compile. Super quick!
Input lag is something I seem to be more sensitive to than most people. It is is my main, daily, frustration with my iPhone. I have a 3G, one of the last ones sold new, and although it was never fast even the first day I got it, it gets slower and slower with each iOS update. I can type out whole sentences before the screen reacts and shows the words, which usually results in mistakes. If I go slower to allow it time to display each keystroke I get a miserably slow, and I've measured this, 1 character (not word, CHARACTER) per second. Imagine the ticking of a clock, that's how fast I can input letters, any faster and it's unable to keep up. If I hold the phone in portrait view and then rotate it to landscape it can take as long as 12 seconds to respond. Restoring the phone doesn't help, this is normal behavior from the moment I reflash the firmware.
Starting an app can take 10-15 seconds, longer for more intensive ones. Google Maps (an Apple provided app) is one of the worst, it can take 25-35 seconds before I am able to begin inputting a destination. Moving around the map view is jerky and slow, and requires waiting after moving every little bit for it to redraw. When I use the iPod app, it takes 7-8 seconds before the controls become responsive after the now playing screen appears. I can sit there pressing pause or play and it just waits...and waits...and waits...and then decides to accept my press of the button.
If you build it, nerds will come. Soylentnews.org
I believe that is the alternate job title for the Chief Technical Officer at AOL.
I don't care if it's 90,000 hectares. That lake was not my doing.
If I hadn't posted already I could mod the gp up. Javascript is a significant misfortune for the world of computing.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Really? In all of the research I did, I found that the worst latency came from LCD TVs, not plasmas. It tended to be due to image "enhancement" algorithms that are more popular with high-end LCDs than high-end plasmas. Check out this "official" plasma input lag thread. Those guys do some pretty serious tests.
I should have just said flat panel. The big problem for most gamers is the loss of the CRT.
The latency problem in non-networked applications is ultimately caused by poor software engineering, starting with system-provided APIs. Most of "bog standard" system libraries were designed for something entirely different than what they end up used for. The "normal" C I/O paradigm is used everywhere, yet it was really designed for batch applications, not for interactive use. The only way to do almost any filesystem and network interaction should be to submit a request, then react when the results come back, all the while being receptive to other "results" (events) coming in. Unfortunately, designing things this way requires a certain discipline and a mindset, and default APIs and "industry practices" simply don't encourage it at all.
A correctly engineered system API should not have any blocking calls apart from the "wait for events" call, it's as simple as that. It's very rare that an application is only waiting for one thing to happen. Even something as simple as a UNIX cat has two file descriptors open, and simultaneously waits for stuff to come and and for stuff to finish going out, with a buffer in-between (I'm ignoring no-copy APIs for a moment). Coding it up as a read followed by a write is, at best, wishful thinking. Of course event-based programming is something that seems like a lot of extra work, but it's just a matter of getting used to doing things the right way.
In fact, if you decide to code up your whole system in an entirely reactive way, you gain other benefits. By reactive I mean you could reduce every application thread's interface to a single processEvent(event), run-to-completion function that you implement. As it turns out, it becomes almost natural to get the guts of the processEvent() function implemented as a state machine. The state machine formalism often helps in producing better quality code, and it certainly makes it very easy to trace interaction with the outside world. Miro Samek shows a striking example: the supposedly "so simple it couldn't possibly go wrong" calculator example from old Visual Basic has several bugs that stem from its bug-prone yet commonplace design. The calculator's state is spread out in an ad-hoc manner in various variables, and the tests done on those variables in response to external UI events pretty much amount to a buggy reconstruction of a single state variable to drive a state machine.
The state machine paradigm is in somewhat stark contrast to the way a typical GUI application is designed, where you have on_fooBar methods that get invoked when fooBar event happens. In the fooBar method it's up to you to verify that the application is in the correct state to do whatever fooBar calls for. This requires forethought, and status quo indicates that it's easy to get it wrong. Perhaps that's the reason: the de-facto mode of implementing reactions to external events is so broken that it's not used for much besides the GUI. Perhaps this is why "quick" system calls are usually done in line and end up blocking the whole application, or at least one thread, and those are not free either so why waste them with blocking APIs?! Apart from perhaps querying the current time or current username, there are really no "quick" system calls. Simple things like listing a directory or getting a key's value from the registry can potentially take seconds if your drive is thrashing around due to high I/O demand, or if the network happens to be slow.
Of course the line has to be drawn somewhere, so let's assume that paging of code, libraries and heap is something we should not worry about because it cannot be helped much. At that point one realizes that indiscriminate memmapping of data files can be problematic in itself: a memory-mapped file is, after all, supposed to hide the fact that you are doing a request-response that can be either very fast or very, very slow. The latter is something you should explicitly handle, and with memmap it's at best cumbersome: you have to use some API to check if given page is av
A successful API design takes a mixture of software design and pedagogy.
You -did- try the calibration in the options menu, right? The one that lets you tune the latency compensation?
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
I've long been thinking about using or creating and using a real-time language for user interfaces. What I have in mind is a language where you can specify time constraints as part of the contract for functions, and the compiler will then enforce those by refusing to emit code if that code would take longer to run than permitted by the time constraints.
Obviously, there are some hurdles here: not every computer is equally fast, many operating systems introduce unpredictable timing, and so on, but I think it would be interesting to at least see how close we could get. I really think the user experience would be much better if at least the user interface always responded quickly to user input.
Please correct me if I got my facts wrong.
I was mainly talking about the GUI from both VS and the apps that Java tends to create.
Why OpalCalc is the best Windows calc
I'd venture a guess that you're not using:
I should note these experiences were all on a quad-core, 8gb of RAM 64-bit version of Vista, but we had developers on XP and Windows 7 finding exactly the same.
Thank goodness I don't have to deal with Visual Studio any more. It's fine for small projects, but as soon as you start having large, enterprise-scale applications, the constant freezes and lag become unbearable.
I have similar problems with mouse controls in some games. For example, in Fallout: New Vegas the mouse moves by several pixels no matter how little and how slowly you move it physically. Overall the mouse controls make it an extremely poor shooter when compared to many FPS games. Luckily the game has a lot of other things going for it, but if it was a pure shooter, I wouldn't play it for even 5 minutes.
Imagine hitting "channel up" on your remote control and waiting... waiting... wondering if the infrared signal made it to the receiver or was blocked somehow, only to finally see the channel change a full minute later. It's my daily experience with my digital cable company.
Amen! I dread the day when my 22 " Sony CRT will die (it's coming, I can see the sings). Should have bought 2-3 monitors at the end to see me through the next 2 decades. After that I would be too old for gaming anyway.....I did such a preemptive purchase with the Seinheiser PX 100 head phones. Those are brilliant for their price range. No, they are better than many models that are twice as expensive. Fortunately Seihn kept them going, but there was a period when all stock was depleted....
Another unbelievable latency issue is HDTV. The audio often fails to be synchronized with the video. It is particularly annoying when the video is behind the audio. This happens frequently on all types of telecasts. I have spoken to a TV station engineer about this, and incredibly, there is no standard way to ensure that the audio and video of HDTV are in sync. Someone at the station can make an adjustment for a particular program, but the offset can be completely different in the next program.
I see this often on direct reception via antenna. No telling what weird latency problems are added when the signal is transmitted through a cable or satellite system.
HDTV in general has at least two or three seconds of latency compared to analog. When you're watching a "live" event, you're not.
Individual TV receivers introduce varying latencies. If you have multiple TVs set to the same channel, you can see and hear this. That ought to be a published spec on TVs, as well as the other gadgets mentioned in the article.
Computers obey me.
Ahh, good point. I avoid all of thiose things. Especially: everything that involves XML usage by VS has been impossibly slow since they switched over to XML formats (and I can't understand how they could have done XML parsing so slowly - boggles the mind).
VS is a great editor and debugger (even in a large shop), but the related source control/build environment is useless at scale. I don't understand why people use it that way - never seen it done right, maybe?
Socialism: a lie told by totalitarians and believed by fools.
I was very wary about buying an LCD monitor a couple of years back due to latency and off-angle viewing. But the one I ended up with (Hazro 24" S-IPS) works a treat. Unless you notice lag even more than I do, something like that should be fine. Make sure you get an IPS panel though as the cheap TN ones are crap. Alternatively, you could wait for Blue Phase mode LCD or the upcoming OLED TVs which should correct all problems (including blurring).
Hardforum.com or avsforum.com is probably a good place to start your research as they know a bit more about lag compared to most.
Why OpalCalc is the best Windows calc