Slashdot Mirror
32GB iPhone 7 Has 8 Times Slower Storage Performance Than 128GB Model (thenextweb.com)
An anonymous reader quotes a report from The Next Web: Apple isn't telling you everything about its phones. Few weeks back, GSMArena reported that the 32GB iPhone 7 and 7 Plus had significantly slower storage performance than the 128GB and 256GB models of the device. In a new video, Unbox Therapy's Lew Hilsenteger conducted a series of speed tests that confirm the discrepancy in storage speeds between the different configurations of Apple's phone -- and it turns out the 32GB iPhone is about eight times slower than the larger capacity storage version of the device. For his first test, Hilsenteger used the free PerformanceTest Mobile app to compare the read and write speeds of the iPhone. While there was little difference between the read speeds of the 32GB and 128GB models, there's a huge disparity when it comes to write speed. The 32GB iPhone writes at 42MB per second, which is nearly eight times slower than the 128GB version's 341MB per second. Hilsenteger then performed a real-world speed test, which included transferring movies from a MacBook to the iPhone using a USB cable. While the 256GB model took two minutes and 34 seconds to complete the 4.2GB file transfer, the 32GB iPhone 7 needed a total of three minutes and 40 seconds for the same transmission.
Unless Apple is doing some sort of quasi RAID like read/write access against all available memory chips (vs treating them like a sequential memory space which may end earlier rather than later depending on what memory capacity you selected at purchase time)... why should a higher capacity device have faster read/write times than a lower capacity of the same generation?
If anything, this sounds like another example of Apple attempting to balkinize the market in a way favorable to them and those who are most willing and/or able to pay them the most for devices.
Help Brendan pay off his student loans
It does suck if your phone doesn't get the performance that could be achieved (and is achieved by other phones) but I'm not sure what this would mean in real life.
Do you need this performance on a mobile device such as a phone? As the data transfer test proved, it's not eight times slower for that, it only takes somewhat longer.
I thought it was normal the fewer flash chips perform worse.
I'm far from being a storage hardware expert but if mass manufacturing means that it's cheaper to use different number of the same flash chips instead of using the same number of different flash chips, it seems logical that the resulting system would have a bandwidth scaling with the number of chips.
Ezekiel 23:20
Two minutes and 34 seconds is hardly eight times faster than three minutes and 40 seconds for the same transmission.
All modern NAND flash memory does "quasi-RAID". Writes are split across all chips in parallel, so the larger the capacity, the more chips, the faster the write speed. Check out any USB thumb drive with various capacities - larger models of the same line will be faster.
That said, 128GB should only be 4 times faster than 32GB, so if these figures are correct then the 32GB units are also using lower spec memory.
foo mane padme hum
On my shelf not three feet away I've got an early prototype of a a logic board for a system later shipped with 2, 4 or 8 flash memory chips back in 2003... a board I owned a good bit of code for. At no point was there any talk of us accessing multiple chips at a time, instead the existing sequential read/write capacity was enough for our needs.
The same goes for any embedded device today, regardless of potential # of memory chips... the manufacturer is only going to parallelize read/write access under two circumstances:
1) no one on the test team noticed them doing so,
2) there is actually a need to do so in order to boost performance... which may not be applicable across all units.
#2 breaks down as it's like putting a hardware raid controller in every PC/server mobo with multiple sata ports. Sure some % of users may end up with multiple HDs attached... why should the manufacturer pay the added cost of baking this extra speed in when it is clearly an add on (or premium upgrade) option?
Help Brendan pay off his student loans
So you are suggesting that the higher level HW or SW is doing some sort of RAID like operation to hit all chips equally? If so, that should scale linearly with the # of chips/amount of storage... yet it doesn't seem to.
Help Brendan pay off his student loans
On the other hand, I've noticed in the past that versions of SSDs for desktop computers did exhibit the pattern I mentioned: up to a certain point, the larger versions were actually faster. Also, maybe with stacked chips in mobile devices, the extra cost is not prohibitive for some reason.
Ezekiel 23:20
A single NAND die isn't capable of 341MB per second. They're clearly using parallel writes.
Bingo. One NAND die is not all that fast; it's when you put multiple dies together - either via multiple packages or, in the case of the iPhone, layering - that you get the absurdly high transfer rates solid state NAND storage is known for.
AnandTech's SSD Anthology even 7 years later is still the single best primer on the subject of flash storage: http://www.anandtech.com/show/2738/6. It goes over how this concept works in greater detail.
The one thing you won't find in there though, but is similarly important for understanding smartphone storage, is SLC caching. Most phones these days are using Triple Level (TLC) storage, which means storing 3 bits in a single cell. This greatly brings down the cost per byte of NAND, however it makes it slower to program and erase. As a result the iPhone (and most other phones) have an area of NAND that is pseudo-single level (SLC), which only stores 1 bit per cell. The purpose of the pseudo-SLC area is to serve as a cache; quickly absorb and coalesce writes, and then write them out to the slower TLC NAND transparently to the user.
The size of the pseudo-TLC area is generally proportional to the size of the total NAND. That means the larger iPhones have a larger pseudo-SLC area. And if you understand caching, then you understand what happens when you exceed that cache size. Most likely some of the tests in TFA were big enough to overflow the pseudo-SLC on the 32GB phone, but not on the larger model. Which is why there's such a large performance difference on some tests, but not in other things like transferring files.
Well, the 32er model has also 4 times less memory than the 128er model, so it's in no haste to save stuff, it will fill up quickly enough anyway.
Chances are the smaller storage means they are using older storage. If you want to make the low end model more affordable going with an older slower component is a way to actually lower the cost.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
When writers use words like that, do they understand what they mean in mathematical terms? I have my doubts.
(this is not a
As long as the phone is not remarkably slow, does it matter if the storage is slower than the upper model? People buy the iPhone for iOS and its ergonomics.
Slashdot, fix the reply notifications... You won't get away with it...
Unless Apple is doing some sort of quasi RAID like read/write access against all available memory chips
"Quasi RAID" is actually how all SSDs work. The controller spreads the writes across multiple flash chips. This is why NVMe is so much faster, the OS can give the SSD controller thousands of outstanding IO requests instead of the max of 32 with SATA. The iPhone uses a single eMMC flash chip which integrates the controller and the NAND on one die. The eMMC chip will do the same thing, only across flash cells instead of entire chips.
In the end, all this comes down to is the fancy 128/256GB eMMC flash comes with a nicer onboard controller than the 32GB one, hence higher bandwidth. That said, with such a huge difference there is no doubt Apple ordered the cheapest 32GB flash they could find. You probably can find the same eMMC chips in a $50 cheap Chinese Android phone. For a $500+ phone they should be paying the extra $2 for higher bandwidth 32GB eMMC chips.
I wonder how the flash is organized. Is it just a question of a single flash chip of varying size, or is it possible that the 128GB model is somehow comprised of 4x 32GB segments which allow write interleaving to happen?
The only other explanation that I can think of would be that 128GB represents a level of density that requires superior flash chips which really are faster, and that 32GB uses older parts that are just plain slower.
That depends 100% on the sort of controllers & memory layouts that are involved.
Do you have specific information that Apple does this? I don't.
Given that:
- nearly all modern smartphone/tablets/etc. do no go the extra headache to implement some weird custom solution for their mass storage.
- instead they all go for simple, standard, cheap of the shelf technology.
- [ BTW: eMMC (embed MMC - i.e.: an SD Card, without the plastic package, but directly available over an MMC bus) seems to be the most frequent solution ]
- Most of the flash anywhere, including thousands of SD Cards on the market right now, follow the exact same tendency: bigger model have more chips and can spread their write/erases among more chips ("quasi-RAID") giving better performance. That's why the "Class 10 UHS III" SDXC cards are only available on the bigger models, smaller models are slower. Same difference between microSDXC and regular SDXC cards (bigger cards can pack more chips and you have a greater choice of faster cards. At the micro level, it's only 128GB and above capacity that usually come with "Class 10 UHS III").
- Even more gory details if you care to read the benchmarked read/write speeds of each card. (again, more chips - found in larger package or bigger capacity - manage higher write/erase speeds).
Given all the above, there's high expectation that iPhones are following the trend.. :
But hey instead of speculating and calling each other names, let's check actual real heardware
iFixit, Chipworks, SK Hynix Datasheet
What a surprise~ iPhone are exactly everyone else~ and source cheap of the shelf parts instead of re-inventing the wheel~~ Who would have though this~~~
iFixit's 32Gb iPhone use H23QEG8VG2ACS - a stack of 4 chips, with 256Gibits total (or 32GiB if used alone like in this phone).
Chipworks's 128GB iPhone use - a stack of 8 chips, with 1024Gibits total (or 128GiB when used in alone configuration)
So without even taking into account anything else, 32GB iPhone can only spread their writes among half of the chips available to a 128GB iPhone.
So they already start with a 50% malus at the hardware level.
That said, 128GB should only be 4 times faster than 32GB, so if these figures are correct then the 32GB units are also using lower spec memory.
Nope. At all. Like you said it entirely depends on the flash configuration. 128 isn't necessarily 4x more chips than 32.
Some constructor would go for 8x more chips of half the capacity.
In Apple case, they went for 2x more chips at 2x more capacity (more expensive but faster, enabling them to have bigger marging on the smaller/slower 32GB).
Which again goes back to the point of what I have posted... and this article.
Which goes back to the answer which you were given:
- YES, nearly every last constructor of flash is doing "quasi-RAID", i.e.: stacking/bonding more chips in the same package and spreading the write/erase among that.
That single fact can account for a huge part of the difference between models.
Then the thing is designed by Apple.
They run iOS on it. i.e.: the same "Darwin" core ( Mach microkernel + BSD monolithic kernel + BSD user space) as Mac OS X, only with a different interface.
They probably *still* use the same asinine file system as always HFS+
And that one is completely inadequate for flash.
It's a classical "inplace" writing file system.
This dramatically increase the "write amplification" typical with random-writes flash media. (each time you need to change some data, you would need to erase and re-write a whole block).
This probably *also* accounts for the dramatic performance
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The write speed doesn't matter. The read speed is fast. Usually you transfer data from a phone to your laptop PC. If you want to do it the other way around, then you are holding your laptop wrong.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Is it not possible that system architectures, and the approach to memory handling, have changed in the last 13 years?
You will see this with a lot of SSDs as well larger capacity models have better write performance because many are capable of paralleling writes. It takes some small bit of time to program a flash block, there is not need to keep data contiguous on a medium with no seek time, therefore you can spray data all over the flash medium and that is fine because you are logically mapping all the blocks anyway.
Its not surprising to me that even the embedded NAND or NOR flash in smart phone would act like a raid0 over X number of chips. I am not saying that is what is going on but its reasonable explanation based on what I know about other memory devices.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Are there situations where a user would notice a slower flash write speed on their cell phone?
The only time I can think of where a phone would need to write massive amounts to flash is during an OS upgrade (which is hopefully a rare thing) -- even during an app install, the user is likely to be bounded by their network's download speed, not by the speed of writing to flash. Similarly, while recording live video, the phone only needs to write at the bandwidth of the video stream, no faster.
Is there some use case I'm missing?
I don't care if it's 90,000 hectares. That lake was not my doing.
Parallelizing writes is done for wear leveling at chip level. Then the algorithms also take care of the ware leveling inside the chip. It really makes sense with the crappy 10nm TLC/MLC technology we have today that shits out after 150-200 writes. Any manufacturer who isn't doing it, is an idiot and their product should not be bought.