The Curious Case of SSD Performance In OS X

mr_sifter writes "As we've seen from previous coverage, TRIM support is vital to help SSDs maintain performance over extended periods of time — while Microsoft and the SSD manufacturers have publicized its inclusion in Windows 7, Apple has been silent on whether OS X will support it. bit-tech decided to see how SSD performance in OS X is affected by extended use — and the results, at least with the Macbook Air, are startling. The drive doesn't seem to suffer very much at all, even after huge amounts of data have been written to it."

Comments

Wow, a pro Mac story

[Anonymous Coward]

That is startling!

Re:Wow, a pro Mac story

[bonch]

How dare anyone not use Windows or Linux. They will not get away with this.

Re:Wow, a pro Mac story

[Trogre]

Yes, as opposed to a Mac Pro story which would be, well, less so.

Re:Wow, a pro Mac story

[makomk]

An inaccurate pro-Mac story too, by the looks of it. For the Mac test, they didn't properly erase the SSD to its initial state - instead they used a tool that filled the disk with zeros, marking the entire drive as in-use. It's no surprise that they failed to see any performance degradation as the drive filled up: the performance was already maximally degraded from the start!

Re:Wow, a pro Mac story

[pond0123]

That is startling!

:-)

Having read through the original article, all of its comments, the linked article on TRIM and performance degradation and the score-over-3 comments herein, I'm surprised that nobody has pointed to this:

http://www.osxbook.com/software/hfsdebug/fragmentation.html

The description of the mechanisms HFS+ uses to avoid fragmentation are reminiscent of TRIM's operation from the drive's perspective and the garbage collection scheme used in Samsung's ARM controller, assuming bit-tech.net's description of these is accurate. It therefore comes as little surprise to read anecdotes from numerous users with both factory and third party ("fast" / "non-Apple firmware") SSDs where little performance drop is seen in OS X, along with a series of tests showing similar results and importantly, so far, no anecdotes or test results showing the opposite.

The absence of claims of degrading SSDs under OS X is a surprise and suggests that there really is a performance advantage with SSDs and HFS+ where TRIM is not in use. Adopting TRIM support might improve matters further, of course.

The bit-tech.net tests did still have numerous annoying omissions; this doesn't invalidate them but it does leave questions hanging. It would have been worthwhile partitioning most of the factory drive for NTFS and re-testing under Boot Camp. It would have been even more worthwhile getting one of the SSDs which showed the worst non-TRIM "dirty" performance under Windows and testing that under Mac OS X; if this wasn't possible on the Air hardware for some reason, they could've done it on the Macbook Pro they used as an HDD baseline in the first series of tests.

BTW, Singh's OS X Internals is a great book if you want to learn more about the innermost parts of the OS.

Re:Wow, a pro Mac story

[kestasjk]

We would prefer you say "stunning" ("breathtaking" would also have been fine)

Re:Wow, a pro Mac story

[PRMan]

The number one thing I got out of the article is that if you buy a Mac, you can pay through the nose for a 2-year-old below-average SSD that performs the same as a modern HDD.

Re:Wow, a pro Mac story

[Omnifarious]

I like their laptops just fine. It's their Jobs-inside iProducts I can't stand.

OS X has nothing to do with it

[Wesley Felter]

You can't really draw any conclusions from these results. In one particular Mac, Apple ships a particular Samsung SSD that doesn't degrade, probably because its "clean" performance is already terrible (you might think of it as "pre-degraded"). In other Macs Apple ships Toshiba SSDs that may have completely different behavior. If you put a good SSD (e.g. Intel) in your Mac the behavior will be completely different.

Re:OS X has nothing to do with it

[iotaborg]

FWIW, I've been using an Intel X-25M 160 GB SSD on my Mac Pro for over half a year, and my read/write speeds are essentially unchanged from when I got it... this is using xbench to check.

Re:OS X has nothing to do with it

[dfghjk]

"If you put a good SSD (e.g. Intel) in your Mac the behavior will be completely different."

Completely different from what?

I have put an Intel SSD in a Mac, in fact 2 in a RAID 0 configuration, and it doesn't behave like you are insinuating it does.

The performance of the Samsung drives does suck but it isn't because they are "pre-degraded".

Re:OS X has nothing to do with it

[mindstrm]

Care to post your xbench results?

The write performance can and should drop significnatly as soon as you've burned through all the unused blocks - so unless you are really sparse on the disk writes over the last year and haven't hit that point, or the drive was already degraded when you got it (which is still good and damn fast compared to the non-SSD drives) - this sounds suspicious.

Re:OS X has nothing to do with it

[Anonymous Coward]

Maybe the intel drives aren't dog crap and don't require TRIM. Just a guess.

Re:OS X has nothing to do with it

[fermion]

I would say looking for this problem in an operating system that has been running SSD for 30 months is the silly thing. Apple is a system designer. When something happens, we don't get a run around with the OEM blaming MS and MS blaming the OEM. It is pretty clear it is Apples fault. So if there was a problem we would have heard about it.

OTOH, MS Windows is designed to be flexible enough to run whatever hardware is thrown at it. The downside is that a driver has to written for every single piece of hardware, and complex routine procedures sometimes have to implemented at the driver level instead of being nicely encapsulated at some other well known location.

More useful, I would like to see what happens when one places an SDD in a a Macbook pro. I susepct 10.6 can handle it. Even more interesting would be how a Powerbook running 10.5 rates. It should work, and I bet it would be ok.

Re:OS X has nothing to do with it

[billcopc]

TRIM performance is directly tied to an SSD's erase performance. All TRIM does is tell the SSD which blocks are free to erase in its spare time. EVERY write to a NAND cell requires an erase, so if the SSD can perform that step while the system is idle, the next write to that cell can be performed immediately.

TRIM allows SSDs to "cheat" by doing some of the work ahead of time. The dirty performance is the normal, sustainable speed you should expect from your SSD. Any gains from TRIM are the result of pre-erasing cells when you're idling... if your system never idles (e.g. a busy database), TRIM won't help at all.

Re:OS X has nothing to do with it

[Anonymous Coward]

maybe the filesystem is not crap and doesn't require TRIM

Re:OS X has nothing to do with it

[m.dillon]

Strange reasoning. In anycase, the Intel SSDs appear to use a combination of static and dynamic wear leveling and it seems to do a really good job. A really, really good job. I have over a half dozen of the 40G drives and have not noticed any reduction in read or write performance.

There seem to be dozens of different write combining and wear leveling implementations across vendors. Dozens and dozens. Variations between vendors are significant and even variations between revisions from the same vendor can be significant. Drives sold just two years ago are likely to have primitive weal leveling and write combining verses drives sold today. Vendor technology can be years apart.

I guess you can thank MLC flash for the radical improvement in wear leveling and write combining algorithms over the last few years. Vendors can't really cheat when they use MLC flash... the algorithms have to work properly or the device has an early death due to the limited cell durability.

Personally speaking, I am very confident about Intel's technology. OCZ seems to be pretty good too but it is also full of hacks and does not properly support SATA NCQ. I'm sure there are some other good vendor technologies out there but there are also definitely some very bad ones that are years behind Intel. In the SSD space, the quality of the software matters a lot.

-Matt

Re:OS X has nothing to do with it

[spongman]

yeah, they stated that they wiped the drive with zeros using DiskUtility. given that OSX doesn't support TRIM, that would mean that EVERY page is dirty, thus EVERY write requires a read-merge-write cycle, and thus the performance would never degrade since it's already as shitty as it can possibly get. maybe if they'd TRIMmed the whole drive with a decent OS and started from there without zeroing they'd have gotten significantly different results.

Re:OS X has nothing to do with it

[threephaseboy]

Even more interesting would be how a Powerbook running 10.5 rates

None of the Powerbooks have SATA hard drives.

Re:OS X has nothing to do with it

[silverdr]

*Will* be completely different, right? And you *know* it, right? Then may I ask where do you know it from?

Re:OS X has nothing to do with it

[beelsebob]

You're missunderstanding.

The SSD doesn't sit there erasing blocks. It merely marks them as erased. The problem is that a write to a block requires an entire cell to be written. If there's data in that cell, the SSD has to read the data out, assemble a new layout for the cell with the new data in it, and then write that back. TRIM allows the SSD to see that there's no data in the cell, and hence skip the read the data out, and reconstruct the contents of the cell steps.

Re:OS X has nothing to do with it

[Tacvek]

Whoa! It can go either way an erased flash block is all ones or all zeros, depending on convention. Assuming the (less common) all zero convention, an erased black can have bits set one at a time, but any time a bit must be unset, the block must be erased. The fastest write performance occurs when the block is already erased.
The next fastest is when it can be erased, and then just the new data written. The slowest is to read, erase, and the write the whole flash block.

It is entirely permissible and even sensible to the drive to actually erase any block filled with only TRIM'd sectors, although if the flash block has a mix of TRIM'd and non-TRIM'd sectors, it can skip reading the untrimed ones when rewriting.

Re:OS X has nothing to do with it

[dfghjk]

"maybe if they'd TRIMmed the whole drive with a decent OS and started from there without zeroing they'd have gotten significantly different results."

maybe. maybe not. I own a mac with a Samsung drive. It's performance sucks. It sucks no less than any benchmark I've seen published on it though.

Re:OS X has nothing to do with it

[dfghjk]

Perhaps you should have posted that comment in the right place.

I've never seen a problem

[mrsteveman1]

I've got a Vertex 60 in a While unibody macbook and it works fine, boot is 7-9 seconds, apps load almost instantly even if i start 10 at the same time.

I know TRIM doesn't work yet in OS X but the drive seems to take care of itself just fine.

Re:I've never seen a problem

[joe_bruin]

The impact of the TRIM command is vastly overrated. It is effective on "naive" devices that don't allocate a reserve block pool and therefore have to erase before doing every write. On a modern SSD, the disk controller reserves 5-10% of the physical blocks (beyond those that the host can see) as an extended block pool. These blocks are always known to be free (since they're out of the scope of that OS) and are therefore preemptively erased. So, when your OS overwrites a previously written data block, one of these pre-erased blocks is actually written to and the old block is put in the reserve pool for erasing later at the device's leisure.

