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 Android Lag Fix That Really Wasn't

Soulskill posted about a year ago | from the hop-on-one-foot-for-better-connectivity dept.

Android 226

jfruh writes "When Android was first introduced, it got much of its buzz in the open source community, and despite it being a mobile juggernaut backed by huge companies, it remains an open source project that anyone can submit code to. Thus, when a community patch that claimed to reduce the lag that still plagues the platform was created, it rocketed around various community code sites and was widely praised. The only problem: it didn't actually speed Android up."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Fist Ports! (-1)

Anonymous Coward | about a year ago | (#42567895)

Fist Ports!

java is shit (-1, Offtopic)

Anonymous Coward | about a year ago | (#42567903)

that is all.

Does it matter? (-1)

Lussarn (105276) | about a year ago | (#42567919)

Since modern android on modern harwadre don't lag I don't really give a rats as of what it was that made it work..

Re:Does it matter? (0, Troll)

Anonymous Coward | about a year ago | (#42568065)

Ah yes. I guess that's why Google desperately launched Project Butter to make Android smoother and less laggy. 'cause it doesn't lag, right?

gSheeps. You gotta love them.

Re:Does it matter? (2)

Lussarn (105276) | about a year ago | (#42568141)

I believe I stated modern. I would have no problem to tell you if my Nexus 7 or HOX lag, but they don't... I'm sure you can dig up a case where they lag, but normaly, they are fluid.

Re:Does it matter? (4, Interesting)

nxtw (866177) | about a year ago | (#42568409)

I can only speak for the Galaxy Tab 2 7.0, but modern Android devices are faster in part because of software performance improvements. Android 4.1 and 4.2 both have performance improvements, and upgrading the Tab 2 from the 4.0 it came with to 4.1 or 4.2 makes the OS visibly faster. The Nexus 7 comes with Jelly Bean (can't recall if 4.1 or 4.2 out of the box), so everything is fast to begin with.

In this way, Android is similar to Mac OS X - initial releases were rather slow, and subsequent versions (10.1, 10.2, maybe 10.3) were faster simply because there was a lot of easy optimization work to be done.

As an iOS user I didn't really like Android until Jelly Bean.

Re:Does it matter? (4, Interesting)

Alomex (148003) | about a year ago | (#42568807)

but modern Android devices are faster in part because of software performance improvements.

Historically you can always get more performance improvements out of software than hardware. Software improvements of 100x on bottlenecks are not uncommon (Google for example has made a ton of them in search, http, maps, etc). This is the same as running on hardware that is five or six generations in the future.

The classic quote is that primality testing has benefited more from better algorithms than from 40 years of Moore's law.

Re:Does it matter? (1)

Anonymous Coward | about a year ago | (#42569097)

Especially when there can be situations where if someone taxes an iPhone enough it'll show occasional stutters or quirks as well, especially when using third party applications. It's a comparison to a nonexistent ideal that is assumed to be true of iOS, and is all the more noticeable when using a past-gen iDevice using the more modern OS versions. My 4 lags regularly even within Apple's in-house crafted applications. Jelly Bean on older hardware is, shocker, the same way. There's optimizations which can be made but there'll almost certainly always be examples of lag or stuttering or UI quirks on any platform.

Re:Does it matter? (4, Interesting)

Xenna (37238) | about a year ago | (#42569131)

I like to try drum kit apps ( I have kids ). But on my Android phone there's a perceivable (and intolerable) lag when you tap the drums with all the apps I tried. On iOS (1st gen iPad) they're all nearly instantaneous.

Ever try anything like that?

Don't get me wrong, I'm not an Apple fan, I'd like Android to win, but not by closing my eyes for its faults.

Re:Does it matter? (1)

Anonymous Coward | about a year ago | (#42569491)

You are correct - however, I'm not sure if it's android issue of a hardware issue. I remember something like windows doesn't have any 0lag drivers, but linux did, but yiou had to use jax or something, not alsa. OSX has 0 latency and is great for musicians.
I wish someone else will come in here and state something like: yes, its software, lets build a new kernal for your android phone, or no its the hardware, buy this phone over here, it has no latency.

Re:Does it matter? (0)

Anonymous Coward | about a year ago | (#42569303)

A lot of people (like me) would say you are wrong about the Nexus 7. Once we got 4.2.1, they got slow and laggy again. Supposedly there is a fix in the works. But there are lots of threads on it - so it is not just an anecdote. Here's a link to one of the bug reports with a little over 100 people saying they have it too: http://code.google.com/p/android/issues/detail?id=39737 [google.com]. So something is causing that. I've actually been dismayed by how slow my 32 GB Nexus 7 got after the latest updates. I still like the device a lot, but it can be frustrating sometimes waiting for the screen to draw or waiting to turn a page when reading a book on it.

Re:Does it matter? (0)

Noughmad (1044096) | about a year ago | (#42568157)

The point of all such projects is purely PR. Google had to look like they were doing something about it.

Re:Does it matter? (0)

beelsebob (529313) | about a year ago | (#42568629)

If it didn't exist, then why the need to do something about it, or look like they were doing so?

Re:Does it matter? (1)

jedidiah (1196) | about a year ago | (#42569215)

They have to address all the trolls.

Otherwise they look like they don't give a damn about the end user. Most companies in a free market have to wory about that sort of thing. (pissing off customers)

Re:Does it matter? (3, Interesting)

sqlrob (173498) | about a year ago | (#42568089)

My Google Nexus tablet begs to differ with your assessment.

Re:Does it matter? (1)

poetmatt (793785) | about a year ago | (#42568139)

And? My google nexus tablet begs to differ with your assessment, you insensitive clod!

no really - mine runs quite smooth, even if battery life went to crap after the latest patch.

Re:Does it matter? (1)

sqlrob (173498) | about a year ago | (#42568211)

Links coming up in Chrome from external apps are slow as heck. Once Chrome starts it's fine, but it just sits there. *Tap* 5-6 seconds, then Chrome.

Haven't noticed anything about battery life, although I had previously disabled Currents, which is the supposed cause.

Re:Does it matter? (3, Interesting)

Mathematiker (2759663) | about a year ago | (#42568587)

This might be related to chrome.

Maybe you want to try firefox for android - it works quite well for me. If it turns out to be faster, it's still google's fault, but then you know the chrome guys are responsible, and not the android guys...

Re:Does it matter? (4, Interesting)

jtownatpunk.net (245670) | about a year ago | (#42568105)

I've only been using Android since 2011 and my devices have never had any kind of lag. Maybe because I have Nexus devices that aren't encumbered by third party skins and interfaces.

Re:Does it matter? (0)

Anonymous Coward | about a year ago | (#42568171)

Which was not the source of the lag. The lag was endemic to Android itself.

Re:Does it matter? (1)

nyctopterus (717502) | about a year ago | (#42568529)

All touch devices have lag, including iOS, and it's significant. Anyone that's tried to draw using these devices knows this. Check this out: http://www.engadget.com/2012/03/10/microsoft-cuts-touchscreen-lag-to-1ms/ [engadget.com]

Re:Does it matter? (1)

ozydingo (922211) | about a year ago | (#42569195)

Interesting research, seemingly terrible reporting by Engadget. Seems to me that MS did not "[cut] touchscreen lag to 1ms", they simply demonstrated via a test device (which appears to be projecting light from above) what different amounts of lag look / feel like.

Re:Does it matter? (4, Interesting)

BitZtream (692029) | about a year ago | (#42568849)

Or you just don't notice it.

I find that anyone used to an iOS device can pick up a Nexus 7 and notice the lag.

If all you use is Android devices, you probably don't notice.

Its not actual lag so much as poor UI choices that are perceived as lag at this point in my opinion, but I most certainly can 'feel' the lag.

Re:Does it matter? (0)

Anonymous Coward | about a year ago | (#42568981)

I have a Galaxy Nexus and I notice the lag mostly when browsing the web.

Re:Does it matter? (0, Flamebait)

jedidiah (1196) | about a year ago | (#42569235)

> I find that anyone used to an iOS device can pick up a Nexus 7 and notice the lag.

I find that you're full of shit. We're people that were used to PhoneOS devices and then defected to Android devices. I was actually a little surprised how quickly the non-geek iFan in the household took to Android.

I figured that "ecosystem" would at least hold her back.

"lag" has never been an issue.

Re:Does it matter? (3, Informative)

Xenna (37238) | about a year ago | (#42568903)

Possibly. I never had a 'nexus', just the basic Samsung stuff. One problem that I noticed is when running 'drum kit' apps. I have tried some on my Android phone and several on my iPad (1st generation). On the iPad the drums react almost instantaneously. On the androids there's a noticable (and fatal) delay.

Did you ever try anything like that on you nexuses?

Re:Does it matter? (1)

Anonymous Coward | about a year ago | (#42568121)

Yeah, since Android 2.1 I haven't got any lag on my Android phones and I have used from 107€ to 370€ smartphones (those are retail prices without contract and CPU was from ARM6 600Mhz to 1.2Ghz ARM7 etc).
Only problem what was between 2.1 and 2.3 (2.1 & 2.2) was that it could take 1-2 seconds to cold start a application but then it was fast.

And now when I have upgraded to 4.1 (on 2.1 phone) I have got only more speed and more nice animations.
The results of "Project Butter" was noticeable when I scrolled lots of different animations on webpage, but problem was not a lag, but the frame drops what the project fixed.

Lag = non existed
Frame dropping = rare cases before 4.1

Re:Does it matter? (1, Insightful)

XaXXon (202882) | about a year ago | (#42568751)

If you've used an apple device then an android device, you realize how slow android is. It's not terrible, but it greatly diminishes the user experience because the screen isn't glued to your finger.

Re:Does it matter? (2, Interesting)

BitZtream (692029) | about a year ago | (#42568837)

Bullshit fanboy.

Even the Nexus 7 lags. I'll buy that you don't' notice it, but it most certainly does. I've had and returned two Nexus 7s hoping to find the lag had been fixed, but it hasn't.

Part of the issue is the way apps are written rather than the OS at this point I think. The play store is a prime example of visible lag that exists due to a poor app design.

Scroll through the play store on a nexus 7 device quickly and it'll scroll fine then stop cold in its tracks, which a sliver at the bottom of the screen saying 'loading' or something to that effect. Technically its not lagging, but it sure as hell FEELS that way. The simple solution is to get a total count at the start, then calculate how far you can scroll total and not stop scrolling to display the loading screen, just scroll into blank space.

This scrolling into black space and loading later is what you'll find on Apple written apps for iOS and is why iOS doesn't get the same perception.

Yes, I'm an iOS fanboy, but I've TRIED to be a Android fan and I just can't do it. Put them side by side and the built in Apps on iOS will feel far better than those built into Android. Actual performance is irrelevant. How they feel matters.

The only people I know that say Android isn't laggy are people who don't use iOS devices. If you have nothing to compare with, you just don't notice.

Yes, 4.1 is smoother than 4.0, Yes, 4.2 is smoother than 4.1. But the apps need worked now that the OS isn't as bad as it once was. I've seen Android apps that don't lag, but the default ones due. Chrome has the same sort of shitty lag when scrolling, where mobile Safari doesn't.

Perception is far more important than reality when it comes to user interface. Another thing as an iOS user that makes Android 'feel' laggy is the lack of rubber banding on scroll. Yes, the Nexus 7 has the blue glowy thing when you try to scroll past the end, but again as an iOS user, it feels like lag to me as the blue glowy isn't all that noticeable compared to the rubber banding. Yes, I understand Android previously couldnt' do rubber banding due to patent issues, but my point is that while Android may not ACTUALLY be laggy, it still is perceived as such due to the UI.

You can deny the perception, but it doesn't change it to most people and it will certainly remain one of those things that you're going to hear from iOS users until it changes.

Re:Does it matter? (-1)

Anonymous Coward | about a year ago | (#42568943)

Dumbass iSheep. Even iOS devices lag. You're just so drunk on the koolaid to acknowledge it. iOS devices have always had the most powerful GPU's in the mobile space at their disposal to try and minimize it, though. The very fact that you need a 3 core GPU and a 4 core CPU to make your OS smooth speaks volumes about how optimized your OS really is. There was a time when Android didn't even use GPU's for acceleration. Imagine an iPhone with no GPU acceleration.

Re:Does it matter? (-1)

Anonymous Coward | about a year ago | (#42569565)

Perception is far more important than reality

I perceive you to be an idiot.

Technically its not lagging, but it sure as hell FEELS that way.

In fact I think you may be clinically retarded.

How important is "true" randomness, anyway? (5, Funny)

14erCleaner (745600) | about a year ago | (#42567943)

If the problem is that they can't generate "random" number fast enough, maybe they could just return 42 when the entropy pool is empty.

Re:How important is "true" randomness, anyway? (4, Funny)

Bogtha (906264) | about a year ago | (#42568025)

No, they should return 4 - it's guaranteed to be random [xkcd.com].

Re:How important is "true" randomness, anyway? (2)

gmuslera (3436) | about a year ago | (#42568205)

Or maybe 9 [dilbert.com]. Being random don't mean to be all different, or even to be evenly distributed.

Re:How important is "true" randomness, anyway? (1)

TechyImmigrant (175943) | about a year ago | (#42568649)

Intel's Digital Random Number Generator has a Dilbert mode (not available to mortals) in which it only outputs 9.
I had to choose between xkcd mode and Dilbert mode. Dilbert mode won.

Re:How important is "true" randomness, anyway? (4, Interesting)

fuzzyfuzzyfungus (1223518) | about a year ago | (#42568049)

If the problem is that they can't generate "random" number fast enough, maybe they could just return 42 when the entropy pool is empty.

It depends on what you are doing with that entropy. Cryptographic applications, probably best not to mess with. Mathematical simulation work? Please consult your handy local PHd, spawning little spaceships in your arcade game clone? Probably not an issue.

Because it's really application dependent, Linux has two ways of asking the kernel for entropy: Reading /dev/random will pull from the kernel entropy pool and block if the pool is empty. How fast the pool refills depends on the hardware platform, presence/absence of dedicated cryptographic hardware, interrupts and network activity, etc. Reading /dev/urandom will never block; but the results may be unsatisfactorily random if the entropy pool is low.

In either case, applications are also free to use material from /dev/random or /dev/urandom to seed their own PRNGs.

Re:How important is "true" randomness, anyway? (4, Funny)

Rockoon (1252108) | about a year ago | (#42568485)

"The generation of random numbers is too important to be left to chance." - Robert Coveyou.

Re:How important is "true" randomness, anyway? (1)

TechyImmigrant (175943) | about a year ago | (#42568665)

>In either case, applications are also free to use material from /dev/random or /dev/urandom to seed their own PRNGs.

Just because they can, it doesn't mean they should.

Re:How important is "true" randomness, anyway? (-1, Troll)

cuiagaha (2814257) | about a year ago | (#42569201)

http://www.cloud65.com/ [cloud65.com] up to I looked at the draft of $8374, I accept ...that...my neighbour had been actually making money in their spare time from there labtop.. there aunts neighbour started doing this 4 only 13 months and resently repaid the morgage on their cottage and bourt themselves a Ford Mustang. we looked here,

You mean that the placebo effect still works? (5, Informative)

toygeek (473120) | about a year ago | (#42567953)

This is why "vortex" generators for carburetors are still sold http://www.vorteccyclone.com/ [vorteccyclone.com] , Magnets for your fuel lines to "align the molecules" http://en.wikipedia.org/wiki/Fuel_saving_device [wikipedia.org] are still sold, and oddly shaped bicycle cranks http://z-torque.com/ [z-torque.com] are still sold. Its really no surprise that it happens in the software world too. Really, its been happening for a long time. Regcure, anyone?

Re:You mean that the placebo effect still works? (0)

Anonymous Coward | about a year ago | (#42568081)

Don't forget the biggest software (software specific, in general terms it's Scientology) placebo (or scam) : DoubleRAM.

Re:You mean that the placebo effect still works? (0)

Anonymous Coward | about a year ago | (#42568151)

I think you mean "RAMDoubler" which supposedly compressed your virtual memory, but did so ineffectively.

However VMWare currently advertises a similar feature.

Re:You mean that the placebo effect still works? (0)

Anonymous Coward | about a year ago | (#42568309)

Whooops. Yep. I meant RAMDoubler. Mea culpa.

Hey, RAMdoubler worked for Johnny Mnemonic (1)

billstewart (78916) | about a year ago | (#42568383)

Ok, it only works if you've got a cybernetic dolphin who can use SQUIDs to read you brain, but you could still become a very technical boy...

Re:You mean that the placebo effect still works? (1)

BitZtream (692029) | about a year ago | (#42568895)

RAMDoubler created a compressed swap partition. It actually worked as advertised, depending on your setup it may actually make things faster for you, but buying more ram was ALWAYS the proper solution.

VMware stores duplicate memory pages between OSes in a single instance across multiple running VMs. This is no different than what Linux, BSD, or Windows do with things like EXE backing stores already except VMware has to search out duplicate pages as it doesn't really know how the underlying OS does its thing but it DOES know how the translation buffer is configured. This also works as advertised and is why I have twice as much RAM allocated to virtual machines on my VMware server as they actually consume. Windows machines all doing essentially the same thing have ... lots of duplicate pages.

Re:You mean that the placebo effect still works? (0)

Anonymous Coward | about a year ago | (#42569169)

RAMDoubler created a compressed swap partition. It actually worked as advertised, depending on your setup it may actually make things faster for you, but buying more ram was ALWAYS the proper solution.

It was helpful in printing the ransom note when we captured Clippy.

Re:You mean that the placebo effect still works? (0)

Anonymous Coward | about a year ago | (#42569223)

RAM Doubler for Mac was a pretty well-regarded product because it completely replaced the crapola System 7 virtual memory subsystem. They then "leveraged their brand" into a Windows version which supposedly was no better/faster than Win3.1's VM -- and it got a lot of terrible press.

VMWare (some versions) not only de-duplicate but also do some form of memory compression.

Re:You mean that the placebo effect still works? (0)

Bruce Perens (3872) | about a year ago | (#42569161)

Maybe you should review RamDoubler on Amazon, where it's still for sale! here [amazon.com].

Re:You mean that the placebo effect still works? (2)

Noughmad (1044096) | about a year ago | (#42568187)

I've never heard of DoubleRAM, so it can't be that big. The biggest software scam has to be anti-virus.

Re:You mean that the placebo effect still works? (0)

Anonymous Coward | about a year ago | (#42568283)

If you were in the market for computers during the days of the 486 or Pentium, you would have heard about it. Couldn't step into a CompUSA without at seeing an advertisement. Yes. Hyperbole.

Re:You mean that the placebo effect still works? (5, Insightful)

fuzzyfuzzyfungus (1223518) | about a year ago | (#42568115)

The surprising thing, in both this Android case and the assorted car-widgets, is not that the placebo effect works; but that the "If it was that easy, why didn't it come from the factory that way" argument hasn't held more sway.

In the case of the 'vortex' device you link to, the argument is essentially that ~$1 worth of stamped metal could markedly improve the performance and fuel economy of most vehicles without other notable modifications. Short of a full-scale Petroleum-industrial-complex coverup, why aren't these things being bolted on at the factory?

In the Android case, it's not like entropy related issues are news to linux users or hardware makers. Devices that do lots of crypto(ie. network gear designed to support a lot of VPN users, http load balancers designed to serve a lot of SSL sessions, etc.) are frequently provided with dedicated hardware RNGs precisely to prevent performance issues on entropy depletion. VIA's more recent CPUs come with an on-die hardware RNG, and you can buy assorted RNGs for various expansion busses if your applications require it.

The issue isn't so much that you can entropy-starve a system and cause it to respond badly; but that(against a background of people already knowing that) Google went and released an OS that is somehow radically more demanding on /dev/random than most linux variants and didn't even notice? That would be a bit of a surprise.

Re:You mean that the placebo effect still works? (0)

Anonymous Coward | about a year ago | (#42568245)

I wonder if this could be solved by using a ghetto PRNG which may be less cryptographically secure, but faster. Of course, /dev/random is the best place, and /dev/urandom is good, but if one needed a ghetto source of unpredictable numbers, there is always grabbing a 256 bit salt and a 256 bit key from /dev/random, then just using AES-256 on a stream of zeros, re-seeding the stream every few meg or so... perhaps using a hash function like SHA-512 as a "bit blender" to further add some unpredictability.

It is ghetto, but it does give some fairly unpredictable numbers.

Don't ever write one yourself (2)

billstewart (78916) | about a year ago | (#42568655)

Bad crypto can cause you no end of trouble. There are people out there who know what they're doing who've written PRNG systems in the general direction that you're talking about, but understand what to do and not do in the designs. Some of it's pretty subtle, like only bringing in new entropy in big chunks rather than trickling it in, and knowing what crypto algorithms work well for applications like this and what don't. And some of it's tuning.

Go read the "/dev/urandom" Wikipedia page. [wikipedia.org] If you need Yarrow, use it.

The general speculation is that something in Android is using /dev/random when it would probably be ok with /dev/urandom, but nobody's sure quite what. Google Maps was mentioned; maybe it's using https to fetch map segments or something?

Re:Don't ever write one yourself (1)

mlts (1038732) | about a year ago | (#42568985)

This is good reading. There is good reason why people don't invent the wheel with cryptographic protocols.

Maybe it is time for a patch to the Linux kernel to make /dev/urandom non-blocking as well?

Re:You mean that the placebo effect still works? (0)

Anonymous Coward | about a year ago | (#42568305)

"If it was that easy, why didn't it come from the factory that way" argument hasn't held more sway.

Remove your cat converter from your car, fits your question, provides a provable performance increase, and is easy.
One year of Mustang came out designed for a chip swap that added like 20-40 hp, took about 5 minutes, was really easy.
Remove governor from carburetor on gas powered golf carts.

There are plenty of cases where its "that easy" and the factory didn't do it. Two of my examples were because of government regulation, one is safety related. The chip on the Mustang was the best one because with the proper chip it couldn't pass fuel economy, and Ford couldn't sell the proper chip. Ford made the programming available to other companies and I doubt there are any of that year's model still running on the road with the factory chip, it was actually that well known at the time.

Re:You mean that the placebo effect still works? (0)

Anonymous Coward | about a year ago | (#42568547)

There's also price discrimination -- Pro GPU cards are identical to consumer GPU cards but the driver enables extra features, 1GHz chips are identical to 2Ghz chips (but only tested/guaranteed at 1Ghz), etc.

Re:You mean that the placebo effect still works? (1)

Anonymous Coward | about a year ago | (#42569481)

Was that a reverse car analogy? Bravo sir.

Re:You mean that the placebo effect still works? (0)

Anonymous Coward | about a year ago | (#42568585)

Google went and released an OS that is somehow radically more demanding on /dev/random than most linux variants and didn't even notice? That would be a bit of a surprise.

It would indeed, especially because it didn't happen. Brought to you by... the article [google.com]: "only wpa_supplicant opens /dev/random, and it doesn't continuously do that."

Re:You mean that the placebo effect still works? (0)

Anonymous Coward | about a year ago | (#42568883)

The issue of /dev/random and /dev/urandom crops up periodically on real systems. Its very hard to predict this will happen - the sum of activity of all apps can lead to this effect. If its bad enough, people investigate and simply swap /dev/random for /dev/urandom, thus defeating the purpose of /dev/random. This issue, on Android, can certainly occur if lots of background apps are periodically/continuously connecting for updates, e.g. email, facebook, twitter. So, users are likely to find the device slows down as the cruft accumulates.

The problem can/could get worse. As phones have 2GB RAM, more active apps can be left running.

Now its known about, hopefully, it will happen "less".

Sometimes it *IS* that easy. (0)

Anonymous Coward | about a year ago | (#42569179)


Re:You mean that the placebo effect still works? (0)

Anonymous Coward | about a year ago | (#42568779)

I don't use android, but on my Panda board (small ARM based board) running linux, I use rngd to add entropy to /dev/random from /dev/urandom. After doing this, hostapd no longer would hang with no entropy (one or more of the wireless interfaces would stop accepting authenticating new users until the associated hostapd instance was restarted or, interface(s) would never start on initial power on). I didn't really notice any other differences, but having a reliable access point where it wasn't before demonstrates that this does "fix" some things. So, maybe an underlying linux /native daemon fix that actually does help things even if davlik doesn't use /dev/random.

I don't know about this android app to do this seeding, but rngd tests the source data before using it to seed /dev/random to make sure it is decent random data which is good enough for my purpose and with the mix of true entropy is probably better than using /dev/urandom directly. BTW, rngd is _supposed_ to be used with a hardware random number generator.

First Post (5, Funny)

Anonymous Coward | about a year ago | (#42567959)

but sent using Android, so...

article doesn't make sense. (5, Interesting)

darkHanzz (2579493) | about a year ago | (#42567969)

The butter project was about latency with user interaction. The issues talks about /dev/random, which is totally unrelated.

Re:article doesn't make sense. (1)

sribe (304414) | about a year ago | (#42568047)

The butter project was about latency with user interaction. The issues talks about /dev/random, which is totally unrelated.

Well, you'd hope it was unrelated, but sometimes I'm no so sure ;-)

Re:article doesn't make sense. (2)

hey (83763) | about a year ago | (#42568297)

Look at the first sentence of the linked page: The Linux entropy pool is frequently empty as Dalvik appears to always use /dev/random, which depletes the entropy pool and will block when the pool is empty. This blocking results in user perceived poor performance.

Re:article doesn't make sense. (1)

Nerdfest (867930) | about a year ago | (#42568419)

I was under the impression that the fix did actually speed it up, but at the cost of battery life. You could have got effectively the same performance enhancement by changing the process scheduler to 'performance' rather than 'on demand'. As someone with an older phone running Cyanogen, I was hoping this fixed helped. My performance problems tend to be more memory related though as the older phones are quite short on RAM.

It's InfoWorld (0)

Anonymous Coward | about a year ago | (#42568299)

Remember these are the guys who cant even understand what their laptop AV software is reporting.

Re:article doesn't make sense. (2)

n30na (1525807) | about a year ago | (#42568429)

The original fix in question was feeding /dev/urandom into /dev/random because the entropy pool was running low and sometimes running out, which is what was causing ui hitching.

Of course, it was actually just an old android bug that'd been fixed ages ago, iirc.

Re:article doesn't make sense. (0)

V!NCENT (1105021) | about a year ago | (#42569167)

man random gives: reading too much chunks of entropy will cause slow down for other users. Every app in Crapdroid is 'sandboxed' by creating a new user session per app.

The evidence for why Android sucks, can be read in the internal emails, used in the Oracle Vs. Google "ahmygod they stole our APIs!" court case.

We need more Linuses (0)

Anonymous Coward | about a year ago | (#42568023)

At least as a project leader, Linus tells people off when they go all hair-on-fire about some wingnut idea.

the placebo effect (1)

slew (2918) | about a year ago | (#42568051)

Apparently, the placebo effect also works to cure percieved computer ailments...

Re:the placebo effect (1)

nomel (244635) | about a year ago | (#42568411)

I don't get it. There were no numbers posted in the thread. This doesn't mean placebo, this just means there are no numbers posted. The claim that it's placebo has just as much foundation that it's not. Write a benchmark and test it, you could get exactly 2 minutes of fame.

Beware of more of this stuff on XDA (4, Insightful)

Freggy (825249) | about a year ago | (#42568117)

The problem is that xda is full of this kind of crap. Kernels which disable fsync (libEAT-MY-DATA, anyone?), exotic I/O schedulers and CPU governors, overclocking processors and other hacks... Very often, they do not have any measurable effect, or even cause new problems, such as freezes, hangs, sleep of death,...

Re:Beware of more of this stuff on XDA (4, Informative)

AdamWill (604569) | about a year ago | (#42568285)

yep, the place is cargo cult central. stick with builds of the major ROMs from affiliated devs, is my advice. Run like hell from the threads which are kangs of those builds with some kid's AWESOME BLACK THEME and a bunch of kernel patches he picked up somewhere.

Re:Beware of more of this stuff on XDA (3, Insightful)

Anonymous Coward | about a year ago | (#42568457)

The funny thing is those dweebs spill out onto the general internet and tell everyone they need to hack their phones.

Then you read a 45 page thread only to find that their wicked sweet ROMz don't support the camera and give the phone 30 minutes battery life. Gee thanks, Melvin.

when did you stop beating your wife? (0, Troll)

terec (2797475) | about a year ago | (#42568119)

Slow phones are slow, fast ones are fast, and occasionally things stick on Android, but no more than on comparably priced hardware using "the other" platform. You know, the platform whose fanbois try to smear Android by placing stories about supposed fixes for supposed problems on Android.

Re:when did you stop beating your wife? (1)

Anonymous Coward | about a year ago | (#42568593)

hurr durr, yes this is all an Apple 'fanboi' conspiracy.

Re:when did you stop beating your wife? (0)

Anonymous Coward | about a year ago | (#42568905)

yes, it is

Just finished reading the whole thread (3, Interesting)

godrik (1287354) | about a year ago | (#42568339)

There are a lot of comments on the bug report page. Clearly this is not a dalvik bug since dalvik does not use the /dev/random. But the other commentatros are still unsure that there might not be some issue in how randomness is generated in android from user input, which might induce lag.
Right now, some folks still investigate.

Re:Just finished reading the whole thread (1)

Anonymous Coward | about a year ago | (#42568369)

Yep, it seems the jury is still out on whether this is a real bug or placebo. Too early to call it. The trolls on each side are in full effect though, and nobody seems willing to do any real empirical testing.

The solution is simple (-1)

Anonymous Coward | about a year ago | (#42568477)

To fix the lag in Android just remove Java.

Seriously, all Java software is laggy and awful.

So remove something that is not there (0)

Anonymous Coward | about a year ago | (#42569099)

Typical uneducated dumbdroid. Don't even know what he/she is using.

Jury is still out (2)

CNeb96 (60366) | about a year ago | (#42568499)

>> "didn't actually speed Android up."

If you actually read the bug mentioned in the summary - most devs are arguing that explanations about why the fixes work don't make sense in terms of Dalvik (java) that the android bug was filed against - not that it doesn't improve latency or that it doesn't work or there isn't a lower level issue. One developer https://code.google.com/p/android/issues/detail?id=42265#c162 [google.com] (sorry I don't know enough about android to know if he is part of the core team or not) - is doing testing to measure results of a patch from the mainline linux kernel https://patchwork.kernel.org/patch/1745611/ [kernel.org] plus some re-arranging of the android code to see if he has found a lower level solution.

Looks like a real bug to me (1)

loufoque (1400831) | about a year ago | (#42568581)

This looks like a real bug to me.
The problem is that many apps use /dev/random instead of /dev/urandom, which of course causes them to be unnecessarily slow.

A "hack" was to make /dev/random behave like /dev/urandom, but it's not clean, which is why it's not done in the official version.

The jury seems still out on this (3, Interesting)

DeathToBill (601486) | about a year ago | (#42568611)

Having slogged through the linked discussion, there is no conclusion either way whether this effect is real or not. There are several theories on mechanisms that could cause an increase in responsiveness, but no conclusion. The most plausible seems to be that when the entropy pool is near empty, each input event causes a context switch as it is used to refill the entropy pool. Slower input handling obviously leads to poor responsiveness.

The summary seems to just be random android-bashing.

Java anyone? (-1)

Anonymous Coward | about a year ago | (#42568681)

Android's problem has four letters: Java.

Its like a train wreck... (2)

Luthair (847766) | about a year ago | (#42568711)

Reading that bug report makes me incredibly glad that I've only worked on open source developer tools, if the comments on that bug report are typical I imagine Google must have high turn-over of developers on the project.

Confirmation bias! (0)

Anonymous Coward | about a year ago | (#42568787)

I think confirmation bias can easily kick in in a situation where the problem is intermittent or hard to discern.

If the platform only sometimes lags, it is easy to take the non-lagging episodes when the system is functioning well as confirmation of the nonexistent fix, and write off the lagging episodes as remaining issues that are not yet addressed.

If the system had had consistently bad response to every event, then a non-fix would not be accepted so easily.

Re:Confirmation bias! (1)

Flipao (903929) | about a year ago | (#42569643)

The lag was always obvious all the way up until ICS, where they introduced proper hardware acceleration for the UI (i.e. actually using triangles to render UI elements), however it was still not quite as good as it was on other platforms, they addressed this on Jelly Bean and the difference is pretty obvious to anyone who's used the same device on both versions.

http://www.youtube.com/watch?v=V5E5revikUU [youtube.com]

Did you even read the thread you linked to? (5, Informative)

buser (2545806) | about a year ago | (#42569021)

Apparently the OP didn't read the thread he alleges disproves the performance increase. There is actually a very lively discussion going on about it, and while there's a general agreement that it's not as simple as the /dev/random pool getting depleted, there is some evidence that it is related to locking in the UI (see comment 162).

Re:Did you even read the thread you linked to? (1, Flamebait)

Flipao (903929) | about a year ago | (#42569575)

The OP is simply yet another MS shill trying to spread the usual FUD.

Speaking from personal experience I own an Ipad 2 and a Nexus 4, the UI in the iPad 2 is smooth as silk as usual, the UI in the Nexus 4 is even better in terms of speed and responsiveness. Switching between applications is seamless and the UI will not drop a single frame.

The user experience in Android was lacking until Matias Duarte took over the UI, in modern phones it's as good if not better than anything on the market, period.

There are four things that make Android laggy (5, Interesting)

Miamicanes (730264) | about a year ago | (#42569493)

There are basically four things that make Android laggy. The good news is that most of them can be overcome by user-modified firmware. The bad news is that manufacturers and Google are unlikely to ever fix them directly, because it would increase the manufacturing cost of phones by a few cents.


Android's normal behaviour is to aggressively kill activities and suspended background tasks, then respawn them from scratch when brought back into the foreground or reactivated. The LINUX (and Windows) norm is to simply quit giving them CPU cycles, stash their state into swap space on the hard drive, and resurrect them later.

One reason why this is done is because Android devices, while not necessarily STARVING for flash, don't have it in quite the abundance that a normal computer has hard drive space. There are also concerns about prematurely wearing out flash. The problem is that flash rewrite life estimates are based upon general use of the entire block of memory... but a swap partition gets created in a specific chunk of flash, and that one tiny chunk gets relentlessly hammered. If your erase-rewrite activity gets spread across the whole flash, it would usually take months of active efforts to be destructive before you really caused damage. However, if you create a 256mb swap partition and hammer it relentlessly, you can permanently damage it in a weekend. For this reason, few at XDA will advocate ever using internal flash for swap.

That brings up catch #2... if you swap to microSD (because it's cheaply replaceable should you end up damaging it), you really need class 6 or better. Swapping to class 2 flash will leave you running more slowly than if you left Android to its default behavior. Guess what class of flash invariably comes with the free microSD card shipped with the phone? Class 2.

Making matters worse, the users in the best position to experiment with swap enhancements are Nexus owners. Unfortunately, Google has this near-religious aversion to microSD, and I don't think any Nexus device since the original Nexus One has shipped with a microSD slot. All that said, if you have a rooted and reflashed Android phone with class 6-10 microSD that has a swap partition and a custom ROM that uses it, you MIGHT see a big reduction in lag if you frequently run apps that have "expensive" startup costs (ie, apps that always begin by trying to make a http request to somewhere, or generate cryptographically-secure random numbers, etc).


Historically, Android hasn't done a good job of putting 2D acceleration to good use ICS was a step forward, but you can't help but feel like the GPU support is more symbolic, half-assed, and buried under 400 abstraction layers that fritter away most of its potential. At least, for simple and straightforward "scroll and/or pan the viewport across a large virtual bitmap" type operations.

Compounding the problem is Android's architectural bias towards generating content on the fly, instead of generating humongous virtual bitmaps and keeping them available for instant viewport rendering.


Building upon 2, and being completely blunt... Dalvik's memory-management totally fucking sucks compared to Java's. ESPECIALLY the way it handles short-lived objects that get repeatedly created in large numbers, and discarded almost immediately.

I dare anyone to disagree. Half the Android API bends over backwards to tiptoe around Android's shitty heap-management by trying to avoid creating and discarding objects for use as short-lived containers.

No, don't give me crap about mobile devices having limited resources compared to desktop computers. That's bullshit, and everyone knows it. Java mostly solved the worst of its memory-management problems around 1.5. Compare the specs of a high-end laptop circa ~2002 with the specs of a Galaxy S3, and arguments about Android devices being "severely resource limited" just kind of fall on the ground and thrash around like a dying fish. They might have been relevant in 2008, when Android had to run on phones with the hardware specs of a G1 or Hero. This is 2013, RAM and flash are cheap, and the lack of microSD cards for safe throw-away flash on Nexus devices is 100% Google's fault and can be remedied by putting them on new Nexi going forward.

Anyway, the fact that Android's API is so neurotic about the creation of transient and large objects is part of the reason why apps get laggy when doing things like scroll. On a PC, a Java app would usually just create and populate the whole list at once, unless you're talking about a list that's so staggeringly multi-gigabyte huge, it's literally impossible. On Android, you're practically forced to build the list piece by piece, over and over again, tearing it down and rebuilding one tiny segment from scratch every time. Apps that insist on doing this via realtime Ajax calls (goddamn, I hate Ajax... it used to only be web apps that sucked and were laggy; now, its endless request-response latency has infected real apps, too) just compound the problem.


Android's default CPU governors suck. Just about everyone I know prefers the performance-oriented governors, like "interactive" or "smartass". Manufacturers, looking to maximize their battery benchmarks while shipping phones with anemic, undersized batteries just so they can be as thin as the latest iPhone, overwhelmingly prefer governors like "ondemand".

Most of the time, they don't even bother to compile 'interactive' into the kernel as a silent, unsupported option. What's the difference? Interactive gives a high priority to UI interaction and "race to completion" strategies. When you turn on the display or launch an app, it instantly kicks up the speed to 100%, and backs down slowly... and ONLY when almost nothing whatsoever is happening. In contrast, 'ondemand' tries to keep the phone running at 50% speed or less most of the time.

Governors like 'Ondemand' combine with Android's preference for killing and restarting activities to multiply the problem, because most of your app relaunches end up happening while the phone is throttled. You don't get to taste real speed until well into the launch process... and Ondemand will take THAT away from you as soon as it can.

The irony with 'ondemand' is that using a demanding live wallpaper can actually BOOST your performance, because it acts like a pilot light to keep the fire stoked. In metaphorical terms, think of the governor as being like a vertical slider that determines the current CPU speed. 'Interactive' is kind of like having a balloon attached to pull it up... it will slowly creep down on its own, but just blowing on it is enough to get it back up to 100%. 'Ondemand' is like having a lead weight attached to pull it down... you can drag it up, but the moment you let go it's going to sink, and you have to keep actively fighting and work hard to keep it from sinking.

The moral: live at XDA, buy phones that can be unlocked and reflashed, make sure it has a microSD slot that you've filled with a big class 10 card, forcibly enable swap and use a tweaked kernel that disable's Android's default "kill-instead-of-suspend" behavior, and use a governor like 'interactive' that only slows down the phone when it's truly idle, instead of a governor like 'ondemand' that makes you earn smooth performance by keeping your phone busy enough to prevent it from slowing down the CPU to 200Mhz.

When your latest gen platforms... (-1, Troll)

AmazingRuss (555076) | about a year ago | (#42569661)

...can't provide interactivity as smooth as the original iPhone, you have a problem.

Denial isn't going to fix this, but I expect many denial responses.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account