Slashdot Mirror
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.
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.
Sometimes in a thunderstorm you see lightning, but it can take several seconds till you hear thunder.
Pretty bad design, imho.
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
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.
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.