The one case where this isn't true is if you're constantly writing gigs of data to an empty drive. With TRIM commands, most of your drive may have been pre-erased, whereas without it you may overrun the reserve pool's size and then will be waiting on block erase. For normal desktop users, this is a pathological case. In servers and people who do a lot of heavy video editing it may matter a lot more.

Re:I've never seen a problem

[PopeRatzo]

It is effective on "naive" devices

When you say "naive devices" are you referring to the controller? (sorry I'm not as well informed about storage as I'd like)

Re:I've never seen a problem

[Jeff-]

You're missing something.

Erase blocks and data blocks are not the same size. The block size is the smallest atomic unit the operating system can write to. The erase block size is the smallest atomic unit the SSD can erase. Erase blocks typically contain hundreds of data blocks. They must be relatively larger so they can be electrically isolated. The SSD maintains a map from a linear block address space to a physical block addresses. The SSD may also maintain a map of which blocks within an erase block are valid and fills them as new writes come in.

Without TRIM, once written, the constituent blocks within an erase block are always considered valid. When one block in the erase block is overwritten, the whole thing must be RMW'd to a new place. With TRIM the drive controller can be smarter and only relocate those blocks that still maintain a valid mapping. This can drastically reduce the overhead on a well used drive.

Re:I've never seen a problem

[onefriedrice]

I know TRIM doesn't work yet in OS X but the drive seems to take care of itself just fine.

It probably is taking care of itself. Some OCZ drives, including the Vertex series, can have firmware which forgoes Trim support in favor of some form of garbage collecting.

Re:I've never seen a problem

[Nerdfest]

I know TRIM doesn't work yet in OS X but the drive seems to take care of itself just fine.

That's because like the iPad, OS X is magical.

Re:I've never seen a problem

[blackfrancis75]

You missed out the important detail of how long you've been using it.

Re:I've never seen a problem

[mindstrm]

That.... makes sense.... I think you just made something click for me.
Thanks.

Re:I've never seen a problem

[Anonymous Coward]

TRIM is a hardware thing, the OS needs know nothing about it. "My" Macs (those I care about) run either WD Black Scorpio 320 with free fall sensor if laptops, WD AV-25 if Minis in down in the cabinet server role, or WD Black Scorpios again, but without the sensor for desktop minis and run reliably and cheap, even tough not the fastest spindles out there. On the other hand I've witnessed many SSD miserably fail in Juniper routers and Mikrotik boxes, so right now, and in the next 5 years nothing will persuade me to move to SSD. Well, if someone gives me an SSD for free, I'll accept, but will not trust any personal data to it.

Re:I've never seen a problem

[waynetv]

How would that work? The TRIM command is what tells the drive a particular block is garbage.

Re:I've never seen a problem

[Rockoon]

Without TRIM, once written, the constituent blocks within an erase block are always considered valid.

I think that many folks are confusing logical sectors with physical sectors.

The device is not reading a block, erasing it, making some changes to some of its sectors, and then writing back to the same now-erased block. It is always writing to some different block.

For simplicity-sake lets say that each block contains 4 sectors, A, B, C, and D. When the file system writes to sector A, the SSD reads the entire ABCD block, updates A, and then grabs a virgin block to write ABCD to. The original ABCD block is then free to be erased by the SSD because it knows that it does not contain any mappable logical sectors.

The issue is of course that from the OS/file system perspective, sector's A, B, C, and D may have been deallocated, but the SSD cannot know this without some help. Hence, TRIM.

Re:I've never seen a problem

[Anonymous Coward]

How can you load more than one app at a time if they load instantaneously? ;)

Re:I've never seen a problem

[Tacvek]

Perhaps The best way to do this is to define some terms.

One term I will define is logical Many interfaces label this a block. This is the minimum amount of addressable data. It is what the kernel sees as the block size of the disk drive, and also used in the drive communication protocols. The file systems also often use them as a sector size, but that is completely independent of the size of a logical block in disk signaling, which is what most kernels view the device in terms of. From this point forward I will call them "logical blocks". Logical blocks are usually 4096 bytes in size.

Flash devices are generally bit readable and bit writable, but only erasable in large blocks, called "physical blocks". In practice the controller can only address them in increments larger than single bit, but smaller than the full physical block size.

The drive maps multiple logical blocks to a single physical block. This can be done in a haphazard fashion, but the simplest way is to map the physical blocks to the number of consecutive logical blocks that they can fit. So in the beginning the disk can be written to directly, since all the physical blocks are blank. If a logical block needs to be changed, just read the other logical blocks from the original physical block, and write the whole thing to an empty block. However, eventually, all physical blocks will have been written to. From this point forward, a physical block must be erased prior to being used.

The trim command tells the disk of any logical blocks no longer in use. If all of the logical blocks in a physical block are not in use, then the drive can erase that physical block when idle, and be ready to use it with no speed degradation. If it tracks which individual logical blocks are not in use, it can also avoid reading them in any future 'read-erase-write' cycle.

If the drive keeps a pool of unused physical blocks around, it can normally avoid the overhead of erasing on a new write, merely reading any logical blocks from the old physical block, and writing everything to a new physical block, and mark the old physical block for erasure while idle.

If a significant pool of empty physical blocks are maintained, then maximum write performance remains possible as long as the amount written at one time is less than the amount of empty physical blocks in the pool. Only when writing too much at once does the pool run out, and erasures occur during writing, causing poor performance.

Thus TRIM is only particularly valuable if the drive has an unreasonably small collection of spare physical blocks, or if the workload writing lots of data (sequential or not) at one time.

Low end drives suffer from the former problem, keeping few if any spare physical blocks around, while higher end drives can maintain optimum write performance at all times, except for large sustained writes.

Re:I've never seen a problem

[mrsteveman1]

5 months

Re:I've never seen a problem

[blackfrancis75]

FWIU not long enough for performance degradation to be noticeable - unless you're regularly filling/refilling the drive

Lazy reporting, try different OSes

[Anonymous Coward]

Maybe they should take the drive over to a Windows XP and Windows 7 box and see if it's the drive hardware being resilient or the OS. The G1 intel drives don't drop a ton after use, and they don't support TRIM. It looks like the Intel G1 flash is artificially capped by the controller. It could be similar here.

Re:Lazy reporting, try different OSes

[mikeroySoft]

or just use BootCamp. Ever try to open a MacBook Air?

Re:Lazy reporting, try different OSes

[wvmarle]

TFA stated this is actually a follow-up test on tests done on Windows, where they found TRIM to have a large effect on the drive's performance. This included a drive they suspect to be technically similar to the one in the Mac (same manufacturer, age) - though unfortunately no direct comparison of actual hardware.

Re:Lazy reporting, try different OSes

[Anonymous Coward]

Yes, I did read that. Similar doesn't mean identical. Who knows what firmware tweaks for OS X might be running under the cover, or if Apple managed to squeeze better binning flash chips for its drives? The test isn't really helpful without direct comparison of the drive Apple includes with another OS, preferably along side tests of off the shelf SSD drives being tested in OS X and other operating systems as well.

This is possible.

[anethema]

It depends a lot on how the drive works.

Intel drives actually use the whole drive for scratch space. Until a sector is written to. Then without TRIM it only has its tiny bit of extra scratch space to work with. That's why intel drives degrade so badly without TRIM.

Indilinx Barefoot controllers on the other hand ONLY use their scratch space, they never use the normal writing space of the drive as scratch space.

See here.

http://www.anandtech.com/show/2829/9

While it does show the synthetic tests degrading with lack of trim, even more than the intel drives, the real world use tests show they suffer almost 0% loss in performance.

Depending on which controller the drive is using, TRIM could make almost no difference or a world of difference.

Anand explains it best:

"Only the Indilinx drives lose an appreciable amount of performance in the sequential write test, but they are the only drives to not lose any performance in the more real-world PCMark Vantage HDD suite. Although not displayed here, the overall PCMark Vantage score takes an even smaller hit on Indilinx drives. This could mean that in the real world, Indilinx drives stand to gain the least from TRIM support. This is possibly due to Indilinx using a largely static LBA mapping scheme; the only spare area is then the 6.25% outside of user space regardless of how used the drive is."

Two quotes stick out

[izomiac]

While skimming the article two parts really stood out. First:

Apple's description of the zeroing format method we used fits the description of what we wanted in terms of resetting the SSD to a clean state

Zeroing is not the same operation as TRIM. TRIM marks a block as unused, and if you read it you'll either get random data, or zeros (probably the later). Zeroing marks it as in-use, and if you read it you'll get zeros. The SSD's wear management algorithm will move the latter around as though it were real data, whereas it knows the former is "empty" so it won't bother (so the SSD will be faster). In other words, they don't seem to be using a "clean state" at all, which would explain why there's no difference.

Secondly, the SSD in the Macbook Air really isn't very fast at all

Which strengthens the hypothesis that they were comparing one "full" state with another. Pop out the drive, TRIM the whole disk in another OS, and run the benchmark again. It'll probably be a lot faster. It wouldn't surprise me if installing the Mac OS at the factory caused every block on the SSD to be used at least once (e.g. a whole disk image was written), which would mean you'd already be at the worse possible performance degradation.

Re:Two quotes stick out

[Anonymous Coward]

Next time don't skim, you completely misunderstood the first quote.

Re:Two quotes stick out

[izomiac]

Well, to be honest I did look a bit more at that part before criticizing it. On page two of the article they elaborate:

The Macbook Air we received from Apple had previously been sent to other reviewers, so we first needed to get the SSD into a "clean" state. While we have an established way of doing with Windows systems - using HDDerase to perform a low level format - we needed to find a way of doing this with OS X. The OS X installer actually allows you to load an app called Disk Utility, which can partition and format the drive - and one of the options is for a format which zeroes all the data.

