Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Insidious Creep of Latency Hell

CmdrTaco posted more than 3 years ago | from the defeat-the-lagbeast dept.

Software 297

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

Sorry! There are no comments related to the filter you selected.

O BIN LADEN !! (-1)

Anonymous Coward | more than 3 years ago | (#36016716)

Nice picture you took there !! Where's your nose !!

Re:O BIN LADEN !! (0)

Anonymous Coward | more than 3 years ago | (#36017030)

no nose arab is funny

ou navy seals shoot good

better shot than zarakowzi shot but f16 bomb takes skill to get shot

death to the fidels, am i right

I noticed this (3)

GeorgeMonroy (784609) | more than 3 years ago | (#36016730)

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.

Re:I noticed this (0)

MikeDirnt69 (1105185) | more than 3 years ago | (#36016894)

I think your synapses latency is too high.

Re:I noticed this (0)

Anonymous Coward | more than 3 years ago | (#36016916)

While virtually all software developed off-shore is absolute shit, that isn't the reason that applications like Eclipse, VS 2010 or Firefox are slow. I think the big problem with apps like those is that their North American and European developers have embraced the over-engineering of "software architecture".

Just look at Eclipse. It's all about "framework" this, "pattern" that, "abstraction" here, "component" there. For every line of useful code in its codebase, there are several thousand lines of supporting code that could probably be cut down significantly in number without any negative effects.

Firefox is much the same way, although with their own twist. Their mingling of JavaScript, XUL and Gecko isn't exactly a lean approach. Gecko itself has its own goddamn component model, besides much of its other code bloat.

For whatever reason, just writing the minimal amount of code necessary eludes these sorts of developers. It's like they go out of their way to find the most obtuse way to implement something that's actually relatively simple. Of course a slow, bloated application will be the end result of such shenanigans.

Re:I noticed this (2)

man_of_mr_e (217855) | more than 3 years ago | (#36017062)

It's fine to write lean and high performant code in a small application with a single developer. Once you have teams of people working on something, then you have to worry about something called "Maintainability". According to various studies, 80% of a piece of softwares total lifetime cost is maintenance and support costs. Nobody wants that to be come 90 or 95 or even 99% because people wrote code that others coudn't understand very easily.

Standardized frameworks, patterns, and components improve codes maintainability, often times at the cost of decreased performance. The idea is that hardware gets faster over time anyways, so you can write more features in less time with lower support costs.

Re:I noticed this (4, Insightful)

cpu6502 (1960974) | more than 3 years ago | (#36017282)

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:I noticed this (1)

Dishevel (1105119) | more than 3 years ago | (#36017578)

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

99% of what you use.
95% of what most people use.

Lots of code for shit no one ever uses.

They call them new features.

If they did not put in "New Features" why would you pay to upgrade?

Re:I noticed this (2)

pankajmay (1559865) | more than 3 years ago | (#36017616)

This issue is exactly why it is worth paying attention in those academic classes that are frequently labelled as out-of-touch with real world. (refer -- countless /. news articles on this).
Introduction to Algorithms, Data structures and advanced algorithms; and the math behind them. Unfortunately since the barrier to entry is so low in today's environment (Hey look I can code --- that is enough) and that coupled with the quest to recruit brute force programmers and not thinkers have led to this mess today where even though we have faster machines, the end result is actually a degraded experience.
Couple this with (to some extent artificially created by programming environments...) trade-off between maintainability and performance, and the situation gets even worse.
And of course combine this with legacy code -- even when written with best intentions, might have faster solutions today OR the legacy code worked well for a few hundred datasets, but you have millions of them today -- scalability issues and the reluctance to leave behind what works.

Finally -- in today's world -- we have an explosion of data -- it's data, data everywhere, but a lot of our tools and programming constructs still have an antiquated view of data -- processing it serially chunk by chunk.
So, it is a lot of factors that have come together to create this issue. The resolution: Computer Scientists need to go back to basics and build concepts of data storage, access, and processing from scratch. And the realization that there is a difference between people who can code, and people who can look at a solution holistically.
For example -- not every representation of a solution of a problem captures the solution space well. Choosing a solution representation as opposed to a naiive approach can make orders of magnitudes difference between hitting the target within well defined bounds, versus having unbounded solutions that never approach a significantly better phase.

Re:I noticed this (4, Insightful)

Nerdfest (867930) | more than 3 years ago | (#36017082)

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

Anonymous Coward | more than 3 years ago | (#36017020)

While I would like to blame a lot of things on cheapshoring, I think the issue comes down to two things, programmers not knowing or using the most efficient coding techniques and bloated software. Not bloated in the way I think you're suggesting but in the compiler itself. I still remember early Pascal and C where compiling 1 byte would give you a 10,000 byte module. I don't think things have changed much for the better, we just buy faster machines. There needs to be good optimizers to get rid of unused code. There's still something to said for coding in ALC.

Changing TV channels (5, Interesting)

Anonymous Coward | more than 3 years ago | (#36016748)

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 (5, Interesting)

Dr_Barnowl (709838) | more than 3 years ago | (#36016778)

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

JordanL (886154) | more than 3 years ago | (#36016886)

This does not explain the > 500ms delay when trying to use the guide.

Re:Changing TV channels (1)

Luyseyal (3154) | more than 3 years ago | (#36016948)

It might if it's getting the channel's feed in the background. It is annoying though. They really ought to consider a "just the listings, I don't want to see the channel at the same time" option. That would be a TON faster.

-l

Re:Changing TV channels (1)

El_Isma (979791) | more than 3 years ago | (#36017190)

Digital cable normally works unidirectionally, think multicast. The header sends information for all the receivers, is not point to point like the internet. So, it doesn't matter that you don't want to see the channel, they still have to send it because somebody else *might* want to see it. And, yes, the channel guide travels in the "background".

Re:Changing TV channels (2)

El_Isma (979791) | more than 3 years ago | (#36017162)

That's due to how digital cable works. I'll speak of DVB since that's what I know (I don't know what USA is using, but surely it will be similar). DVB sends a big stream composed of several smaller streams, some of those are video/audio streams, some are channel information (the guide, the streams IDs (audio/video/cc) of the channel, etc), others are info on the stream itself (carrier frequencies) or general information (time).

For the video stream, as the parent poster said, you'll have to wait to get a keyframe to start to view it (sending more keyframes means less efficient coding, means more bandwith per channel).

For some of the channel information, like the guide, you have a tradeoff between bandwidth and latency. Sure, you can stream the guide with almost 0 latency, but that means using a lot of BW to be able to send all the channel guides all the time. You have less available BW for channels, which means having to use more carrier freqs which means more money on hardware to send those signals (and possibly repeaters...). So, cable operators send the guide with a "reasonable" BW. The problem gets worse the more channels you have, since the channel guide has to be sent on all carriers.

Re:Changing TV channels (1)

Alamais (4180) | more than 3 years ago | (#36017280)

I don't understand why you wouldn't do it like my Dish receiver seems to: send the guide constantly, slowly, over and over, and store it. That way it may take a while (hours?) to first get the guide when you start the box up after installation, but once it has its first copy, it just has to delete old data and look for updates in the stream. You can have longer (more far-future-seeing) guides this way, and access is instant when you push the button. Even though it does the PiP thing in the corner while you browse, my receiver's guide has never bothered me latency-wise.

Re:Changing TV channels (1)

cpu6502 (1960974) | more than 3 years ago | (#36017340)

TV Guide is instant on over-the-air television. Mainly because the data is immediately available from the box's memory. Anything past 3 hours takes a little longer to fill-in, since those are only sent every 5 seconds. Past 1 day, the data is only sent every 30 seconds.

As for channel changing, I've noticed some boxes are slow as snails, while others are instant and display the picture almost as fast as analog. It all depends on the manufacturer.

Re:Changing TV channels (3, Informative)

Omnifarious (11933) | more than 3 years ago | (#36017208)

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

PhrostyMcByte (589271) | more than 3 years ago | (#36017348)

A cable box needs to have a separate tuner for each stream. Live TV takes one, each recording show takes one, etc. and such keyframe prefetching would also take at least one. Most cable boxes only have 2-3 tuners, and inevitably they're all going to be taken. So while this could definitely hide the latency in some situations, it's not a perfect solution.

Cable companies are also beginning to use SDV, which broadcasts channels on demand instead of all at once. Some latency will be involved here too, because your cable box needs to send a request to the SDV hub if it's not streaming the channel already.

Channels on each frequency (1)

tepples (727027) | more than 3 years ago | (#36017380)

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.

Re:Changing TV channels (1)

assassinator42 (844848) | more than 3 years ago | (#36017676)

I'm guessing Microsoft does something like for their IPTV platform (used in U-Verse in the US). You receive a unicast stream until the multicast stream is joined (and presumably another keyframe reached). Although this isn't always seamless and you can't rewind to what you received in the unicast stream.

Re:Changing TV channels (1)

BenoitRen (998927) | more than 3 years ago | (#36016942)

In my experience with Belgacom's digital TV, input latency is the norm. Most of the time when you input a command, it takes at least a second for it to execute. It's quite frustrating.

Re:Changing TV channels (1)

SheeEttin (899897) | more than 3 years ago | (#36016982)

This is just anecdotal, and probably a one-off kind of thing, but the other day my Comcast cable box/DVR was being very slow to do anything (i.e. press a button on the remote, wait several seconds for a response). I fixed it by unplugging it and plugging it back in again.

So, I guess what I'm saying is: have you tried rebooting it? :P

Re:Changing TV channels (1)

rsborg (111459) | more than 3 years ago | (#36017078)

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!

Or a more positive spin,maybe this will result in less TV watched. I've noticed that since we have gone Dish (wife must have TV5Monde), we hardly watch TV at all (the little tot watches the most, probably 30m-1hr a day avg, but this is all netflix streaming/DVR/appletv content).

If some startup or established company is keen on solving this, they could be highly disruptive in the TV space.

Re:Changing TV channels (1)

Anonymous Coward | more than 3 years ago | (#36017270)

You're not alone, brother. I first noticed the problem a few years ago on a hotel TV; I assumed they'd bought cheap TVs. Now, I act like a good consumer and get the latest piece of crap brand-name full-HD LCD TV, and I'm subjected to the same _degradation_ in performance of a basic function. Not one word in the reviews about that, either.

Oh, and PS, the Toshiba 32E200U has the single stupidest feature I've ever encountered: a two-level mute button (press once for 1/2 mute, twice for full mute). WTF were they on when they came up with that idea?

God, I hate TV. At least Bin Laden paid for his crimes.

Re:Changing TV channels (0)

Anonymous Coward | more than 3 years ago | (#36017388)

fast channel changing is also an unachievable goal due to hardware constraints. Tuners and cable boxes take time to lock, mpeg encoders need to fill video buffers, digital tuners need to wait for stream information and then the first I-frame. All of this adds up to MythTV's internal lag becoming a less significant portion of the problem.

http://www.mythtv.org/wiki/Feature_Wishlist

This is probably more related to MythTV, but still relevant

Re:Changing TV channels (5, Interesting)

TapeCutter (624760) | more than 3 years ago | (#36017768)

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.

N900 (5, Interesting)

Dr_Barnowl (709838) | more than 3 years ago | (#36016762)

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

blair1q (305137) | more than 3 years ago | (#36016836)

Is it a phone?

I use my "phone" for phoning and receiving phone calls and talking on the phone maybe...I dunno, 0.6% of the time it's lit up?

It's a computer. If I happened to put a phone in there, then that saves me having also to have a phone.

Though I will get a burner if I think Jack Bauer is on to me. Maybe a six-pack. I ain't stupid.

Re:N900 (1)

Americium (1343605) | more than 3 years ago | (#36016870)

I have the same issue. I think one of the most appealing things about the iPhone is simply how smooth and fast is reacts. It's like GNOME or KDE vs Windows 7, the slight lag just makes Linux not fun to use.

Re:N900 (1)

cforciea (1926392) | more than 3 years ago | (#36017032)

I use my iPhone really a lot (it is work issued and called all day), and I find that usually once every couple of days I fail to actually answer an incoming call because I can't actually get it to react correctly. Some of the time, I can't get the answer slider to move across, some of the time I have some frozen screen up that doesn't let me interact with the phone (I personally love it when the GUI for a phone call is up, only it is not live so I can't touch anything on it. I assume this has something to do with the background image for the call coming up without the actual interactive widgets being there). I also randomly have apps (including preinstalled apps like google maps) close without explanation and random freezes besides. I used to think it was because I was using an old beat up 3g with old-ish firmware, but my company recently replaced it with an iPhone 4 with updated firmware and very few installed apps and it has more or less the same problems (without dying pixels on the screen and a mostly dead battery that is not really end user replaceable, which is why the phone got swapped). I don't have a ton of experience using an Android to make a comparison, but I can't imagine that what I have should be the target of anyone's aspirations. I just can't figure out how they can put so much hardware into a phone and have it still be a substantially worse phone than the tiny Samsung dumb flip phone that I got for free with contract years ago.

Re:N900 (0)

Anonymous Coward | more than 3 years ago | (#36017066)

Huh? My iPhone is, far and away, the most frustratingly slow device I own. Sometimes it takes 3 full seconds just to respond when try to answer an incoming call.

Re:N900 (0)

Anonymous Coward | more than 3 years ago | (#36017144)

I've noticed on my T-mobile Comet the same sort of thing, only it seems more prevalent when the phone has been idle, meaning the lag seems to be the cpu's speed ramping up from low power mode when coming off idle. Still annoying, but maybe understandable. Reason softphones are something of a bad idea though.

Re:N900 (0)

Anonymous Coward | more than 3 years ago | (#36017158)

I find this hilarious compared to the stark contrast of horrible lagginess that was Apple's transition from 68K to PPC. The interface was PATHETICALLY laggy for years, so much so that I didn't want to touch a Mac for a long time.

ffs (0)

Anonymous Coward | more than 3 years ago | (#36017212)

wtf?? I have seen a lot of my friends struggling to answer their iphones. Are you just a fanboi in disguise?

As a N900 owner, I do agree with the GP. Whatever I have seen so far, HTC phones have best response overall (and believe me, I dislike HTC as much as I dislike Apple - for different reasons though).

Re:N900 (0)

Anonymous Coward | more than 3 years ago | (#36017272)

KDE defaults to Wintard mode.
GNOME defaults to Mactard mode.
The key word is *"defaults"*.

You are aware that in "Linux" you can change *EVERYTHING*? And if you don't (meaning you're not a computer user but a appliance player), it's the wrong OS for you anyway.

I recommend doing away with most of KDE/GNOME.
XMonad or Compiz (if you still want bling [which is NOT a shame!]) and a togglable overlay with a start menu equivalent and some other tools in it, that is always active and hence doesn't need loading, should do it. :)
Oh, and Opera as a browser and mail client... obviously.

I just run all apps I always need all the time. They just lie on other desktops. Load time: ZERO. :)

Re:N900 (3, Informative)

Microlith (54737) | more than 3 years ago | (#36016958)

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.

Re:N900 (1)

somersault (912633) | more than 3 years ago | (#36017252)

What do you mean about the messaging? My Dell Streak has been used a lot more for texting, web browsing , ebook reading and youtube than it has as a phone. Likewise my Xoom doesn't even have anything but wifi.. Android is no more a phone OS than iOS is.

Re:N900 (1)

Microlith (54737) | more than 3 years ago | (#36017292)

What do you mean about the messaging?

messing, not messaging. Regardless, they don't want you stepping outside the carefully set bounds of the Android OS and they try to enforce it by making you root the system.

The N900, by contrast, is a much more typical Linux system that you can freely enable root access via official methods. Tuning has definitely been needed, but my point against the GP was that I had not seen the latency he talks about in response to phone calls, and why the phone application wasn't loaded 100% of the time.

Re:N900 (1)

lewiscr (3314) | more than 3 years ago | (#36017314)

The HTC's aren't phones either. Nothing running Linux qualifies as "just a phone". This includes most "dumb" flip phones (which are running embedded linux, QNX, or some other embedded OS). The real time OSes usually handle it better, but I've had those sort of problems with them too. I don't remember the last time I had a cell phone that didn't have any applications (even if it was a manufacturer installed MP3 player app).

iReport (2)

RichardJenkins (1362463) | more than 3 years ago | (#36016776)

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.

RTFA (5, Funny)

Dog-Cow (21281) | more than 3 years ago | (#36016798)

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

Re:RTFA (0)

Anonymous Coward | more than 3 years ago | (#36016900)

I waited for it to load. And after looking at it for about a minute, I can't tell you exactly what's wrong with it, but I can tell you it sucks.

Re:RTFA (0)

somersault (912633) | more than 3 years ago | (#36017322)

I figured out one day that the reason I always thought Windows felt so flaky compared to for example Amiga OS was due to the awful window rendering.. you got flickery tearing if you tried to move a window around quickly. Also even Windows 7 looks like shit next to Ubuntu, due to what I presume is a lack of anti-aliasing in the fonts and other interface elements. Even at high resolutions it just looks tacky.

Re:RTFA (0)

Anonymous Coward | more than 3 years ago | (#36017424)

Even Windows XP has ClearType and I cannot imagine they removed it from Windows 7. No, the real reason Windows 7 looks like shit is that the design is horrible and cannot be changed (at least not without patching uxtheme.dll, themeui.dll and themeservice.dll). And of course the interface is cluttered, and inconsistent old Win9x applications don't look like new ones, and Media Player, MSN and Office do their own thing. Don't underestimate how much of the experience of something can be coloured by the design, even if it doesn't affect what goes on under the hood at all.

Um, stuff's slow. Make it faster. (-1)

blair1q (305137) | more than 3 years ago | (#36016804)

Computers do things in linear time. Even when you calculate O(whatever), all you're doing is telling the user how much linear time his inputs are going to soak up.

So if things are getting slower, it's because they're trying to compute more between user interactions.

So do what we've been doing since the dawn of digital: make it faster. Or wider. Or more parallel.

Re:Um, stuff's slow. Make it faster. (0)

Anonymous Coward | more than 3 years ago | (#36016896)

Congratulations on taking Algorithms I. We look forward to seeing you in Introduction to Operating Systems.

Re:Um, stuff's slow. Make it faster. (0)

Omnifarious (11933) | more than 3 years ago | (#36017244)

You confirm my decision to have you as a 'Foe'.

Re:Um, stuff's slow. Make it faster. (1)

PhrostyMcByte (589271) | more than 3 years ago | (#36017588)

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.

Worst Offender: Satellite Receivers (2)

omnichad (1198475) | more than 3 years ago | (#36016806)

I don't personally have Satellite, but it seems that almost every satellite receiver is underpowered to run the GUI.

Re:Worst Offender: Satellite Receivers (1)

gknoy (899301) | more than 3 years ago | (#36017176)

I've had a slightly different experience. I use DirecTV; while it's not the snappiest at changing channels, the channel listing menu is fairly responsive. In comparison, using my in-laws' (or my dad's) digital cable is like trying to use the application through a VPN into a slow windows ME box in Elbonia. Not only was it slow to change channels, the channel list itself had noticeable rendering latency and artifacts.

Re:Worst Offender: Satellite Receivers (1)

Alamais (4180) | more than 3 years ago | (#36017334)

I've got Dish's fancy (and under-supported) new VIP 922 receiver, and channel-change lag and UI response are complete non-issues. The usefulness of the built-in Sling support is another thing...

Re:Worst Offender: Satellite Receivers (1)

GuldKalle (1065310) | more than 3 years ago | (#36017320)

At least then you get the product slightly cheaper. I find products with plenty of cpu far more annoying. Take the Xbox 360 UI. A lot of the menu navigation has a delay of about 1 sec, just for doing some animation. And input is disabled in that time.

Can't things suck because they suck (0)

Anonymous Coward | more than 3 years ago | (#36016830)

without having to attribute it to some invisible deity. It is pretty easy to pin down lag as a problem. Was this ever difficult to identify with Quake or Unreal Tournament. Gimme a break.

slashdot (5, Insightful)

Anonymous Coward | more than 3 years ago | (#36016832)

Slashdot's Javascript.

The new slashdot interface (5, Insightful)

nu1x (992092) | more than 3 years ago | (#36016910)

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

hhedeshian (1343143) | more than 3 years ago | (#36017094)

+1 agree

Maybe slashdot should have a poll about it instead of how much you hate Sony; we already know that information.

Re:The new slashdot interface (1)

Anonymous Coward | more than 3 years ago | (#36017188)

The rest of us disabled javascript.

not so, sadly (1)

nu1x (992092) | more than 3 years ago | (#36017422)

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

Re:The new slashdot interface (3)

Culture20 (968837) | more than 3 years ago | (#36017460)

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.

Re:slashdot (2)

snowraver1 (1052510) | more than 3 years ago | (#36017114)

^^ this

Any popular story, such as the recent Bin Laden killing story, opens SSLLOOWWLLYY... It takes maybe 2-3 minutes to open, and during that time, the browser is unresponsive. (I have a single core HT laptop with 3 gigs of ram). Once the page loads, actually scrolling is a joke. The lag there is in the 5-10 second range. C'mon /.

Re:slashdot (1)

Sardak (773761) | more than 3 years ago | (#36017222)

Has it really gotten that bad? Luckily for me, NoScript blocks all of the javascript on here, so any page, regardless of its size, loads just as quick as anywhere else. They also have an option under the preferences [slashdot.org] to switch to the classic discussion system that might help as well.

Re:slashdot (1)

Intrepid imaginaut (1970940) | more than 3 years ago | (#36017414)

Use firefox instead of chrome. ;-) Works like a charm for me and I don't have your specs.

Re:slashdot (0)

Anonymous Coward | more than 3 years ago | (#36017522)

I'm using Firefox. Still takes many seconds to open and ~1.5 seconds to expand any post, ~0.8s for Reply to This to work, ~20s to Preview a post. !!

Re:slashdot (1)

snowraver1 (1052510) | more than 3 years ago | (#36017746)

I use IE7... It's a work laptop. My computer at home runs much better (FF on dual core AMD X2 with 4 gigs), but still I would expect better performance on IE7. I'm sure that I am not the only one using it on this site.

Re:slashdot (1)

milas (988484) | more than 3 years ago | (#36017560)

I'm using Chrome/Ubuntu 10.10 on an ASUS netvertible which uses one of the older low-powered Atom chips clocked at 1.33GHz, and while Slashdot definitely isn't the snappiest website, it loads decently quickly and scrolls smoothly for me. I don't understand where this unattainably high standard for the Slashdot JS came from. Much worse are Disqus powered websites! Of course nothing comes close to the mess of JS that is Facebook...

Not just Slashdot's JavaScript. (-1)

Anonymous Coward | more than 3 years ago | (#36017518)

All JavaScript is guilty of being slow and bloated.

JavaScript's first problem is that, semantically, it's a shitty language. It's not well-suited to fast implementations. Even with the stupidly huge amount of effort that Google, Apple, Mozilla, Microsoft and Opera have put in to improving their implementations, they're all still far slower than most of the scripting languages like Tcl, Perl, Python and Ruby that came out of the 1980s and 1990s.

JavaScript's second problem is that it appeals to fools. Good programmers don't want to go near it, mainly because it's a shitty language, with a shitty runtime environment. Only people who don't know other languages are drawn to it (of course, if they weren't so ignorant, they'd flee from it as quickly as possible, too). Since most JavaScript programmers are ignorant idiots, the code they write tends to be among the worst out there, and it often performs horribly.

JavaScript's third problem is that it interferes with better languages getting a foothold. Even if Google, for example, were to embed a real programming language like Python or Scheme within Chrome, the inertia that JavaScript holds would likely prevent the alternatives from being used.

Computing and engineering historians will look back and see JavaScript as one of the biggest screw-ups ever. It has brought so much harm, with so little benefit, while at the same time preventing the situation from improving.

Re:Not just Slashdot's JavaScript. (1)

The End Of Days (1243248) | more than 3 years ago | (#36017868)

Awww, was the troll afraid to put his name to the lies?

the olden days. (2)

radioteeth (1551375) | more than 3 years ago | (#36016838)

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.

Re:the olden days. (1)

Anonymous Coward | more than 3 years ago | (#36017210)

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.

I assume you're referring to NetQuake vs. QuakeWorld. The real argument was client-side prediction vs. no client-side prediction.

I questioned what the hell they were thinking (being that I was using the U of MN's slip/ppp dialup), and I hated ice-skating around in NetQuake. I then thanked the $DEITY the day that the QW beta started.

Client-side prediction taught me that for most FPS games (perhaps some other online game genres) you can play just fine with sub 150ms latency and a well implemented client-side prediction scheme.

CAPTCHA: playable

same as it ever was (2)

decora (1710862) | more than 3 years ago | (#36016904)

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.

Re:same as it ever was (1)

hhedeshian (1343143) | more than 3 years ago | (#36017058)

Why shouldn't he?

Sure, a lot of people use Linux on the desktop but (not counting phones) its server market share is (much) better. Frankly, if these patches are super-duper-mega-ultra-awesome, like you hint at, distro maintainers would be including them. I don't count phones because they're so far away from what you and I call "Linux" that it doesn't really count. I'm sure there are layers of proprietary garbage that would make latency worse with or without these patches.

Most Linux users use a kernel supplied by their Linux distribution. Some distributions ship the "vanilla" and/or "stable" kernels. However, several Linux distribution vendors (such as Red Hat and Debian) maintain another set of Linux kernel branches which are integrated into their products."

Linux Kernel [wikipedia.org]

VS2010 and smartphones (2)

MetalliQaZ (539913) | more than 3 years ago | (#36016924)

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

Re:VS2010 and smartphones (1)

Kral_Blbec (1201285) | more than 3 years ago | (#36017044)

How much of that is connection lag and how much is UI though? The connection is understandable, depending on signal strength and other variables. UI lag is not. If its lag in the browser its probably connection related.

Re:VS2010 and smartphones (1)

tepples (727027) | more than 3 years ago | (#36017452)

How much of that is connection lag and how much is UI though?

If touching doesn't immediately produce a visual or audio response that the device is trying to load something over the connection, then it's perceived as UI lag. That's part of why Slashdot has that little "Working" box with a throbber that pops up at the bottom of the screen when I preview a comment.

Re:VS2010 and smartphones (1)

umghhh (965931) | more than 3 years ago | (#36017102)

I hardly ever watch the TV (most of it is crap anyway and if I watch then I chose in advance and do not flip between channels). The phone I use has indeed lags sometimes but this has less to do with the languages or frameworks used but a lot with processors and batteries not being able to cope - not sure if they all still do it but they actually inserted slower processors into smart phones on purpose so that the battery lasts longer. Still I use my phone as a calendar, alarm clock and pin generator for my VPN connection. Occasionally I also take up calls from my boss but not all too often. Lag? what lag?

I also find the claims that java is slow preposterous - the problem lies in developers not having a clue or not having a choice and using legacy software while building fancy things on top of heavy and slow base applications. From this perspective java is to blame mainly because allows unskilled staff to fake good programming skills i.e. not code writing but thinking about how code is structured in advance. But of course I am a troll so mod me to hell for my half informed views.

Slashdot (5, Insightful)

Bobfrankly1 (1043848) | more than 3 years ago | (#36016950)

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.

Re:Slashdot (2)

tepples (727027) | more than 3 years ago | (#36017484)

The 10-second preview wait is to port scan your IPv4 address for open proxies. I compose long replies in Gedit or Notepad while I wait for Slashdot to catch up.

What the h&*)) is going on here? (3, Insightful)

rickb928 (945187) | more than 3 years ago | (#36016984)

I read about this right here in January [slashdot.org] . And February [slashdot.org] .

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 [google.com] '.

Slashdot is becoming the USA Today of the Internet. Isn't it time for another site upgrade?

Re:What the h&*)) is going on here? (0)

Anonymous Coward | more than 3 years ago | (#36017142)

The Latency Hell is the cause.

Re:What the h&*)) is going on here? (0)

Anonymous Coward | more than 3 years ago | (#36017394)

I wouldn't call that a slightly different emphasis. This article covers latency in current hardware & software, one aspect of which is bufferbloat; the other two articles cover bufferbloat. This article is far more general and therefore will both inform readers about different problems and lead to a different discussion. I don't see what your problem is (other than the obvious bitchiness).

Re:What the h&*)) is going on here? (0)

Anonymous Coward | more than 3 years ago | (#36017788)

I read about this right here in January [slashdot.org] . And February [slashdot.org] .

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 [google.com] '.

Slashdot is becoming the USA Today of the Internet. Isn't it time for another site upgrade?

Those who do not learn from history are doomed to repeat it.

strace / truss (1)

Rogerborg (306625) | more than 3 years ago | (#36017026)

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.

Re:strace / truss (1)

Shin-LaC (1333529) | more than 3 years ago | (#36017502)

Modern platforms have dtrace.

Finally! (0)

Anonymous Coward | more than 3 years ago | (#36017028)

I've been railing against game input lag for YEARS. Early on it was quite understandable since the hardware could barely keep up, and it was a part of gaming. But as the hardware has gotten more advanced IMHO it's an unforgivable sin of sloppy coding to still have input lag. Some game companies have gotten it right and their games are an effortless breeze to interact with - Naughty Dog/Insomniac comes to mind with their Jak & Daxter/Ratchet & Clank games, or Harmonix with Frequency & Amplitude and the earlier Guitar Hero games. The integration was so tight and smooth you could finally focus on the game itself and not on delaying your own reactions to fit the engine's lag.

And then things took a turn downhill, I could speculate why but I doubt we'll ever really know. God of War 1 was one of the worst in recent memory, and I could never understand how people raved about it. The input lag was AWFUL, made it almost unplayable especially when it was partially a platformer. And Guitar Hero 3 was absolutely dreadful, especially when compared to the previous lusciously smooth installments in the series. And I'm still on the fence about Assassin's Creed games - at times they seem fluid and quick to react, then you'll hit a sequence where everything goes to hell.

IMHO good interface (both visual aspects and really tight, quickly reacting control code integration) is one of the easiest ways to make or break a game. Look at Angry Birds - an incredibly simple game but the interface makes it effortless to play. If there was any lag in it at all it would make it infuriating.

Just my $.02

Java or Visual Studio 2010 anyone? (0)

MobyDisk (75490) | more than 3 years ago | (#36017064)

Anyone.... what? What are you trying to say?

Were you implying that Java or Visual Studio 2010 are sources of lag? You mentioned bufferbloat, a problem with video games, and a problem with Ubuntu. None of those involve Java or Visual Studio 2010 - although someone could edit or build code in those but the products don't add latency. So I don't think that is not what you meant.

Perhaps you personally experienced lag when using those applications. But Java isn't really an application, and nothing in Java intrinsically buffers things so I'm lost there. I assume VS2010 is slower than previous versions, and it uses WPF so that would be likely, but that still doesn't tie it to latency.

Could you reply and clarify what you meant? Or was this inserted by a Slashdot editor?

Re:Java or Visual Studio 2010 anyone? (2)

nomel (244635) | more than 3 years ago | (#36017284)

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.

Re:Java or Visual Studio 2010 anyone? (3, Insightful)

lgw (121541) | more than 3 years ago | (#36017590)

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?

Re:Java or Visual Studio 2010 anyone? (1)

sycomonkey (666153) | more than 3 years ago | (#36017488)

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.

Re:Java or Visual Studio 2010 anyone? (0)

Anonymous Coward | more than 3 years ago | (#36017538)

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.

Skytopia article (2)

MobyDisk (75490) | more than 3 years ago | (#36017170)

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

Slashdot too (0)

Anonymous Coward | more than 3 years ago | (#36017236)

I've noticed that lately the time it takes me to read the summary and the time it takes me to post a response worded in a tone implying that I am a highly qualified expert in the subject who has read the source material is increasing by tens of milliseconds every year.

I coveed it in detail in this months column (1)

seifried (12921) | more than 3 years ago | (#36017288)

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 [linux-magazine.com]

Lightning (2)

formfeed (703859) | more than 3 years ago | (#36017506)

Sometimes in a thunderstorm you see lightning, but it can take several seconds till you hear thunder.

Pretty bad design, imho.

irrelevant (0)

Anonymous Coward | more than 3 years ago | (#36017592)

Latency as a cause is irrelevant. As noted "they might not be able to tell you anything, and simply say the game sucked, without really understanding why it sucked."

Latency sucks. People who build products which have or induce high latency will have their products labelled by one and all as "sucky". It is a self-correcting problem, much like cars with "no oomf". People may not be able to tell you precisely why that car "sucks", but they all know it does. Hence the vast improvement in the responsiveness of KIAs in the last few years. If they want to sell, they have to change.

Shitty engineering... (0)

Anonymous Coward | more than 3 years ago | (#36017660)

...is everywhere!

Film at 11 (and 12ms latency while the channel changes).

Really (4, Informative)

geekoid (135745) | more than 3 years ago | (#36017744)

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?