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

Comments

Changing TV channels

[Anonymous Coward]

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!

Re:Changing TV channels

[Dr_Barnowl]

That's down to compressed stream buffering. An analog box could be instant because every frame was transmitted uncompressed. With digital TV, you have to wait for a keyframe at least.

Re:Changing TV channels

[Omnifarious]

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? It might be that even just scanning for key frames might be too CPU intensive to do for all channels. But most people, when channel flipping, do so in a fairly predictable order. You could start doing this for the most likely targets for channel flipping when channel flipping behavior is detected.

Re:Changing TV channels

[TapeCutter]

When I was a kid I had to wait for the B&W TV to warm up, now I'm an old fart I have to wait just as long for the digital set top box to boot up. Somewhere in between I had a TV that came on instantly.

Re:Changing TV channels

[JonySuede]

it is the encryption technique utilized that introduce this lag. There is a key change at about 1s so it must wait until the next key to decode the stream.

N900

[Dr_Barnowl]

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.

Re:N900

[Microlith]

I can't comprehend why the phone app isn't in memory on boot. It's a PHONE.

As Nokia put it, it's a device designed around "mobile computing." The phone app is entirely secondary (unlike on most Symbian devices, which have physical buttons) and is mostly there as a convenience thing. The primary reason the circuitry for it is even there is for 3G data.

Instead, when the phone rings you have to wait several seconds for the phone application to load.

Which lies totally outside my experience, where it comes up instantly.

90% of the lag on the N900 is if you've just done something memory intensive (notably the browser) that caused stuff to be paged out to the eMMC, which isn't exactly fast. But the crippling problems that used to cause were resolved back in September or so with the PR1.3 update.

In contrast, my wife's new HTC Z snaps and zings along with Android, even though it's "bloaty" Java / Davlik.

That's because it's a phone, and not a more general purpose sort of device. In fact, they don't even want you messing with it which is why you have to root the damned thing.

RTFA

[Dog-Cow]

I was going to read the article, but it took too long to load.

slashdot

[Anonymous Coward]

Slashdot's Javascript.

The new slashdot interface

[nu1x]

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 ?

Re:The new slashdot interface

[Culture20]

I turned it off and went with the old style. I'll take a 5 minute wait between posts any day before trying to
r
e
a
d
t
e
x
t
l
i
k
e
t
h
i
s
And yes, the posts lower in the chain would often look like that with the most recent javascript fiasco. I have no idea whether it's still that ugly.

Slashdot

[Bobfrankly1]

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.

What the h&*)) is going on here?

[rickb928]

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?

Re:I noticed this

[Nerdfest]

For business development (not tools like FireFox, etc) it's not about being 'as fast as possible', but rather 'as maintainable as possible' while trying to be fast enough. When you write code to wring every clock cycle out of a CPU, the code tends to be difficult to maintain. Sometimes you need to do this, but in general you don't. People still write absolute crap in both situations of course.

Re:I noticed this

[cpu6502]

I'm not buying those excuses.

Why is it Microsoft Word 97 fits into my 8 megabyte 386 laptop, and has 99% of the same functions as modern Word, plus is quick and responsive. Why can't they bring that level of efficiency for today's Word 2010?

Because they aren't trying.
Because they don't care.
Because it's easier for management to tell users, "Go buy a new computer with 8x more RAM," than to pay programmers to make the code more efficient/responsive.

Re:Java or Visual Studio 2010 anyone?

[lgw]

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?

Really

[geekoid]

"(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?

Re:I noticed this

[Bourdain]

While I agree with your criticism of the parent comment regarding his lack of empiricism, if he were to change his assumption from

Why is it Microsoft Word 97 fits into my 8 megabyte 386 laptop, and has
99%
of the same functions as modern Word, plus is quick and responsive. Why can't they bring that level of efficiency for today's Word 2010?

to

Why is it Microsoft Word 97 fits into my 8 megabyte 386 laptop, and has
75%
of the same functions as modern Word, plus is quick and responsive. Why can't they bring that level of efficiency for today's Word 2010?

It all of a sudden holds more merit

While I'm not claiming to hunt down statistics to prove my point, I think it's safe to say there's absolutely some truth to lazy programming becoming more the norm than the exception in certain areas.

Do you really think some ratio of perceived/available functionality over ram usage has remained constant or significantly decreased?

Don't you hesitate when you're about to download an application for a simple task but the first one you find is, inexplicably, 100 megabtyes, compressed, whereas the 2nd one you find (and download) is 10 or 15? :)

I know I do

It's all in engineering

[tibit]

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

Re:I noticed this

[Bourdain]

Okay, let's say it's 50%

The only personal experience I have with this is that, among many other things I do professionally, usually at any organization I'm at (as a consultant or otherwise), I'm embarrassingly the "Excel guru".

Using Excel a moderate amount, I do try to use VBA pretty sparingly given its obvious slowness compared to other methods of calculation, but on occasion, it's markedly more efficient than other designs (e.g. testing for a series of involved conditions which would otherwise process extremely slowly using a formulas, etc.)

I've found that even on modern hardware, Excel 2007 VBA execution, of identical code, is much slower than Excel 2003.

For that reason, along with the sheer inefficiency of the ribbon design in terms of responsiveness and usage of screen real estate, I keep all Office 2007 usage relegated to a VM which I rarely even need.

To further clarify the issue, I have developed a personal library of macros I use in simply navigating spreadsheets efficiently. Even on modern hardware, Excel 2007 cannot keep up with my usage of these macros and throws errors repeatedly whereas I never see such errors in Excel 2003. Keep in mind, this is on modern hardware.

My interpretation of this is that speed and efficiency were low priorities for the Office development team. Given that their interface redesign was, I believe admittedly, largely geared towards novice users, these alleged low priorities make more sense.

To appeal to your sense of empiricism, which I appreciate, please see (perhaps not of the greatest quality...)
http://www.wilmott.com/messageview.cfm?catid=10&threadid=81967
http://www.excelbanter.com/showthread.php?t=137875
http://www.ozgrid.com/forum/showthread.php?t=78673&page=1

for what it's worth, I always disable screen refresh and calculation during a macro (except in rare circumstances when that behavior is necessary)