According to Apple, "the "Zero all data" option... takes the erasure process to the next level by converting all binary in the empty portion of the disk to zeros, a state that might be described as digitally blank." The next level? Count. Us. In.

And the link goes to an Apple site that explains what zeroing the data does and how to do it.

Once we'd done this with the clean SSD, we then proceeded to give it a damn good thrashing. As with our Windows SSD testing, we filled the SSD with around 112GB of files from a USB hard disk - the files included OS files, game installs and media. We then deleted these files, then copied them across again, repeating the process ten times, so that we'd written over 1TB of data to the SSD.

So... they wrote over the whole disk with a format, then copied and deleted a bunch of files in hopes to get full coverage of the disk (i.e. exactly what the zeroing format did). That's about three levels of abstraction above what they're trying to test.

Re:Two quotes stick out

[broken_chaos]

if you read it you'll either get random data, or zeros (probably the later)

If you read a TRIMmed block directly, most drives will kick back zeroes. You can do this with hdparm -- particularly useful as a method to test if TRIM works (and it even uncovered a bug in ext4's TRIM implementation in data=writeback mode, where TRIM only works on metadata). Run hdparm -I on a SSD, and it'll actually say something along the lines of "Deterministic read ZEROs after TRIM" for most drives.

In other words, they don't seem to be using a "clean state" at all, which would explain why there's no difference.

Very true. There are only two methods I know of to 'clean slate' a full drive -- either TRIM the entire thing (with a tool like hdparm -- this is tricky to get right) or run an ATA Secure Erase command. Most SSDs take the secure erase command and just blank every NAND chip they have (taking ~2 minutes compared to the multiple hours that rotational drives take for the Secure Erase command) -- I've done this on my X-25M and it works brilliantly.

Unless Apple's Disk Utility actually does a Secure Erase command (which is very unlikely), then their testing methodology is entirely flawed, and their 'resetting' of the drive instead made it behave as if it was entirely, completely, 100% filled to the brim.

Re:Two quotes stick out

[AllynM]

Apple's description of the zeroing format method we used fits the description of what we wanted in terms of resetting the SSD to a clean state

Zeroing is not the same operation as TRIM. TRIM marks a block as unused, and if you read it you'll either get random data, or zeros (probably the later). Zeroing marks it as in-use, and if you read it you'll get zeros. The SSD's wear management algorithm will move the latter around as though it were real data, whereas it knows the former is "empty" so it won't bother (so the SSD will be faster). In other words, they don't seem to be using a "clean state" at all, which would explain why there's no difference.

Not only that, but writing to all free space of many SSD's will *drop* their IOPS performance since the drive now has to track *all* sectors in the LBA remap table. This is especially true with Intel drives (even the 2nd gen). Additionally, without TRIM, most drives will then continue to track all LBA's as long as used in that same Mac.

Secondly, the SSD in the Macbook Air really isn't very fast at all

A Macbook Air is just about the worst test of SSD performance, as its SATA and other busswork is run in a much reduced power mode, meaning the bottleneck is not the SSD at all. A worst-case degraded SSD in an Air will still be faster than the other bottleneck in that system.

Allyn Malventano, CTNC, USN
Storage Editor, PC Perspective

Re:Two quotes stick out

[scdeimos]

I read the Apple link (http://support.apple.com/kb/HT1820) and I don't see how it would be equivalent to TRIM on an SSD device.

Zeroing a device, as per the link, just writes zeroes to every block on it. From an SSD's point of view this means that every block is in use and just happens to contain zeros. Next time a request is made to write to a block it requires a (comparatively slow) read-modify-erase-write cycle. It won't make an SSD faster, but it may serve to securely erase the data on it (depending on its absence of wear levelling techniques).

TRIM on the other hand is used by the file system driver to say "I've deleted all data in this block, you can disregard it now." The device will erase it at its leisure. Next time a write is made to that block it's a simple (and fast) write cycle, without the read-modify and costly erase. Saving the erase cycle from interfering with a write is how TRIM-enabled drives gain their performance boost.

TFA's tests were invalid, because the drive was always in a degraded mode (assuming of course the 2008-era Samsung even supported TRIM).

Re:Two quotes stick out

[Anonymous Coward]

How did you run hdparm or Secure Erase? I was unable to get hdparm to run correctly under Linux on two Macs and the Secure Erase (CMRR) boot disk wouldn't boot on either a MacBook Pro or an Air. Please provide more info.

Re:Two quotes stick out

[Anonymous Coward]

The erase that's built-in to the drive utility is just a block-overwriter AFAICT. It would be useful to hear how someone invokes SE...

Re:Two quotes stick out

[broken_chaos]

I haven't done it on a Mac, only on a PC under Linux (more or less following this documentation). You may have to find an alternate tool to send the ATA Security commands to the drive, if hdparm isn't working.

Mind you, the drive has to support ATA Security commands (some may not) and has to be in an 'unfrozen' state (many BIOSes/EFI firmware freezes the drive at boot). This may mean you'd need to power cycle (disconnect/connect) the drive while the computer is running to unfreeze it (which, as long as the drive is entirely unmounted, is safe for an SATA drive). You might also be able to boot with it disconnected and plug it once booted instead.

There seems to be some information (some similar to what I've already mentioned) specifically pertaining to Macs/OSX here, though I haven't tested it.

Re:Two quotes stick out

[Anonymous Coward]

Yes, complete confusion on the part of the reviewers.
Firstly, writing 0s to a NAND device is the exact opposite of a free block because NAND erased state is 1,
though that may not be reflected as 1 to the OS I guess, but writing ANYTHING to it, 0 or 1 makes it DIRTY.
So they started with a totally dirty disk and then dirtied it a bit more. Surprise surprise.. it acted the same!

The only way to get a clean disk is to run the manufacturer's format utility which will run the correct low level commands
to do so.

One test they could do would be to just let the disk sit for a couple of days, and let it's background garbage collector clean up as much of he drive as it can
and then do a small write test. They should see good speed until the drive's reserve pool has been used up at which it should drop to the performance they saw here.

Re:Two quotes stick out

[Anonymous Coward]

Default isn't to do a secure erase, but there are options to do a 1-pass, 7-pass, and 35-pass secure erase.

Flawed article

[ShooterNeo]

The article writers made 2 major mistakes that cause their results to be meaningless.

1. They didn't secure erase the drive, which is what actually puts a drive back into a virgin state. They instead wrote zeroes to every sector, which means that the drive controller probably still thinks those zeroed out sectors are still in use.

2. The Samsung drive controller has a form of self cleanup that greatly reduces the need for TRIM.

3. Regardless, the SSD they used was slow as a dog and barely worth using over a HDD.

Re:Flawed article

[AHuxley]

Yes it was a pain to read, I just wonder how good the OS X clean up is and the Samsung hardware clean up last?
Seems sandforce and Intel are the current neat SSD's until we get super sized and next gen controllers :)
I wonder whats holding Trim back on OS X? Can trim in windows 7 nuke a drive?
Hows the Linux Trim supporting branches?

Re:Flawed article

[ekran]

I think that the biggest mistake in the test was that they wrote zeros to the drive first, which means that the blocks got allocated (dirty) and had to be read/rewritten with new data when the next phase of the test started. So, basically both tests are the same and it's no wonder they got about the same test results.

Re:Flawed article

[Rockoon]

Yes it was a pain to read, I just wonder how good the OS X clean up is and the Samsung hardware clean up last?

The answer is of course that the OS/X cleanup doesnt do jack-shit for the SSD, although it still may help out OS/X. The SSD doesnt see "cleanup operation" .. it sees "writing data that must be saved"

Apple is waiting to patent iSSD first

[kolbe]

Seriously though, MAC OS X has its roots with the BSD's of the world (Mach kernel http://developer.apple.com/macosx/architecture/) and one need only visit any of the number of SSD inquiries from the FreeBSD community to get an idea of how Mac OS X would respond at a kernel level: http://forums.freebsd.org/showthread.php?t=1169 for example.

Granted, there are some filesystem differences between the other BSD flavors and MAC OS X, but the architectures are very similar and one can draw the same conclusion as this parent review did:

MAC OS X can run quite well on SSD drives, it just hasn't been sanctioned by Big Brother Jobs yet. Remember too, Apple offered 128GB SSD's in their Mac Book Pro's as far back as 2008, so it's nothing new.

If you don't mind voiding your Apple warranty, I'd say go for it!

Re:Apple is waiting to patent iSSD first

[fuzzyfuzzyfungus]

The complicating factor, when trying to make any useful statements about "What Operating System Whatever does on SSDs" is that SSDs are totally free to do whatever crazy stuff internally, so long as they can present a coherent block device abstraction over the IDE/SATA/etc. bus.

TRIM happens to make the design problem easier; because it allows you to throw data on the floor when the OS says that they are no longer needed, rather than having to treat everything that isn't explicitly deleted as still good. However, before TRIM was available, manufacturers tended to do their best to design around its absence. This generally had a cost(either monetary, with lots of reserve flash driving up the cost, performance, with the drive either starting fast and taking a nosedive or just not being all that fast, or predictability, a given write operation could take milliseconds or it could take literal seconds, depending on the drive state).

Something wrong with testing methodology?

[whoever57]

Consider this statement:

Consider the Vertex: without TRIM, and when used, its sequential read speed for 1,024KB files is 137MB/sec; the Macbook Air manages 105MB/sec. With TRIM, the Vertex manages 258MB/sec in this same test.

According to their tests, TRIM has a big impact on read speeds, yet according to their explanation, TRIM should only have a significant affect on write speeds.

Re:cheese penis

[Anonymous Coward]

2.5 million B.C.: OOG the Open Source Caveman develops the axe and releases it under the GPL. The axe quickly gains popularity as a means of crushing moderators' heads.

100,000 B.C.: Man domesticates the AIBO.

10,000 B.C.: Civilization begins when early farmers first learn to cultivate hot grits.

3000 B.C.: Sumerians develop a primitive cuneiform perl script.

2920 B.C.: A legendary flood sweeps Slashdot, filling up a Borland / Inprise story with hundreds of offtopic posts.

1750 B.C.: Hammurabi, a Mesopotamian king, codifies the first EULA.

490 B.C.: Greek city-states unite to defeat the Persians. ESR triumphantly proclaims that the Greeks "get it".

399 B.C.: Socrates is convicted of impiety. Despite the efforts of freesocrates.com, he is forced to kill himself by drinking hemlock.

336 B.C.: Fat-Time Charlie becomes King of Macedonia and conquers Persia.

4 B.C.: Following the Star (as in hot young actress) of Bethelem, wise men travel from far away to troll for baby Jesus.

A.D. 476: The Roman Empire BSODs.

A.D. 610: The Glorious MEEPT!! founds Islam after receiving a revelation from God. Following his disappearance from Slashdot in 632, a succession dispute results in the emergence of two troll factions: the Pythonni and the Perliites.

A.D. 800: Charlemagne conquers nearly all of Germany, only to be acquired by andover.net.

A.D. 874: Linus the Red discovers Iceland.

A.D. 1000: The epic of the Beowulf Cluster is written down. It is the first English epic poem.

A.D. 1095: Pope Bruce II calls for a crusade against the Turks when it is revealed they are violating the GPL. Later investigation reveals that Pope Bruce II had not yet contacted the Turks before calling for the crusade.

A.D. 1215: Bowing to pressure to open-source the British government, King John signs the Magna Carta, limiting the British monarchy's power. ESR triumphantly proclaims that the British monarchy "gets it".

A.D. 1348: The ILOVEYOU virus kills over half the population of Europe. (The other half was not using Outlook.)

A.D. 1420: Johann Gutenberg invents the printing press. He is immediately sued by monks claiming that the technology will promote the copying of hand-transcribed books, thus violating the church's intellectual property.

A.D. 1429: Natalie Portman of Arc gathers an army of Slashdot trolls to do battle with the moderators. She is eventually tried as a heretic and stoned (as in petrified).

A.D. 1478: The Catholic Church partners with doubleclick.net to launch the Spanish Inquisition.

A.D. 1492: Christopher Columbus arrives in what he believes to be "India", but which RMS informs him is actually "GNU/India".

A.D. 1508-12: Michaelengelo attempts to paint the Sistine Chapel ceiling with ASCII art, only to have his plan thwarted by the "Lameness Filter."

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (- 1, Flamebait).

A.D. 1553: "Bloody" Mary ascends the throne of England and begins an infamous crusade against Protestants. ESR eats his words.

A.D. 1588: The "IF I EVER MEET YOU, I WILL KICK YOUR ASS" guy meets the Spanish Armada.

A.D. 1603: Tokugawa Ieyasu unites the feuding pancake-eating ninjas of Japan.

A.D. 1611: Mattel adds Galileo Galilei to its CyberPatrol block list for proposing that the Earth revolves around the sun.

A.D. 1688: In the so-called "Glorious Revolution", King James II is bloodlessly forced out of power and flees to France. ESR again triumphantly proclaims that the British monarchy "gets it".

A.D. 1692: Anti-GIF hysteria in the New World comes to a head in the infamous "Salem GIF Trials", in which 20 alleged GIFs are burned at the stake. Later investigation reveals that many of the supposed GIFs were actually PNGs.

A.D. 1769: James Watt patents the one-click steam engine.

A.D. 1776: Trolls, angered by CmdrTaco's passage of the Moderation Act, rebel. After a several-year flame war, the trol

Re:Traditional denial

[Jane Q. Public]

That's not the problem with their antenna. As it turns out, the algorithm they used to show signal strength ("bars") was incorrect... generally showing more signal strength than there really was. So what was happening was this: people thought they had a good signal when they really didn't. Then the slight loss from bridging the antennas pretty much took their connection down. It SHOWED as a big difference, but the real difference was very small.

The same tests done in an area where there is actually a good signal get completely different results. There is almost no different whether the antennas are bridged or not.

I didn't understand the 'benchmark'

[Joce640k]

FTA: "We simulated this by copying 100GB of mixed files (OS files, multiple game installs, MP3s and larger video files ) to the SSD, deleting them, and then repeating the process ten times,"

Surely you should be deleting half the files - every other file - then rewriting them. If you copy a bunch of files then delete them all you're leaving the drive in pretty much the same state as it was at the start, the only difference between passes wil be due to the wear levelling algorithms inside the drive. Overall performance at the end will mostly be a result of the initial condition of the drive, not what happened during the test.

Re:I didn't understand the 'benchmark'

[jedidiah]

> I've been running Windows XP since beta2, and it really kicks ass. I don't
> have to recompile my kernel when I want to install an ethernet card, it

        You didn't have to do this with Slackware in 1994.

> automatically detects it and installs the drivers no matter who the
> manufacturer is. Dual monitors? No chore with windows, get two video cards,

        Windows 7 doesn't even do this with hardware slightly older than it.

Re:I didn't understand the 'benchmark'

[TheLink]

No. When an OS deletes stuff, most drives do not know you've deleted stuff on the drive. All they know is the OS has said: "Write this on to that block".

The drives do not know that the newly written block means that a huge bunch of other blocks are no longer in use.

To take the extreme case, say you write to the entire drive and deleted the partition, the drive doesn't know anything about partitions - it just knows you've overwritten a few blocks, it doesn't know that almost all the blocks in the entire drive are now unused. So an SSD drive may assume that all that data is still wanted (and yes in some cases the FBI may want the data around even though the user might not ;) ).

I'd personally be worried about how buggy the current TRIM implementations are. Because any bugs in TRIM will be rather insidious. Imagine if they get "trimming a deleted partition" wrong on a drive with multiple partitions. You wouldn't notice anything wrong at first.

Re:I didn't understand the 'benchmark'

[Anonymous Coward]

I'm going to respond to this because I have nothing better to do at 1 in the morning.

I've been using Linux since 2003. I started with Mandrake then moved to Slackware and then finally Ubuntu. I've never had to recompile my kernel under any circumstances for any reason. It has automatically detected just about every device I've ever bought except for one really odd web cam. And trying that web cam in Windows XP did not produce any phenomenal results either. I ended up getting rid of it. So the only device Linux has had trouble with, windows couldn't handle either.

Dual Monitors: I love that you say Windows XP automatically handles and detects dual monitors/projectors/TV's etc... Yes that is why when I plug any monitor into my Windows laptop and have to go into desktop properties, cross my fingers that it detected something was plugged into my VGA port and then tell windows it's there with the correct resolution and all. Now it's true that I might have to do all this same stuff with Ubuntu, but that is only if I want to leave my computer on. I have another dandy option of just restarting my machine and watching the second monitor come to life on boot up. I would say that's is less work than what I have to do in windows. Especially since depending on what kind of video card you have the procedure in windows is completely different. Linux on the other hand is in-different to what video card you have when it comes to a second monitor (well Ubuntu is anyway). Got two video cards, need a video editing or production machine than I would say Linux would be the better choice. No driver install, no Cd's and once again just boot up and watch both monitors come to life with absolutely no work on your part. Other than doing something hobby wise, I can remember the last time I used an editor to do anything. Oh I remember, changing my PHP memory and last I recall windows doesn't have a beautiful GUI for that one either.

I've never, ever had a problem get Linux (Ubuntu) to detect and figure out for me some of the best ways to use the extra buttons on my mouse. For instance my scroll wheel not only goes up/down click, but it also clicks left/right. I don't remember ever telling Ubuntu what to do with that but if I ever get a web page that goes to far over to the right those extra buttons start scrolling left/right. No problem. Ubuntu put those buttons to use or me, it's a beautiful thing.

Need games, Google a little. You'll find hundreds (if not thousands) of "FREE", that's right I said "FREE" games. Unlike windows where I have to go to the store buy a games (that I will probably hate and can't return because they are afraid I copied it) then put the cd in the drive, install, then play. With Ubuntu it's open their nice GUI find a game, install, play, done. Or "sudo apt-get install ". Wow, that was so hard.

If you are actually going to try to pair windows stability vs Linux stability... I'm laughing so hard I can't finish that sentence. Over a month, wow. I've had a Linux server up for a total of 8 months and would have been up longer if I didn't feel it was time to update. Unfortunately that updated the kernel which meant restart. That sucked because that uptime was so nice. One of these days I'm just going to leave it running for years...

You have to be the first person on Earth I've ever heard say IE 6 was worth a lick of salt, never mind best browser, besides it's July of 2010. My Win XP machine is already running IE 8, don't you think it's time for an update.

And as far as development goes, you are pitting windows up against the OS designed for development. Since it's 1992 inception the main crowd of Linux has been developers. And sure you can use .NET if you like that over-bloated framework. You know that is something I just don't get, for years everybody complained about what a pain in the butt over bloated obnoxious framework Java was (and I'll admit although it's gotten better, even 5 years ago it really was obnoxious and bloated) and detested the thing to it's

Re:I didn't understand the 'benchmark'

[drsmithy]

You didn't have to do this with Slackware in 1994.

Yes you did. Linux didn't get kernel modules until around 1995 (and they weren't in common usage until years after that).

Windows 7 doesn't even do this with hardware slightly older than it.

Windows 7 installs perfectly on my old Dell Precision M60 laptop, released in 2003. Not only that, but it actually works properly with my docking station and external monitors - something none of the popular Linux distributions manage to do.

Re:Bad Summary

[mrsteveman1]

Actually TRIM ensures there are free blocks of flash ready to be written quickly, otherwise they have to be erased first even if the OS thinks that particular logical address wasn't being used, which has a substantial performance penalty.

My experience with SSD & a Mac

[putaro]

The HD in my Macbook Pro was failing and when I was shopping for parts, I noticed that PowerbookMedic (normally I'd just go buy a hard drive locally but I needed to replace the DVD drive as well so I figured why not just get it all in one go) had an SSD available at a reasonable price so I purchased it on the theory that whatever they were shipping was a decent fit for the Mac - they didn't have any maker info on the page but I figured that the only real difference between SSDs would be max bandwidth and anything would be an improvement over a regular HD so I didn't do any research. When it arrived it was a G.Skill drive (128GB).

When I first installed it things were very zippy and I was really happy. After about a month, though, things started to slow down and I started researching and found the SSD fragmentation problem that's been referenced often. Zero'ing out the unused space on the disk did give a bit of a performance boost, but not back to the original levels. Eventually things got so bad that I removed it and replaced it with a regular HD and things got much better.

So, a few points:

1) HFS+ is not magically aligned with SSD's somehow (the Macbook Pro is running Snow Leopard so it's got the latest OS updates). You can still hit the fragmentation problem.
2) A lot of people are saying that overwriting with zero's won't do anything. Any controller will detect a block of zero's as being unused data and just mark the block as such. It's not hard to do, it's an obvious thing to do, and even the worst controller out there has a boatload of firmware in it - they are not just bare flash RAM chips hooked to the ATA bus somehow.

Re:My experience with SSD & a Mac

[mindstrm]

"Any controller will detect a block of zero's as being unused data and just mark the block as such." - can you cite a source for that? It makes sense, as long as we're talking about full, raw blocks full of zeroes.

And it's still a hack, compared to a simple command like TRIM which simply says "No longer in use - zap away" - it's just something we never had to worry about before, and now we do - there are lots of other clever hacks - but it's still necessary.

Re:My experience with SSD & a Mac

[the_other_chewey]

"Any controller will detect a block of zero's as being unused data and just mark the block as such." - can you cite a source for that? It makes sense, as long as we're talking about full, raw blocks full of zeroes.

No it doesn't. What if I write a large file that is padded with zeroes to a certain size I intend to use later?
I certainly hope that my SSD will not eat away that file's padding...

Re:My experience with SSD & a Mac

[putaro]

Hmmm...I thought I had seen a real reference somewhere but I looked and all I can find are anecdotes. It *should* work that way :-). Manufacturers are not releasing much information on this internal fragmentation issue, especially the ones that have a real problem with it.

