Slashdot Mirror
Samsung Mass Produces Fast 256GB SSDs
Lucas123 writes "Samsung said it's now mass producing a 256GB solid state disk that it says has sequential read/write rates of 220MB/sec and 200/MBsec, respectively. Samsung said it focused on narrowing the disparity of read/write rates on its SSD drive with this model by interleaving NAND flash chips using eight channels, the same way Intel boosts its X25 SSD. The drive doubles the performance of Samsung's previous 64GB and 128GB SSDs. 'The 256GB SSD launches applications 10 times faster than the fastest 7200rpm notebook HDD,' Samsung said in a statement."
So it launches applications 10 times faster [sic] (should say in 1/10 the amount of time), but the article only claims speed improvements of about 3.5 to 1. People need to seriously examine how they quote or accept statistics.
Jim Elliott, vice president of memory marketing at Samsung, said the new 256GB drive can store 25 high-definition movies taking up 10GB of space each in just 21 minutes, which he said is a significant advancement over a 7200rpm hard disk drive, which takes about 70 minutes.
Ah yes, but you don't have the seek times of the 7200rpm drive which are at best ~7ms. And since opening an application involves opening lots of different files (in different physical locations on the drive), this is where launching an app can be 10x faster.
So for straight writing a single, large, contiguous piece of data, it's only 3.5 times faster. For loading 200 random, tiny files, it's ten times faster.
Me neither. We spent weeks (which translates to tens of thousands of dollars) benchmarking and optimizing a database app. The thought of accelerating it by a factor of 5-10x with a simple hardware upgrade is stunning.
1 TB of SSD today = 17 * $150 = $2,550.
1 TB conventional storage = $95.
SSDs are still over 25 times as expensive. They will improve quickly, but they need to hit a moving target to kill conventional drives.
You can get 16GB SDHC cards for about 30 USD. Those are class 6, which means you get anything from about 8MB/s to 20MB/s depending on the brand. Of course, if you want more speed, you can always use RAID0.
In fact, given how cheap they are, a RAID5 system would probably make sense. You get a speed boost, and the ability to hot swap a single card if it goes bad. ZFS would also work really well, but I don't know if you'd get a speed boost that way. Also, all these approaches would allow you to very easily extend your system by buying another card (and reader) and adding it to the pool. (You may want to check up on whether you can remove it again later, though.)
Hmm. Thanks for prompting me to go and look at this stuff. I might actually do this for my next lightweight server.
Giga is an SI prefix. It is defined as 10^9 and abbreviated as a capital G. So to say you have 200G of something implies you have 200,000,000,000 of them.
Computers do it wrong. When computers say Giga they mean 2^30, not 10^9. That's wrong, for that you use IEC prefix of gibi, abbreviated as Gi.
The reason is that back in the day, computers had little memory. Thousands of bytes was all. So when talking about thousands of bytes, programmers started calling them "kilobytes". After all, it is close. 2^10 is close to 10^3, only 2.4% error. Well memory kept growing, and the incorrect prefix usage kept going on and they kept using bigger ones.
However this has two problems:
1) The error grows. At the giga level it is about 7% off. The large you are talking about, the more the difference between the base 10 prefix and it's "closest" base-2 amount.
2) You get confusion between levels. For example suppose your computer shows you something in megabytes. It says you have a file that is 2000 megabytes. Well that's 2 gigabytes right? Wrong, 2 gigabytes is 2048 megabytes. So it is rather unintuitive to humans. We work in base 10, the numbers displayed are base 10, but the prefixes are used wrong.
Really, the harddrive makers are right. Computers should display amounts according to the base 10 prefixes. Computers have no problems with base conversions, they should be doing that for people.
One problem is they write in blocks (128kb?) and the entire block needs to be erased to modify a single byte.
That chews those writes faster than you'd expect, and write leveling can only do so much especially if the drive is mostly full.
No, you wouldn't necessarily expect to be able to load 3000 tons. Firstly, what type of tonnage are you talking about? In shipping, there are several different types of tonnage, or in other words, different values for the same thing, with at best slightly different names. For example, Gross Register Tonnage, Net Tonnage, Gross Tonnage, Thames tonnage, Panama Canal tonnage, Net Register Tonnage, and who knows what else.
Secondly, suppose a ship has a "capacity of 3000 tons". Could you fit more pillows or gold bars into the ship? Which one will fill the hold first? Can you fit 3000 tons of pillows into a ship with a capacity of 3000 tons? Can you fit 3000 tons of helium in? 3000 tons of depleted uranium? What if the ship is to be sailed from a salt water port into a freshwater lake? Does that affect anything?
Why would you pick tonnage of shipping as an example of regular math? Shipping measurements are all over the place. For example, how long is a ship? Well it depends on the shape of the ship, and where you measure it. Length at the waterline or length overall? With the ship loaded or empty? Heeling or sitting level? Salt water or fresh?
Just about everything to do with computers is simpler and more regular than just about anything related to boating.
Reads are byte word size
The caveat is that it is necessary to erase the whole block to write a byte when a bit needs to be changed from its erase state. e.g. :
If the erase state is 0 and a bit needs to be cleared (it holds a 1 in or scenario, and we want it to be zero) then it is necessary to erase the whole block. This (obviously) means copying the block contents to RAM, zeroing the FLASH page in which the byte resides, and then writing the page back to FLASH. It sounds worse than it is, and ultimately the overhead doesn't put a dent in the difference between using spinning media and FLASH. For example, what is the overhead to change a single byte on a hard disk?
Update the metadata (itemization of steps not included; you get the idea.)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
SSDs do not allow you to directly read/write/erase flash memory. The firmware includes a flash translation layer that lets the host read/write 512 byte sectors just like any other drive. Sectors do *not* have a fixed location on the disk. Writing a sector simply appends it to the current erase block, and updates the translation table (also an append). When it runs out of blank blocks, it picks one to erase based on its wear leveling algorithm and garbage collection, and copies any live sectors to a fresh erase block. Just like a HDD, there are plenty of spare erase blocks, which are needed for the copying garbage collection and for when erase blocks go bad.
While the basic function of FTL is open, the wear leveling and garbage collection algorithms are fiercely proprietary. (The best ones actually count how many times a block has been erased and keep the counts even - and do this at high data rates.) This is OK for now because there is also fierce competition, and the code runs only in firmware on the device - not on the host. (Same as the controller code on a HDD.) Should the SSD market ever shake out into a monopoly, the basic FTL ideas are available.
I've found that for VMs it's best to short stroke the drive. Partition it so that your VMs are in the middle of the drive, all together, in a somewhat narrow section of the disk. That way, even while doing high IO/sec, you're at most half a disk seek from anything else on the disk. Also, always pre-allocate your VM disks; the performance difference is huge. If you're running a *nix distro, it pays to put your swap on one side of the VM partition and /var on the other, this way you shouldn't have to stray out of the center of the disk too much. The anticipatory IO scheduler in Linux helps a good deal here, you'll get much more throughput for a sub millisecond latency cost. With NCQ/NTQ, and only using 1/3 of the disk surface, you can feel the difference... especially as compared to a single partition that's running low on space and doing a full stroke to get from the VM to your OS.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.