Slashdot Mirror

← Back to Stories (view on slashdot.org)

Flash Memory, Not Networks, Hamper Smartphones Most

Posted by Soulskill on from the at-least-flash-doesn't-do-it-intentionally dept.

Lucas123 writes "New research shows that far more than wireless network or CPUs, the NAND flash memory in cell phones, and in particular smartphones, affects the device's performance when it comes to loading apps, surfing the web and loading and reading documents. In tests with top-selling 16GB smartphones, NAND flash memory slowed mobile app performance from two to three times with one exception, Kingston's embedded memory card; that card slowed app performance 20X. At the bottom of the bottleneck is the fact that while network and CPUs speeds have kept pace with mobile app development, flash throughput hasn't. The researchers from Georgia Tech and NEC Corp. are working on methods to improve flash performance (PDF), including using a PRAM buffer to stage writes or be used as the final location for the SQLite databases."

27 of 121 comments (clear)

  1. Or, you know, maybe by Anonymous Coward · · Score: 2, Insightful

    writing smaller applications? Maybe, you know, stick to one thing and master it instead of spewing forth so many OSes, languages and nonsense that there's no hope of reigning in the software chaos? But don't worry, the hardware folks will pull a rabbit out of their hats (again), so that software geeks never, ever have to learn or change.

    1. Re:Or, you know, maybe by icebike · · Score: 5, Informative

      writing smaller applications? Maybe, you know, stick to one thing and master it instead of spewing forth so many .

      An interesting comment, but not the focus of the linked article.

      Its not about the size of applications. Large reads into memory of big applications is not the problem, as this happens with sequential reads, which are very fast on the media type they were looking at.

      Its the small RANDOM read/write units that cause the problem, the small sqlite database updates to databases stored on the MicroSD card that are the problem.
      The recommendations for placing often used sqlite databases in RAMdisk yielded a tremendous performance increase because it eliminates tons of little random read and write operations that tend to be scattered all over the microSD card. This is buried in page 10 of the Actual Research document, but pretty much glossed over in the linked article. This would require a bit of an OS re-engineering, on the part of smartphone OS designers, such as offering APIs to do much of the routine data storage that these apps all end up using. That storage would be in ram, backed up to MicroSD in a more efficient manor.

      Programmers tend to heavily use the general-purpose
      “all-synchronous” SQLite interface for its ease of use but
      end up suffering from performance shortcomings. We
      posit that a data-oriented I/O interface would be one that
      enables the programmer to specify the I/O requirements
      n terms of its reliability, consistency, and the property of
      he data, i.e., temporary, permanent, or cache data, with-
      out worrying about how its stored underneath.

      Yes, ramdisk can go away on a un-planned phone reboot, but if the RAMdisk was used as a cache, and occasionally written to disk performance would be much better, because you find these little sqlite databases used all over Android and IOS.

      --
      Sig Battery depleted. Reverting to safe mode.
    2. Re:Or, you know, maybe by __aaltlg1547 · · Score: 4, Interesting

      A couple points:

      1. Smart phone makers have no control of what crap software you're going to stick on their phone -- only the crap software that comes preinstalled.

      2. The former is the point of why consumers buy smart phones in the first place.

      3. The smart phone makers have a big incentive to find a way to make the hardware faster because running your apps faster is a selling point.

    3. Re:Or, you know, maybe by arth1 · · Score: 4, Informative

      Its the small RANDOM read/write units that cause the problem, the small sqlite database updates to databases stored on the MicroSD card that are the problem.
      The recommendations for placing often used sqlite databases in RAMdisk yielded a tremendous performance increase because it eliminates tons of little random read and write operations that tend to be scattered all over the microSD card.

      How about the recommendation to not use sqlite whenever a flat file works better? Do one write instead of database operations which cause multiple blocks to change even if you only change one thing.

      And if you have to use SQL for whatever reason, don't use indices unless absolutely necessary. It seldom is, despite what school has taught you. The index has to get updated too, which causes additional non-sequential writes. The minor speed boost you may get from selects are easily eaten up by the major speed bumps you cause on inserts and updates.

      An embedded system, which this should be treated as, isn't a miniature version of your desktop computer. And an SD card isn't a miniature version of a hard drive, or even an SDD. You have to think about minimizing writes and especially random writes. Not just minimize the number of high-level-abstracted changes, but actual low-level writes caused by them. Because there isn't a 1:1 correspondence.

      Also, memory is at a premium. Dropping pages really hurts speed. Don't rely on garbage collection as a substitute for using less memory or freeing up memory manually.
      Don't hang on to resources in case you may need them. Be cooperative, and close the sockets and file handles when you don't use them, because other parts of the system may benefit from that memory. CPU is rarely the issue, so don't worry about CPU outside identified bottlenecks. Worry about being a resource hog, because that causes the entire system to slow down, and drag your app with it.

    4. Re:Or, you know, maybe by Tablizer · · Score: 2

      In the future, the distinction between desktop and portable will likely get blurrier, and development techniques and related economics will become similar.

      --
      Table-ized A.I.
    5. Re:Or, you know, maybe by beelsebob · · Score: 3, Informative

      Except that apple are still doing this just fine at 1024x768, and are likely in a few months to be doing it just fine at 2048x1536... The reason the iPhone can do this and android can't is nothing to do with the resolution – it's that iOS has always used the graphics hardware to render the UI.

    6. Re:Or, you know, maybe by msobkow · · Score: 2

      And if you have to use SQL for whatever reason, don't use indices unless absolutely necessary. It seldom is, despite what school has taught you. The index has to get updated too, which causes additional non-sequential writes. The minor speed boost you may get from selects are easily eaten up by the major speed bumps you cause on inserts and updates.

      100% true!

      The issue is so common that a virtual index that is not maintained by the database is often referred to as a "business index". With small datasets, application performance is often increased overall by relying on full-table scans for non-indexed data rather than applying an index.

      Another situation where this often crops up is keys that have a low variance. For example, a hundred thousand record table where one of the index columns only has a dozen values. There are no hard numbers, but as a rule of thumb, if there are 10% the number of keys that there are records for an expected table size, I test a business index approach to see how the performance works out.

      But most programmers aren't professionals who test performance before releasing code. As long as "it works", they ship it. Performance tuning will only get done if enough paying customers are complaining that the revenue stream is threatened.

      --
      I do not fail; I succeed at finding out what does not work.
  2. A truly stupid comparison by MrEricSir · · Score: 2, Insightful

    Users don't have the option of trading network performance for faster local storage. The two are so unrelated it's not clear as to why we're comparing them (I'd use the term "apples and oranges" but I'm sure that would piss off some anti-Apple trolls.)

    And sure, SSDs could be faster, believe me nobody would complain if they were. But after using spinning magnetic storage for decades, SSDs seem blisteringly fast to me.

    --
    There's no -1 for "I don't get it."
    1. Re:A truly stupid comparison by Microlith · · Score: 5, Interesting

      SSDs and the eMMC NAND storage inside smartphones are wildly different, even if they are fundamentally the same concept.

      SSDs get all of their speed from massive parallelization, writing to and reading from multiple die at once. Often these die tend to consume a bit more power, allowing for faster overall access. In smartphones, you usually have eMMC as the primary NAND device. These are basically high capacity, soldered down SD cards packed with several high density MLC NAND. You have drastically fewer IO channels, no DMA capability (it's all PIO via the CPU,) and slower NAND due to reduced power requirements.

      This is why watching your memory consumption is essential on mobile devices, and why optimization for each device has to be done. The moment the CPU has to access the NAND, you're going to take a performance hit no matter how many cores you have.

    2. Re:A truly stupid comparison by Microlith · · Score: 3, Informative

      The long term goal would be to minimize the latency and increase the speed of the writes. Doing so lets you return to a low power state as fast as possible, on top of improving performance.

    3. Re:A truly stupid comparison by Nemyst · · Score: 4, Funny

      The good term is "Apples and Androids", obviously.

    4. Re:A truly stupid comparison by dmitrygr · · Score: 3, Informative

      Not even close to correct. All current, last generation, and the generation before that SoCs for phones/Tablets/PDAs support DMA to SDMMC module. Tegra 1/2/3? yes Omap 1/2/3/4/5? Yes QC? Yes Marvell 3x, PXA2xx? Yes

      --
      -------
      1. Enjoy your job
      2. Make lots of money
      3. Work within the law

      Choose any two.
    5. Re:A truly stupid comparison by Anonymous Coward · · Score: 2, Informative

      They are being compared in this manner because in the US, a network provider made an advert where they "race" two smart phones to prove that their network is faster. That is, they have two phones and click "install" on the market at the same time on both of them, and then we see that one of them installs in 2 seconds flat while the other one takes like 30 seconds to install the the app. The advert is obviously bullshit because even on a wifi connection and broadband, apps never install that fast. This article explains the reason why: the flash memory can't write the data fast enough to keep up with the download speed.

      So although users don't have the option to trade one for the other, they do have the option to not be fooled into buying something they don't need and can't use.

  3. Why not a ramdrive? by Anonymous Coward · · Score: 2

    Why not have the phone offload all the info to a ramdrive and occasionally backup the info to the ssd?
    Phones could be blisteringly fast if they used ram this way.

    1. Re:Why not a ramdrive? by Kenja · · Score: 2

      For much the same reason they dont have RAID-0 in the phone. It's too expensive, and its a PHONE!

      --

      "Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
    2. Re:Why not a ramdrive? by Microlith · · Score: 4, Insightful

      RAM consumes a lot of power, far more than a NAND disk that can be powered down in between accesses.

  4. Cut back a little by Waccoon · · Score: 4, Insightful

    While I sympathize with developers who have ambitious ideas, the bottom line is that you have to develop within the limitations of the hardware. If your software is too slow or otherwise suffers in performance, then your software is simply too slow.

    Cue stories about how RAM chips were too slow to keep up with cutting-edge video controllers in the 90's.

    1. Re:Cut back a little by tuxicle · · Score: 2

      What about stories of how RAM chips today are too slow to keep up with cutting edge CPUs?

    2. Re:Cut back a little by tlhIngan · · Score: 5, Interesting

      RAM speeds have not been a significant issue for some time now. Go and read some of the performance tests done recently on various speed RAM, even jumping from 1333 to something like 2133 DR3 RAM has such an insigificant performance change on the rig that it is clear memory is not the bottleneck nowadays. The Bus, HDD etc are the bottlenecks that hurt more than anything else.

      False.

      RAM speed does have a significant impact. It's just that cache hides a LOT of the impact. If you ever disable the cache on your CPU, your computer would feel like it was 15 years old - it's that slow.

      Now, one thing about RAM - RAM hasn't actually gotten significantly faster - the clock speeds may have gone up, but the latencies have gone up as well. The faster RAM may have true access times (measured in nanoseconds) close to that of the slower one, especially the cheaper RAM.

      But a modern CPU is very cache dependent. Hell, even the little ARM in your smartphone suffers tremendously when cache is off. (I should know - I've had to do actual timing tests of the ARM caches.).

  5. so you want a phone to have 4-32GB RAM disk by Joe_Dragon · · Score: 2

    so you want a phone to have 4-32GB RAM disk + say 256-512MB + system ram

  6. Choose two... by Anonymous Coward · · Score: 4, Insightful

    Reliable, fast, energy efficient. Choose two.

  7. Can't make it slow if you can't get it by Anonymous Coward · · Score: 3, Insightful

    Flash memory may be responsible for slowing things down, but you can't slow it down if you don't have it.

    I would kill for a happy medium between $35 for unlimited data that barely works (Virgin) and $80 and a first born child for 2gb/month for decent coverage (Verizon, AT&T, T-Mobile...). A little legislation wouldn't be a bad thing, though I understand I might think differently if I had campaign donations to worry about.

  8. Could have told you that... by aaronb1138 · · Score: 5, Interesting

    It is nice to see that there is an actual effort to make an empirical test, but I think most techies had this figured out long ago. The simple test is boot time on the devices. A relatively small OS which typically takes 2+ minutes to cold boot, yeah sounds like a storage issue.

    Fixing the issue with some form of data striping would be attractive, but chews battery for each additional chip. Some kind of balloon-able RAM buffer configuration would work nicely, where the buffer RAM was turned off when the device was not in active use or where individual modules could be brought online as needed.

    Frankly, Microsoft pointed at flash as being a speed culprit early on with their requirements for WP7 phones for add-on, non-removable storage expansion micro SD cards. Sure there were a lot of people all gruff and bemoaning the double price premium for Microsoft certified micro SD cards, but it was mostly just a lack of understanding of the needs for device performance. If I recall correctly, Microsoft had somewhere around 10-12 MiB/S read and write and I/O per S requirements which put most cheap commodity flash modules out of the running. I would also guess that WP7 stripes data between the on board and add-on SD card or otherwise uses some kind of secondary caching algorithm since the micro SD cards get married to the device.

    In the Android world, plenty of RAM cache hacks have been implemented, most notably some in Cyanogen and similar. Consider the technical implications of this post at XDA forums regarding I/O schedulers: http://forum.xda-developers.com/showpost.php?p=22134559&postcount=4

    As an anecdote, the most frequent crashy app on my Android device is the Gallery. It tends to have all kinds of issues with the scheduler as it is reading images and creating thumbnails, likely due to flash access speeds.

    1. Re:Could have told you that... by Anonymous Coward · · Score: 2, Informative

      Your app does not crash because of flash. Your app crashes due to shit coding.

    2. Re:Could have told you that... by the_B0fh · · Score: 2

      A correctly written app should not crash, if the hardware and OS is working correctly (even if slowly).

  9. Gee storage is a bottleneck by Osgeld · · Score: 4, Insightful

    Isn't this true with any computer system since the dawn of computers?

    from plugging in jumper wires to transfer a program from paper to memory, to tape streamers, to magnetic disks, to flash the slowest thing for a computer is its mass storage, always has been, and will continue to be for a very long time

  10. Re:I would like faster flash memory by arth1 · · Score: 2

    Reading 12 gigs of photos over high-speed USB 2.0 isn't that bad when you do it from a reasonably fast card and dedicated card reader. You can typically get 360 Mbps (of the 480 Mbps advertised), which equals 45 MB/s, or about 5 minutes, if your HD can keep up with writing that fast.

    If you use your phone as a card reader, don't expect anywhere near that speed. The phones aren't optimized for that, unlike a card reader.