TRIM is a hack as well. It would probably be easier to just up the block size to match the native cell size but that would break a lot of existing filesystems since everybody standardized on 512 byte disk sectors ages ago.

Re:My experience with SSD & a Mac

[putaro]

The SSD is a level below the file system so if it marks something as "unused" that won't really affect how long the filesystem thinks the file is.

If you write a block of zeros to it and it gives you a block of zeros back, then you still have the zeros "in" your file. If internally it just checks a flag first to see if the block is marked unused and returns all zeros if it is, you can't tell the difference.

Re:My experience with SSD & a Mac

[moonbender]

It could erase the page and still mark it as being in use. Thus the page isn't used for wear-levelling by the drive, but if you ever rewrite to that page, it'll be a lot faster since the whole block containing the page won't have to be rewritten. Of course that still means the drive runs out of unused blocks after a while, but it's still an improvement over a drive with no TRIM support at all (or a drive used in an OS without TRIM, e.g. Ubuntu 10.04).

Re:Bad Summary

[mestar]

Yes, and as we know, solid state disks lose performance when files are fragmented, because, when the disk spins, err, i mean the electrons, the heat goes around, ah, fuck it.

Re:Bad Summary

[DJRumpy]

I have to wonder why they didn't boot into Windows on the same PC and repeat the tests. That would have identified if it was a hardware issue, or a software (Filesystem) issue that caused the irregularity.

