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."
Just imagine the power savings as well. Also, they should last an order of a magnitude longer than media that needs to spin all the time.
As soon as these get cheaper and have more capacity, spinning media is dead.
the transfer speed they tout is probably the peak transfer speed. But the time it takes to launch a program also depends on factors besides the transfer speed. Like seek time for example.
Hard disks have to position the heads at the right sector before starting a read. Maybe these SSDs don't have a solid state analog to that activity and are thus faster by however long that takes.
I don't know the specifics, but I'd guess that comparing overall program access and launch time to peak transfer speed is apples and oranges.
This is somethat that a lot of people tend to overlook, either because they don't understand how a hard drive works, or because they don't stop and think about it. Loading programmes, especially ones which rely on libraries, translation files, multimedia, etc... at other locations on a disk would greatly slow down a HDD in comparison to an SSD.
Contrasted with SSDs, which are pretty much random access devices, in order to read each of those files from an HDD, there are basically 3 time factors to consider.
1. Seek time. The time it takes to move a reader head to a specific track (ring of data on a platter). Assuming that there is only this read taking place, you can pretty much assume that the reader head moves from its current location to the correct spot on the disk right away. Things are not always this pretty, though.
2. Rotation time. On average, you will have to wait half a rotation for the correct spot on the disk to spin around to the reader heads. There may be algorithms designed to mitigate this by reading even as it waits. In case the read is large enough to span a significant portion of the track, it can append that buffered data later, but I don't know if this is done or not.
3. Read time. This is the amount of time required to read the data off of a single track, and can take up to 1 rotation of the platter to complete.
So while the GP has a point in that people need to be careful about what kinds of statistics they believe, he/she glosses over the fact that reading a single piece of data with an HDD is hardly a random access, constant time operation (or linear time for n pieces of data).
Disk I/O is the one area I still have an easy time slamming modern computers on. Most others, it isn't too expensive for me to simply get enough power that handles what I want in realtime without slowdown. Multiple VM, no problem quad cores are cheap. Big audio projects? Hell I can get 4GB of RAM for less than a month's Internet access... However when those projects start hitting the disk, I start having problems, even with a RAID array. The sequential stuff isn't it, it's the random access that kills it.
Audio only takes 172Kbytes per second per track (for 32-bit floating point). So you figure that doing something with, say, 64 tracks isn't a big deal right? Only about 11Mbytes/sec, way under what a single disk can take. However you can find that it'll choke. Reason being is that the audio isn't all nice and sequential. It's written to disk as 32 separate stereo audio files. Also you maybe have some of them reading, some of them writing and so on. The disk gets overloaded trying to seek to the information in time.
VMs are the same thing. Two VMs running computations at the same time on a system works at full speed. They each use a core of the CPU, there's no problem. The do contend for memory bandwidth, but that is plenty high enough. Likewise one VM doing disk access happens at near native speeds. There's not a lot of overhead to read and write to the disk. However get two VMs doing disk access, man things grind to a halt. Your drive is dancing all over trying to service the simultaneous requests from different areas so throughput grinds to a halt.
An SSD would just be amazing for apps like this. Not because it has so much more bandwidth, but because it's bandwidth stays much higher under intense random access. Where a harddrive might obtain 50MB/sec in sequential read, the same drive might struggle to pull even 5MB/sec in random reads. For the SSD it might be more along the lines of 200MB/sec for sequential and 180MB/sec for random. Even though it isn't full speed, it's close enough as no odds. With that, the VM and audio work would have no throughput problems.