Re:Bad Summary

[Nimey]

Mod parent overrated. TRIM is to help keep the drive running at a good pace once it's been written to over a period.

The problem with SSDs is that they can read/write only a page at a time; they do not address individual bits or sectors. Over time, this means that a given page (I forget the size, maybe 64KB) will have parts of multiple files in it. Therefore, writing to one of the files in that page means that the drive has to re-write each file, and if one of the affected files is spread across several pages, then those pages have to get re-written, and so on. Write performance, and to a lesser extent read performance, goes into the toilet.

Enter TRIM, which keeps files to a minimum number of pages and is typically run in the background as a garbage-collection measure.

How are the sandforce units going?

[AHuxley]

How are Mac users with Mercury Extreme SSD's or the Mushkin ect units doing?
They might be a bit different to the units Apple found at a set price point to max the profits.
Most of the Apple users sites seem to like the idea of a ~ TRIM via a removal of all data, zeroing and a copy back of the OS. Thanks

Re:How are the sandforce units going?

[MassacrE]

How are Mac users with Mercury Extreme SSD's or the Mushkin ect units doing?

Based on my research, the sandforce-based disks have a minimum reserve space of 7% (so say, 16GB of a 256GB disk). When you perform a write, it merges the old data and your changes to create a new block on the SSD, and then maps that into the computer’s view of the disk - the computer only sees new data, but the address now points to a different part of the physical disk. The ‘old’ block is cleaned by the drive whenever the drive becomes idle again, and added to the reserve pool, most probably to the end to promote more even wear.

If you did a large burst of writes (say, ~16GB of data on the 240GB-rated drives) you should see performance plummet, as the drive is kept busy and hasn’t been able to blank out the dirty pages in the reserve space. I imagine this is the purpose of higher performance, 200GB-rated drives; they just reserve a larger amount of space to deal with these sorts of usage bursts.

If you have TRIM support, it should be possible for the deletion of files to cause the reserve space to grow, as the TRIM command is issued by the filesystem layer to indicate to the drive that there is no longer relevant information on that section of disk.

TRIM is really important for drives without reserved space, as once you fill up the disk every write will first require a section of the flash to be wiped clean.

How does it work is a mystery to me

[Ilgaz]

First of all, Apple HFS format family has been critized for using the exact same areas of disk (for B Trees, journal) eventually wearing them off. I didn't buy the claims until I noticed an external USB drive has couple of bad sectors on exact "metadata"/B-tree area. Another USB drive got wasted (actually converted to fat32) and I finally agreed to that claim. It is magnetic drive I talk about, on SSD things can really get ugly.

They could move the B-Trees and journal, actually advanced disk optimizers like iDefrag does it every time whenever it spots that they aren't close to beginning of drive but it seems they didn't even implement that basic counter measure. BTW; obvious but, nobody should "defrag" a SSD drive.

I was expecting they add such enhancements with the OS X version shipping with Macbook Air and yet, nothing happened. It is not bad as NTFS but, HFS+ has to have some workarounds for SSD.

Wonder if "We do ZFS, no it is target of patant trolls" period has something to do with it. No matter what people say, they were really serious about ZFS until Sun CEO stupidly leaked it and that company whined about their patents made them totally give up the idea.

Perhaps, something like UFS+ in future?

Re:How does it work is a mystery to me

[scdeimos]

BTW; obvious but, nobody should "defrag" a SSD drive.

That's not necessarily the case and it also depends on the defragmenter strategy.

With SSD typically having 128kb or 512kb erase blocks and their client file systems typically having 4kb-64kb clusters it can actually make sense to defragment a TRIM-enabled SSD every now and again. Gathering all of the directory/file blocks together allows the file system to TRIM as many blocks as possible and improve performance - otherwise you'll have all these partially-filled erase blocks hanging around that may only contain one or two file system clusters and can never be TRIMmed as a result, along with the read-modify-erase-write performance penalty you get when updating them.

Re:Bad Summary

[scdeimos]

You both need to read up on TRIM (and I'll leave it at that)... http://en.wikipedia.org/wiki/TRIM

Holy fuck, what's with all the trolls today?

[Anonymous Coward]

Slashdot is going down the crapper.

Re:Holy fuck, what's with all the trolls today?

[AHuxley]

OS X seems to bring them out in force :)

Trim is a hack

[KonoWatakushi]

The problem is that a Flash based SSD needs to have a pool of unused blocks to work around the block-erase stupidity. However, trim only "solves" the problem when there is a good deal of free space on the drive anyway; when the drive nears full, it is useless. At the current pricing, people don't buy SSDs to keep them empty, and one would not expect an SSD to perform badly when full, as with rotating rust.

The solution is to provision enough extra blocks on the drive beyond the advertised capacity. While the vendors refuse to do this, you may do so yourself. Simply create an empty partition the drive--just make sure it isn't ever written or zeroed.

Anyway, the vendors' motivation to cut corners here should be perfectly clear.

Why not just open fs.blocksize to 64-256k?

[redelm]

TRIM just seems to be yet another abstruse abstraction layer. Why not just allow filesystems (HPFS, UFS, ext[234]) to have large blocksizes?

Jes, I know the Intel MMU pages are either 4k or 4M. And people like "saving disk" since on average half a blocksize is wasted per file. But 4k is a tiny blocksize, set IIRC for newspools that few use. It only wastes 10 MB on a 5,000 file/dir system. That is not enough!

A 128 kB blocksize to match the hardware bs would "waste" a more reasonable 320 MB. Only 1% of the minimum 32 GB SSD.

Re:Why not just open fs.blocksize to 64-256k?

[AHuxley]

TRIM makes you need Win 7 for real ;)

Re:Why not just open fs.blocksize to 64-256k?

[redelm]

I need MS-Windows like a need a hole in my RAM. Which it leaks :)

Re:Why not just open fs.blocksize to 64-256k?

[mindstrm]

TRIM isn't about blocksize - it's about letting the drive know that a block can be freed up and reset to a fast-writeable state - only the filesystem driver can do that in a meaningful way - the drive can't automatically know on it's own.

You an cleverly hack around with GC and spare blocks and whatnot to keep SOME blocks free and available all the time, but they won't necessarily represent what the filesystem thinks are free - so it's sub-optimal. TRIm isn't an abstraction layer - it's a simple command to effect a simple action that wasn't previously necessary because this limitation simply does not exist on magnetic media - we don't have to erase it before writing to it again.

Re:Why not just open fs.blocksize to 64-256k?

[redelm]

I thought TRIM was more about telling the flash controller that nearby blocks were trash so they did not need to be read before an infill write. With matching flash and fs.blocksize, read-before-write is not necessary.

Re:Why not just open fs.blocksize to 64-256k?

[putaro]

I think it's reasonable but I'm sure there's a lot of code down in the FS layers that would break. No one has had to deal with a non-512 byte sector disk for a while.

Re:Why not just open fs.blocksize to 64-256k?

[moonbender]

I though so, too, but the block size would have to be 512 kB... Not sure if it's worth it.

Re:Why not just open fs.blocksize to 64-256k?

[Anonymous Coward]

Just increasing the sector size wouldn't help with SSD performance. With larger sectors an no TRIM, all sectors would have to be erased before beeing written to (that's just how Flash works). The erase operation is actually the expensive part, reading or writing is pretty fast, so all reasonable SSDs keep a pool of pre-erased sectors available and add to that pool whenever something is TRIMed or they run an internal garbage collection. Another reason for not havin a 1:1 mapping of flash sectors to filesystem sectors is wear leveling. Without the remapping, you would ruin the sectors where you /tmp or c:\temp directory resides within weeks at most.

Aligning the filesystem (more or less) to the internal sector size just makes sure that writing 4k doesn't require erasing 2 flash sectors, which would happen rather frequently with old PC/MBR style partitions that start at sector 63.

Re:Why not just open fs.blocksize to 64-256k?

[redelm]

If a pool of pre-erased blocks is a good idea, then just turn on one of the fs "secure" options that erases deleted blocks rather than simply marking them unavailable.

Re:Why not just open fs.blocksize to 64-256k?

[Tacvek]

Trim has both purposes. If you trim a large file, it may have several physical erasable blocks become blank, thus allowing the drive to erase those whole physical blocks when idle, allowing fast writing to those physical blocks. It also tells it which of the logical blocks in a physical block are considered garbage, allowing the drive to skip them when reading that block, when rewriting that group of logical blocks.

The second purpose becomes redundant if the file system uses larger sector sizes, and the OS also tells the device that it wants larger addressable blocks, matching the increased sector size. The first purpose remains useful, assuming it is not important to you that blocks not actively used remain intact.

Re:Bad Summary

[wvmarle]

So basically if I understand it well, this is in effect an anti-fragmentation measure. When files get fragmented performance starts to degrade. In a way I have the feeling that if you match the block size of files written to the block size of the SSD (optionally padding with zeros to fill it up) you could get quite a performance boost - and only when the drive starts to fill up start using the unused, zeroed out fragments from the blocks.

Or would it be possible use the anti-fragmentation measures built in into many file systems directly instead of TRIM?

An apple a day keeps the doctor away

[Anonymous Coward]

while Microsoft and the SSD manufacturers have publicized its inclusion in Windows 7, Apple has been silent on whether OS X will support it

Isn't that kind of like comparing apple's and lemons?

how can you _boot_ into windows on hpfs+?

[Anonymous Coward]

windos cant boot from hpfs+ (or ext3 or reiserfs (3.6 or 4), or zfs or really anything new and high performance except for uh, ex(tra)fat, then again these filesystems might require acls or a layer to account for windos acls)

sure you could reformat it and install windows, but this would be unfair as we know the performance would suffer on writes to blocks that need to be erased before they can be written. another possibility would be a proper flash erase and then install windows to rule out some "hardware issue". so far the implication is that its the windows ntfs filesystem and (after the necessary testing) some linux filesystems that may be doing something differently to hpfs+.

Re:how can you _boot_ into windows on hpfs+?

[DJRumpy]

No, using a windows partition on the Mac and NTFS as the file system via Boot Camp. It would eliminate hardware and allow Apples to Apples (no pun intended) between OS's. It's trivial to set up such a configuration on a Mac.

windos cant boot from hpfs+ (or ext3 or reiserfs (3.6 or 4), or zfs or really anything new and high performance except for uh, ex(tra)fat, then again these filesystems might require acls or a layer to account for windos acls)

Re:how can you _boot_ into windows on hpfs+?

[jabbathewocket]

The point is that while it would allow them to isolate whether the *drive* itself in the macbook air is somehow immune to the issue, or if its something to do with the operating system/file system preventing the issue to occur.

IE if You do the tests in OS X, rezero the drive install windows xp/vista run them again (in NTFS on the mac's ssd), then finally install windows 7 also to a clean drive under NTFS and run the tests a final time (this last test would have trim enabled of course)

Chances are that what is happening is that the OS X has an artificial limit in speed (for whatever reason) masking the problem.. If that theory is correct then installing windows 7 to a freshly zero'd drive on the air, should result in significantly faster initial performance than measured under OS X, with a dropoff to roughly the levels measured under OS X over time.

Re:how can you _boot_ into windows on hpfs+?

[Endophage]

Although this makes me wonder whether 2 partitions with different filesystems would have any effect on the performance of the drive...

Re:how can you _boot_ into windows on hpfs+?

[DJRumpy]

It should have a negligible effect on an SSD as each OS is in it's own logical container. Things like outside edge vs. inside edge of a plater affecting seek speed are meaningless for solid state drives.

I also don't buy the fact that the drives in the Macbook Air mentioned in the article may be such poor performers that they would skew the results, although they were definitely not top of their class, they were far above drives that are actively experiencing this problem, meaning the drives performing at their worst, and being effected by this, should drop to a similar 'poor' level of performance. The SSD's on the Macbook Air still performed acceptably with negligible loss (MB's/s rather than KB's/s), even on the random read/write 4K tests.

Re:Bad Summary

[poetmatt]

the latter is correct. filesystems that mac and linux use don't have fragmentation issues anywhere near the extreme that NTFS does.

Re:Bad Summary

[wvmarle]

That gives me the idea that an SSD should be tested with different file systems as well to see effects. Such as ext2 (no journaling), ext3/4 (ext2 with journaling: often seen as an issue because of the many writes), Apple's HSF+, and NTFS, and then as far as possible with and without TRIM enabled. Could be interesting. Preferably identical hardware, each file system with it's native OS.

That said I don't recall having seen any story here about such tests: which file system is best for your SSD (performance wise, wear/tear wise). Also I still haven't heard about SSD-specific file systems, while that would make sense to me considering the large technical differences between HDD and SSD. A file system should be able to take advantage of that.

disk images are only of in-use blocks

[SuperBanana]

. It wouldn't surprise me if installing the Mac OS at the factory caused every block on the SSD to be used at least once (e.g. a whole disk image was written), which would mean you'd already be at the worse possible performance degradation.

Disk images on the mac made by hdiutil (which is what Disk Utility is largely a front-end to) are almost always a copy based off files or just in-use blocks to a new image- the image is copied bit-by-bit back (for speed) and then the filesystem is expanded afterwards. This allows Apple to have one disk image, not one for each size hard drive shipped- and gives maximum speed (for magnetic drives.)

what about journaling?

[vaporland]

The question was asked in TFA comments whether or not OS X disk journaling was turned on. The question was not answered. It seems to me that this would have a profound effect on performance.

Re:Bad Summary

[billcopc]

Yes and no. Wear-leveling happens with or without TRIM, but what TRIM does is tell the SSD controller that a block can be treated as "virgin", meaning it can be overwritten in a single pass. This is an optimization as normally one must read the contents of an entire block, combine it with the incoming data, erase the block on-disk and finally write the newly-merged data.

Contrary to popular ignorance, the slowdown is not caused by "fragmentation" - that's backwards, when the drive is clean it is cheating by skipping part of the write cycle. In other words, an SSD's dirty performance is its normal, sustainable speed. When it is clean, it can go faster because it is being LAZY, by short-cutting the Read-Erase-Update cycle. For obvious reasons, most SSD vendors, particularly in the consumer segment, advertise the maximum speed when really the honest thing would be to advertise the minimum speed.

proof is in the pudding

[Dr.D.IS.GREAT]

OSX rulez! it will even get you laid, especially if you have an ssd :D

http://www.youtube.com/watch?v=coAep95p5kY

Re:Bad Summary

[Anonymous Coward]

No, no, no. TRIM is not a SSD memory management command, and has nothing to do with fragmentation. It is also important for storage technologies other than SSD.

Of course blocks/sectors on any device will have multiple files on each sector. SSDs are no different in that regard. What gets presented to the filesystem is still a block device.

It probably does not help NTFS that much for use on SSDS that by default it has a 4K block size (whereas HFS+ has a 16KB blocksize).

A SSD's erase block size is generally 128KB, and a properly configured filesystem, will therefore be 128K aligned. So the "perfect" allocation cluster size for a SSD for optimal performance would be 128K block size, but alas, few file systems other than ZFS will do so..

The ATA TRIM command is equivalent to the SCSI PUNCH command.

It is basically a way for the OS to tell the disk subsystem, that certain blocks of the disk is now NOT USED; in other words, the disk layer can throw them away.

This is referred to block layer discard

It allows the disk to know that a bunch of blocks are no longer used by the filesystem and can be discarded.

If the block device is a SSD, once it receives a TRIM command, and a whole 128K erase block has been trimmed, it would generally make sense for the device to schedule the underlying flash pages that block resides on to be erased and prepared to have new data written to it.

Unlike with a standard hard drive, when you are dealing with flash memory: a flash memory page that had any data on it has to be completely erased before any new data can be written to it.

Write performance will go to hell if the SSD runs out of non-erased memory pages to store data to. Since it means a usable page will have to be erased to store that block.

When an existing block gets overwritten, new (unused) flash memory has to be consumed as if it was an entirely new block.

Therefore, if there ARE non-erased memory pages available to store data to, When you overwrite a non-TRIM'ed block, one of the free/remaining non-erased underlying memory pages will likely be consumed (since there is not enough time to quickly erase a page to implement 'overwriting')

Re:All Open Source Developers are Shallow

[Anonymous Coward]

You mean don't use Linux, it turns you into queer bait. As a gay man, all I can say is: "pfft, I wish".

Re:Bad Summary

[mysidia]

I have the feeling that if you match the block size of files written to the block size of the SSD (optionally padding with zeros to fill it up) you could get quite a performance boost - and only when the drive starts to fill up start using the unused, zeroed out fragments from the blocks.

With SSDs it's erase block size that matters most. When a page of memory on a SSD device is being overwritten, the page has to be erased first, and then its contents rewritten.

Of course if your OS implements SCSI PUNCH or ATA TRIM, immediately when a block is freed, your SSD drive can have the memory erased ahead of time, and ready to use with minimal write latency.

Most SSDs use an erase block size of 128K. So you would want your entire filesystem's allocation blocks 128K aligned.. in NTFS world, this would mean you need to align the disk partition, at least prior to Vista/Windows 2008.

I believe MacOS automatically aligns partitions. This issue alone could explain why things might get so bad with Windows, let alone the ridiculously small 4K block size, or fragmentation issues that plague NTFS filesystems.

And the ideal allocation cluster size is 128K (by default NTFS cluster size is 4K, which is not suitable. for best performance change in such a scenario it to 64K)

You can think of the performance issue that can occur as something like RAID stripe crossing.

If you have two 4K blocks side by side, and you need to overwrite just those two blocks.. if they are on different 128K erase blocks, your SSD will be having to write 256K of memory to change 8K of data.

If those 2 NTFS blocks are on the same SSD block, your ssd flushes and writes 128K of data, maybe.

This is before we start thinking about wear-levelling algorithms,

or the fact an efficient SSD will likely keep a pool of non-erased blocks, to satisfy write requests against.

So as long as there is memory left that was scheduled for erasure and flushed due to TRIM or flushed due to being overwritten, there would be no reason to require an extra in-line ERASE (increasing write latency).

So the pool of non-erased pages are important, and the critical elements effecting write performance are (1) time to update header blocks to re-map disk blocks to unused flash pages, and (2) time to copy the erase block with changes to the newly mapped location.

Re:cheese penis

[Mitchell314]

I was going to mod this up, but that doesn't do it justice. Really had me laughing there, that was good.

TRIM equivalent

[m.dillon]

All SSDs have a bit more storage than their rating. Partitioning a little less space on a vendor-fresh drive can double or triple the extra storage available to the SSD's internal wear leveling algorithms. For all intents and purposes this gives you the equivalent of TRIM without having to rely on the OS and filesystem supporting it. In fact, it could conceivably give you better performance than TRIM because you don't really know how efficient the TRIM implementation is in either the OS or the SSD. And because TRIM is a serialized command and cannot be run concurrently with read or write IOs. There are a lot of moving parts when it comes to using TRIM properly. Systems are probably better off not using TRIM at all, frankly.

In case people haven't figured it out, this is one reason why Intel chose multiples of 40G for their low-end SSDs. Their 40G SSD competes against 32G SSDs from other vendors. Their 80G SSD competes against 64G SSDs from other vendors. You can choose nominal performance by utilizing 100% of the advertised space or you can choose to improve upon the already excellent Intel wear leveling algorithms simply by partitioning it for (e.g.) 32G instead of 40G.

We're already seeing well over 200TB in endurance from Intel's 40G drives partitioned for 32G. Intel lists the endurance for their 40G drives at 35TB. I'm afraid I don't have comparitive numbers for when all 40G is used but I am already very impressed when 32G is partitioned for use out of the 40G available.

Unfortunately it is nearly impossible to stress test a SSD and get results that are even remotely related to the real world, since saturated write bandwidth eventually causes erase stalls when the firmware can no longer catch up. In real-world operation write bandwidth is not pegged 100% of the time and the drive can pre-erase space. Testing this stuff takes months and months.

Also, please nobody try to compare USB sticks against real (SATA) SSDs. SSDs have real wear leveling algorithms and enough ram cache to do fairly efficient write combining. USB sticks have minimal wear leveling and basically no ram cache to deal with write combining.

-Matt

Re:TRIM equivalent

[Peter Desnoyers]

All SSDs have a bit more storage than their rating. Partitioning a little less space on a vendor-fresh drive can double or triple the extra storage available to the SSD's internal wear leveling algorithms.

This won't actually work - partitions don't exist from a disk's point of view, but are just bytes in sector 0. The SSD will religiously preserve the useless data in the sectors outside of the partition you create, using up space that could otherwise be put to good use.

As other posters have explained in bits and pieces, flash chips can be written in pages (2KB or 4KB, usually) but have to be erased in blocks (64 or 128 pages). If you overwrite 10 pages in the middle of a block, the writes will go into fresh pages somewhere else, and the original 10 will be useless until you get around to erasing the entire page. Since those other pages are holding data, you can't erase them until they either (a) get replaced by additional new writes, or (b) are moved somewhere else. If you end up having to copy say 3 pages of data for every new page you write, your write performance is going to go down by a factor of 4.

The more free space you have, the more likely it is that even with totally random writes there will be some blocks that are entirely empty and can be erased without having to copy any data. That's why the 32GB Intel X25-E (the enterprise drive) has 40GB of flash chips inside it. On the other hand, just about every consumer drive has 6.7% or so free space, because that lets them use say 64GB (64 * 2^30) of flash chips and legally advertise it as 64GB (64 * 10^9).

Typically your file system has a fair amount of free space (compared to 6.7%), because performance suffers and you run the risk of running out of space when you get close to 100% usage. Without TRIM, however, the SSD can't make use of that space, and carefully preserves the contents of every block on the file system free list. In theory TRIM should allow the OS to identify the file system free list to the SSD, which will then have much more space available for garbage collection, resulting in reduced copying and better performance. In practice, your mileage may vary.

Re:TRIM equivalent

[Anonymous Coward]

This won't actually work - partitions don't exist from a disk's point of view, but are just bytes in sector 0. The SSD will religiously preserve the useless data in the sectors outside of the partition you create, using up space that could otherwise be put to good use.

If you partition the drive when new, or after it has been properly wiped (i.e. using the TRIM command or Secure Erase to wipe the drive), then the drive will know the un-partitioned space really is unused, so it should be able to make use of it. Whether it does or not depends on the drive's controller and wear-levelling algorithm, but it is not an unreasonable hypothesis, though there doesn't seem to be any real evidence to confirm or invalidate the hypothesis.

Re:Traditional denial

[m.dillon]

All cell phone vendors goose the signal strength meter. All that happened was that Apple goosed it so much they got caught red-handed and were forced to admit it. It certainly was NOT a software bug or a mistake. There is no way it could have been anything but intentional (before they got caught) IMHO.

-Matt

Re:Bad Summary

[Lennie]

Euh, the SSD doesn't know anything about the filesystem layout, thus files.

Re:Bad Summary

[Lennie]

I did add noatime to ext4 mount options for my SSD.

Re:Bad Summary

[fractoid]

Therefore, writing to one of the files in that page means that the drive has to re-write each file, and if one of the affected files is spread across several pages, then those pages have to get re-written, and so on.

What? Why? Yes, you can only erase an SSD a block at a time, but you don't have to re-write any other blocks. You just read the affected block into memory, erase the block, update the copy in memory with the changed data, and write it back. The only other data you have to change is the block lookup table used for wear leveling, which maps a logical block ID to a physical block of memory.

I wonder if they've done something non-standard but clever to mimic the functionality of TRIM? Like explicitly overwriting any deleted blocks with zeroes at delete time (or soon afterwards, as a low priority job) so that they don't need to be erased when recycled? If that's even possible with current APIs...

Funny but not totally correct

[Mathinker]

Yes, and as we know, solid state disks lose performance when files are fragmented, because, when the disk spins, err, i mean the electrons, the heat goes around, ah, fuck it.

Your reply was witty, but all of the EEs here on Slashdot will tell you that, for example, trying to write to random addresses in, for example, DDR2 memory when you could have written the same data to contiguous addresses, is a very bad idea. The only reason programmers don't feel this difference quite so much is that the cache hierarchy of the CPU is babying them.

Re:Funny but not totally correct

[Anonymous Coward]

Sounds like a dig on object oriented languages wasn't completed.

I've seen some of the most data fragmented code...

Re:Bad Summary

[Anonymous Coward]

Not if the SSD has mor physical blocks than logical. If it had it could erase all physical blocks that were not mapped to logical blocks and use one of them at the next write.

But why is this an issue at all?

[randyleepublic]

Why haven't patches been made for all the major file systems so that they have am option to run "SSD mode"? In SSD mode the file system tells the SSD which blocks to erase. What is so diff?

Re:Bad Summary

[sjames]

Actually, you can clear bits to 0 at any time, bit by bit if desired. You can only set bits back to 1 sector by sector. That erase process is not fast. Because of that, we would like to queue up sectors for erase as soon as they're no longer needed. However, most filesystems just mark a block as free and assume it can be freely overwritten without penalty.

TRIM informs the SSD that a given block of data (which is likely smaller than the erase sector) will not be needed again. That way, when the erase sector needs to be copied in order to modify a block, the unwanted ones can be skipped and so become ready to be written immediately.

Mod parent up

[TheThiefMaster]

There's a lot of misinformation in these comments, and parent actually seems to know what they're talking about...

iTrim

[Anonymous Coward]

TRIM is sooo outdated. With the new iTrim you can take care of your disk by simply shaking the notebook.

And if you don't belive it Steve WILL multitouch your retina.

Re:Traditional denial

[kangsterizer]

Are you being sarcastic or just proving my point?

24db loss is FAR from a slight loss. It means the range you can get an equivalent signal has just been divided by 8!

Re:cheese penis

[sakdoctor]

Can I get this as a Civilization IV mod?

Re:cheese penis

[jawtheshark]

Minor nitpick: it's "Marconi", not "Marcoli"... unless I missed the joke in that...

Silly testing procedure

[buserror]

They used the "write zero" disk erase method, which in fact un-erase every NAND block of the disk, which in turn forces the disk to erase each block again as it writes. Thats why they see such consistency of results : they are measuring the worst possible case where the disk is forced to the slow path for each block.

To erase NAND, you need to erase it by block, and the resulting block is full of 1's. Writing to NAND is a question of writing zeros in places, you can't write 1's on NAND unless you erase it.

So in a way, their test is showing that OSX is much, much better than windows when the disk is dirty, but that apple hasn't implemented the "trim" that allows the disk to re-erase nand 'free' blocks.

Re:Silly testing procedure

[emt377]

They used the "write zero" disk erase method, which in fact un-erase every NAND block of the disk, which in turn forces the disk to erase each block again as it writes. Thats why they see such consistency of results : they are measuring the worst possible case where the disk is forced to the slow path for each block.

To erase NAND, you need to erase it by block, and the resulting block is full of 1's. Writing to NAND is a question of writing zeros in places, you can't write 1's on NAND unless you erase it.

So in a way, their test is showing that OSX is much, much better than windows when the disk is dirty, but that apple hasn't implemented the "trim" that allows the disk to re-erase nand 'free' blocks.

While erased flash is all 1's, it's complemented before the host sees it, so the host reads erased flash as all zeros. So filling a drive with zeros is pretty much the same as erasing it. And if the drive controller is remotely intelligent it will detect that a sector is written with all 1's and not bother even allocating it; it can store a magic value in the sector map to indicate this logical sector is blank and has no physical allocation. The first non-zero write to it would then cause it to be allocated. The fact that at least one common OS tool writes zeros (and DU can't be the only one) to erase drive space is pretty good motivation to handle this correctly at the allocation level. I think it's pretty safe to assume that any firmware engineer who works on SSDs is perfectly aware of all these aspects - and more.

Re:Silly testing procedure

[buserror]

I think you give credit a bit generously here. And in any case, how do you explain 1) the linearity and consistency of results 2) the fact it's consistently slower than a windows with Trim support ?

If the blocks were truely erased, at the very least the peak write would be significantly faster, but it's not.

The only other wacky possibility would be for the OS to be the bottleneck.

4.

[Sycraft-fu]

They didn't test it on a high performance platform. The Air is, unsurprisingly, optimized as a low battery usage mobile device. This implies a number of things, none of them good for trying to do high speed SSD testing. A more appropriate platform would be a Mac Pro, and perhaps look at adding on a high speed SATA card for good measure.

Now I can appreciate testing on a non-performance system too, but not if your objective is to test TRIM. In that case you need to be on a high end system so that the system isn't where things slow down, and difference will be due to the disk. Then, once you've established that, you can test if that difference matters to lower end computers.

Re:Traditional denial

[Jane Q. Public]

The tests I read about were done by AnandTech. And yes, 24db is considerable, but it should not be enough to cause connection loss if you had a good signal to start with. That was my point, and that was what the article said their tests showed as well.

By way of comparison, they also found that the way you hold an Android Nexus can attenuate your signal up to 18db... even without bridging any antennas. So it's not like the iPhone 4 has a totally unique problem. It's just a little worse than some.

Re:Bad Summary

[TheRaven64]

When files get fragmented performance starts to degrade

Nope, fragmented files are not a problem at all for flash. The problem is fragmented free space. Flash is partitioned into cells. Once a cell is blank (all ones), you can write to it once, then you have to erase it. Imagine that your cell size is 64KB and you write 32KB files all over it, then delete every alternate one. Now, before you can write any files, you have to erase a cell. If you want to write a 1KB file, you have to read a 32KB file into a buffer somewhere, erase a 64KB block, rewrite the 32KB file, and then write the 1KB file. This is very slow. With the TRIM command, you can tell the drive that the 32KB blocks are no longer in use, and it can compact the allocated space while the drive is idle, then have some free space for writing into, without needing an erase, later.

Re:Bad Summary

[wvmarle]

When files get fragmented performance starts to degrade

Nope, fragmented files are not a problem at all for flash.

With fragmented in this case I meant fragmented over many partial cells instead of using only complete cells except for the last one. Not fragmented as in the sense for platters where it means the file is scattered all over the disk.

auto defragment related?

[mynion]

I seem to recall osx or to be more precise hfs auto defragments a file when it is loaded. ie it loads a file then says "oooh messy" and writes it back in the background.
So the file second invisible write happens after the initial write time and in fact after a subsequent read time operation.

I wonder if osx is just doing things when it isn't being measured and files are constantly moving to spare gaps as a result.

(Someone must know more about hfs than my fuzzy memory to verify/refute this theory).

Re:Bad Summary

[TheRaven64]

And, as I said, that doesn't matter. The files can be split over a lot of different cells and it won't matter more than a tiny bit when it comes to transfer. The cells are only used for writing. For reading, the entire thing is random access. You will need to send more commands to access non-contiguous blocks, but that's a pretty small overhead. It's the fragmentation of empty space, not the fragmentation of files, which causes problems for flash.

Re:cheese penis

[Endophage]

particularly liked 1799 :-)

Re:cheese penis

[BitZtream]

The funny part is that you think the caveman was dumb enough to release his new invention under GPL and give up every advantage he had.

Block Size vs. Storage Efficiency Problem

[billstewart]

Definitely you can do that - the problem you run into is the tradeoff between block size and storage efficiency, because you lose space at the end of a block of data. And you care about it more on small expensive disks than on big cheap ones. Some file systems deal with this by having two different block sizes, the smaller one used for frags, but even so, the bigger the big block size, the more you lose.
However, I'd expect Apple to do a better job of tuning their file systems to the media type than Windows does.

I WANT MY LIFE BACK REMOVE THIS FROM /.

[Anonymous Coward]

I RTFA and at the END realized the IDIOTS had done a ZERO-FILL of the SSD (so clean tests on a DIRTY drive), then read through two pages of comments and saw many others who realized it too. Please pull this fkng waste of time off /. Too late to get my time back but maybe help someone else.

Re:Traditional denial

[kangsterizer]

1 phone is not some phones.. it's 1 phone and it's been critized as well when it was released.. The iphone4 has 24db loss.
This is considerable :p

Every 3db you double the range. 24/3 = lose 8x range. 18/3 = 6x range

So, unless you're right next to the antenna you actually don't get a signal at all, that's why so many are affected!

Think about it:

When you have the best reception, you are at around -50dbm.

When you are at the worse reception you are at around -110dbm (which is pretty good reception capabilities by the way)

when you remove 24db that's between 1/3 and half of the phone possibilities (which is more than half the range of course, as said higher)

Still sounds little to you?

Let's make a small example that looks a little more shocking maybe. The base number is random, I do get signal over 15km with some phones and towers, it depends on the area and the tower's power, and the phone sensitivity, but it gives an idea. Inside cities, the range is much less so the impact is bigger.

iPhone "holding it wrong": 500m range
Nexus 1 "holding it wrong": 666m (ops, the beast)
iPhone "holding it right": 4km

Re:cheese penis

[BigSes]

Why would anyone post something so awesome as AC?

Re:Traditional denial

[Jane Q. Public]

1 phone is not some phones.. it's 1 phone and it's been critized as well when it was released.. The iphone4 has 24db loss. This is considerable :p

You are generalizing too much. They also listed other phones that lose considerable signal depending on how you hold them. I just gave one example. It really isn't a unique problem to the iPhone.

Frankly, I'll take AnandTech's tests over your theory any day. Theory and practice should be the same... in theory. In practice, they rarely are.

-110dbm is pretty sensitive, I'll grant. But I did not say that 24db was little at all. Please do not put words in my mouth. I made two claims only: (1) that things were not quite the way most people thought they were, and (2) that 24db is not that much more than some other phones, like the Nexus.

Re:Traditional denial

[Jane Q. Public]

Correction: I did initially say "very small", and that is wrong. It isn't very small. But again, it isn't a great deal more than some other phones.

Re:Traditional denial

[kangsterizer]

Well you see I don't put words into your mouth :P
I know only of the Nexus one has other phone that really has a problem with this, other phones have a much lower attenuation.

All phones have the "issue" because it's how radio waves work, however, the iPhone 4 has a real design flaw. It's a shame, since the receiver is actually good otherwise.

My "theory" is not really one, it's just data you can lookup and actually agrees with Anandtech.

Simply, many people think it's really a software issue and 24db is not much, but it's huge, and Anandtech didn't really emphasize that in a clear manner (well, they're not flamebait like me haha)

  In my example @ 500m you would probably still see 5 bars on the iPhone while your range has been cut by 8x.

Since they are (24db) the measured db from Adnandtech, it's actually pretty precise and not much a of a theory vs practice thing.

Huh? What kind of "logic" is this??

[King_TJ]

You're saying the "Samsung SSD doesn't degrade because it's initial performance is already so terrible"?!

That makes no sense at all. Think about it. Even if the drive was slow enough. out of the box, that a read operation took 10 seconds to complete, that should result in it being more like 20 or 30 seconds when the drive is all fragmented up.

Unless a drive had 0 performance (never returned a result when you did a read or write), it should be possible to measure it degrading in performance from a clean setup and a fragmented one....

Re:Bad Summary

[femtoguy]

Clockwise in the northern hemisphere, and anti-clockwise in the sourthern hemisphere (or is that backwards, I can never remember).

aw come on...

[VanessaE]

A good joke all the way to the end, yet you missed a perfect opportunity to add an AYB reference, however old and dusty and outdated it might be.

A.D. 2101: War was beginning. Japanese-to-English translators found to be in particularly high demand.

Re:Bad Summary

[anton_kg]

The should use ATA7 secure delete command instead, to flash the entire SSD (physicaly) to the initial value https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

Re:Bad Summary

[anton_kg]

This procedure describes how to use the hdparm command to issue a Secure Erase ATA instruction to a target storage device. When a Secure Erase is issued against a SSD drive all its cells will be marked as empty, restoring it to factory default write performance.

zhangyuyu

[zhangyuyu]

http://www.gucciusaoutlet.net/index.php?main_page=index&cPath=75&zenid=aa7cf3c1c03ba16b9ac00c8cd2a23ef2