Slashdot Mirror
Intel Plans 'Overclocking' Capability On SSDs
Lucas123 writes "Anticipating it will make a 'big splash,' Intel is planning to release an product late this year or very early next that will allow users to 'overclock' solid-state drives. The overclocking capability is expected to allow users to tweak the percentage of an SSD's capacity that's used for data compression. At its Intel Developers Forum next month in San Francisco, Intel has scheduled an information session on overclocking SSDs. The IDF session is aimed at system manufacturers and developers as well as do-it-yourself enthusiasts, such as gamers. 'We've debated how people would use it. I think the cool factor is somewhat high on this, but we don't see it changing the macro-level environment. But, as far as being a trendsetter, it has potential,' said Intel spokesman Alan Frost. Michael Yang, a principal analyst with IHS Research, said the product Intel plans to release could be the next evolution of SandForce controller, 'user definable and [with the] ability to allocate specified size on the SSD. Interesting, but we will have to see how much performance and capacity [it has] over existing solutions,' Yang said in an email reply to Computerworld."
Time to make some watercooling blocks and special fans and make money from those with too much.
So, what Intel are saying, is that they are going to take a SSD controller with unstable, buggy firmware - and then add a feature that allows users to modify the internal constants the firmware uses to do it's job. This can only end very badly, unless Intel and Sandforce do some serious testing to find and fix the data corruption issues, the problems with the drive ignoring the host, and the problems where the drive gets stuck in busy.
(all problems detailed in this post have been experienced with an Intel branded, Sandforce controller-ed drive)
Translation: :D"
"It's useless, but idiot gamers will buy anything if we call it over clocked
...since Intel is the historical enemy of overclocking. In their view if you get more performance than you paid for you are stealing from them, even though you are modifying a piece of hardware that you own. I suppose Intel's overclockable SSD will be an 'extreme edition' version that costs several hundred dollars more than an equivalent device that is rigged with extra DRM to forbid overclocking.
BSOD
If you are lucky. A silent killer of data, sneaking around like Jack the Ripper, never known by name, only by result.
Intel
Nuf said
I guess the word "Turbo" is out of favor these days.
Time for Seagate to make some real hard drives that spin at 20000 RPM
Why even mention the word overclocking? How does that make any sense? Marketing trying to market with senseless words again.
Over-provisioning already exists on a ton of different SSDs like Samsung and OCZ. Intel didn't invent anything new and the controller's MHz isn't going anywhere, nor would that be a good idea anyway. One flaw in the data and it's goodbye boot drive data integrity. What a useless "catching up" announcement.
would I want to use compression at all, if my goal is speed? If maximizing total capacity is not the concern, I would use none of the drive for compression. I think the point to be taken from this is that Intel is recognizing that storage capacities for SSDs are reaching the point where compression is no longer necessary to make the technology a viable alternative to mechanical drives, and we will now begin seeing the true speed potential of the technology.
It's the ancient tradeoff of CPU vs. IO. When you have more of one than you need, burn it to improve the other.
I want to delete my account but Slashdot doesn't allow it.
What could possibly go wrong?
"Overclocking" is technically a misnomer. It's a sort of tweaking, but it's a bit more than that; we could call it ... twerking!
Why would I want to tweak "how much data is used for compression"? If the drive compresses data internally, why not just do compression for all data?
And, all the consumer drives are bottlenecked by the SATA bus anyway.
"...gimmick?"
You are welcome on my lawn.
tl;dr Allow users to adjust the compressed vs. uncompressed section sizes. Compressed goes faster, but rewrites a lot more and thus wears it out faster.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
They're using "overclocking" here as a metaphor, but people seem to take it literally. Overclocking the drive would involve raising voltage and increasing clock speeds. That's probably possible. But what they're talking about appears to be to give the user the ability to influence the amount of overprovisioning on the drive. For an SSD, the physical capacity is larger than the logical capacity. This is important in order to decrease the amount of sector migration needed when looking for a block to erase. From zero, adding overprovisioning will substantially increase write performance, but at a diminishing rate as you add more extra space.
As for compression, it does two things. It allows more sectors to be consolidated into the same page, amplifying the very limited flash write bandwidth. And it effectively increases the amount of overprovisioning. These two mean that more compressible data will have substantially higher write performance and somewhat higher read performance. (Although reads are already fast enough, on many drives, to max out the SATA bandwidth.)
Anyhow, giving the user the ability to tweak overprovisioning seems pretty worthless to me. At best, some users will be able to increase the logical capacity, at the expense of having lousy write performance. Maybe this would help for drives where you store large amounts of media that you write once and read a lot. But how much more capacity could you get? 25%? Another knob might be compression "effort", which trades off compute time against SSD bandwidth. There's going to be a balancing point between the two, and that probably should be dynamic in the controller, not tweaked by users who don't know the internal architecture of the drive. Some writes will take longer than others due to wear leveling, migration, and garbage collection, giving the drive controller more or less free time to spend on compressing data.
I want my SSD running smooth, with a capital smoo.
After you deal with HD & SSD failures, you are only concerned with reliability.
Considering SandForce sells controllers to multiple vendors isn't the only difference between them how they choose to provision the drives. I know there can be hardware differences, but lets say we have two drives with basically the same internals. Lets also suppose that Drive X is faster than Intel's equivalent, but Intel's is cheaper (not likely but stay with me here). Now you may be able to tweak the Intel drive's settings and get it to match or closely match Drive X for cheaper. That could be a good use.
Or you want to use the consumer level drive in a small business. You don't want to spend the money on the enterprise level drive so you take this new drive, reserve more space for failure (such as dropping the 250GB down to 220GB or something) and continue on.
Overall I agree that this won't be much use to most people but it does have potential for the unusual cases.
It is not an overclock but the ability to adjust the "spare area". This is the percentage of flash on the drive that is not exposed to the user and is used for garbage collection, write acceleration (by having pre-erased blocks), reduction of write amplification, etc. You can emulate more spare area on drives already if you take SSD and format it to less that it's full capacity.
This is the SSD equivalent to short stroking a hard drive.
It's worth noting that the higher performance and enterprise level drives already have much more spare area but that results in a tradeoff of capacity for performance. They are just going to let you set this slider between consumer level (maximum capacity per $$$) and performance level (higher performance but less capcity).
They're using "overclocking" here as a metaphor, but people seem to take it literally.
Because it is a specific technical term that shouldn't be misappropriated for something completely unrelated. This foolishness is what happens when the marketing department steers the ship. Something Intel should have learned their lesson on with the MHz wars and the P4.
Then again maybe I've just been ahead of the curve all these years when I "overclock" a new ext[2-4] partition with the minimum superuser reserved space. I've also taken a liking to "overclocking" my tarballs by switching from gzip to bzip2.
I am becoming gerund, destroyer of verbs.
You seem to be using HDD terminology in SSDs, when the analogies simply don't hold good. The terms 'sectors' or 'blocks', which mean different things in HDDs, are almost synonymous in SSDs. Essentially, they mean the minumum erasable areas that one can erase before one can write to one or more locations within that area. There is no concept of 'sectors within the same page' or anything like it. If the flash device in question supports page mode reading or programming, it simply defines the area that can be written in a single operation.
I've always assumed that the biggest performance problem now is that we quickly maxed out the SATA 6GB/s standard.
It seems like overclocking is just tinkering at the margins, and that a more complete solution is either another rev. of the SATA standard, or else go with PCIe.
Its just unlocking more of the safety margin for general use. Either way, an OC'd CPU might fall over and you lose an online game - a FUBAR'd overclocked SSD could result in bye bye all your data.
wrong.
sector: smallest addressable unit of space
in hdd this is the same for reads and writes. for ssd its the smallest adressanle unit but....
blocks: no such concept with hdd. traditionally there were cylinders, heads and sectors (addressing scheme) and some folks may have used block to refer to a sector, but normally in data storage a block is the smallest addressable unit in a file system, sometimes called a cluster.
for ssd its different: it can only write either ones or zeros, not both. by definition, a sector is the smallest addressable unit on the drive: so whatever the smallest data unit that can be written at a time is, is a sector. This can be complicated (as it is for high capacity hdd) by the drive lying about its sector size. but wiping is done in groups of pages -- all at once, all data in that "block" is wiped out. Confusingly, called a "block" which is also a term from file systems, joy.
in short, you are backwards and confused. sector/block are *not* "amost synomymous in SSDs". If you take the SSD "block" (smallest unit that can be erased) and note that, for a spinning platter drive, sector and *this* notion of a "block" are synomymous then you realize that the aboev statement was reversed. Writing for SSDs is much more complicated than for spinning platter due to the separation of writing ones and zeros, the consequent requirement for over capacity, and the wear that comes from writing to an SSD (whereas frequent writing to a spinning platter drive keeps it "refreshed").
They have somewhat compensated for that by improving the compression ratio from a factor 2 to a factor 2.5. I have no idea what that number is supposed to mean though
I'd imagine it compares to the upgrade from DEFLATE (used in PKZIP and Gzip) to LZMA (used in 7-Zip). As I understand the claim being made, the original algorithm compressed a representative corpus of data to 50% of its original size and the new algorithm 40%.
In SSD's - which ultimately boils down to the NAND flash, there is no such thing as 'sectors' the way you defined it above. The smallest addressable unit there is a word, if one is talking about reads. If one is talking about programming, one can program a page, which is smaller than a block. Also, NAND flash has to be erased first (set to all '1's) before any area of it can be programmed. The only type of flash where one can write either '0's or '1's is the EEPROMs (or E-square), but those things are of the order of less than 1kbit, not the GB or TB that people are thinking of here.
Writing for SSDs ain't complicated on its own - one can easily just write to wherever the assigned addresses are. It's just that since the endurance of a flash - the number of times a block can be erased - is 10k cycles or less for each block - it is undesirable to discard a flash where a few blocks have been repeatedly written to, while some other blocks may be totally unused - one would then end up having to discard a flash that still has some perfectly good areas. To avoid that, you have memory management routines that would try and use different areas of the flash and even out the usage, so that the lifetime of the flash can be maximized. But that seems different from doing compression, and using compression techniques to alter write performance. Write performance is a silicon level issue and would have to be fixed at that end - the SSD can't give a performance higher than that, regardless of whether compression is used or not.
Filesystems & datastructures (vectors vs. pointer-based structures like linked-lists) that promote contiguous memory *might* help - since the need for "circular disk" patterning isn't required on SSD! Eliminating it would help imo.
* Think about it!
Compression helps me 4 HOW I use ramdisks/ramdrives (detailed below) in hardware - especially for browser caches, logging, print spooling, & temp ops!
(E.G./I.E.-> I 1st did the list below on multiple HDD's to distribute workloads & then software based ramdisks carving system RAM out to do so, but then going "dedicated hardware RAM" instead as shown below)
I found I can "pack more" into the areas on disk structures per (insert measurement here) for faster pickup on loads after seek/access/read cycles from disk.
The compression stage is offset by today's FAST cpus too! The gain, is there, despite the small "hit" in that stage.
I went "True SSD's" for decade++ now though:
Cenatek "RocketDrive" PCI bus, 4gb PC-133 SDRAM circa 2000-2007 iirc, & currently a Gigabyte IRAM PCI-Express bus, 4gb DDR-2 RAM 2008 to present (BOTH can be spanned/striped into a single 16gb unit).
Both = CONSISTENTLY excellent 4 BOTH read + WRITE speeds (flash wasn't so great on write especially for years so I stuck by using these with std. HDD's in the following ways to offload their workloads, effectively speeding them up by making them work less)!
Only reason I haven't done the SAME with Flash RAM based SSD? Concerned about longevity mainly (not proven in REAL YEARS out there still imo is all):
I move this off my WD Velociraptor sata II 10,000 rpm 16mb buffered harddisks driven off a Promise Ex-8350 128mb ECC ram caching raid sata 1/2 controller (which defers/delays writes via said cache, & also lessens physical head movement on disks & this is where I am going to make it even faster via lessening its workloads, read on & reduces fragmentation as well in the same stroke - "bonus") onto my 4gb DDR2 Gigabyte IRAM PCIExpress ramdisk card:
---
A.) Pagefile.sys (partition #1 1gb size, rest is on 3gb partition next - this I didn't do on software ramdrives though)
B.) OS & App level logging (EventLogs + App Logging)
C.) WebBrowser caches, histories, sessions & browsers too
D.) Print Spooling
E.) %Temp% ops (OS & user level temp ops environmental variable values alterations)
F.) %Tmp% ops (OS & user level temp ops environmental variable values alterations)
G.) %Comspec% (command interpreter location, cmd.exe in this case, & in DOS/Win9x years before, command.com also)
H.) Lastly - I also place my custom hosts file onto it, via redirecting where it's referenced by the OS, here in the registry (for performance AND security):
HKLM\system\CurrentControlSet\services\Tcpip\Parameters
(Specifically altering the "DataBasePath" parameter there which also acts more-or-less, like a *NIX shadow password system also!)
* All of which lessen the amount of work my "main" OS & programs slower mechanical hard disks have to do, "speeding them up" by lessening their workload, fragmentation, and speeding up access/seek latency for the things in the list above too.
---
Thus - HDD's concentrate on program &/or data fetches that are still hdd bound (& not kernelmode diskcaching subsystem cached in 4gb of DDR3 system ram here either yet) done on a media that has no heads to move, & thus, more mechanical latency + slower seek/access as you get on hard disks + reduced filesystem fragmentations due to that all, also & it works!
Since 1992 or so I've done the above for performance & efficiency (boosting HDD slower speeds). Again - 1st using separate HDDs (slower seek/access by FAR) & then using software ramdisks per the list above (on a MS-DDK based one I wrote in fact, on how I apply them), even later by applying Software-Based Ramdrives to database work with EEC Systems/SuperSpeed.com on paid contract (which did me VERY WELL
The smallest of those problems is the question about who decides what is a representative corpus.
Wikipedia's article about LTO claims that the algorithm is based on Hifn's LZS, and benchmarks are relative to the Calgary corpus.
An example of something which is clearly cheating would be to define the compression such that if the input is identical to the benchmark corpus, then the compressed output is simply a single zero bit.
This would require the compressor and decompressor to contain an exact copy of the benchmark corpus, which would likely result in copyright problems.
In certain scenarios you would get around that sort of "cheating" by measuring not just the size of the compressed data but also the size of the decompression code. That however requires somebody to specify on what platform the code will have to run.
I assume it would run on whatever platform the drive's microcontroller uses, and compression on an MCU might not favor use of a multimegabyte corpus. But I see your point that more transparency in this benchmarking would be good for consumers.
6 core overclocked CPU, high end viedo card, 3 hard drives ( 2 are 10,000 rpm ), and an ssd here, and not seen the system pull more than 250 watts yet ( on a 550 PSU ). You don't need no 750 watt PSU unless you are nuts enough to run 3 GPUs.
Oversized PSUs do waste more power as the efficiency drops off as you get close to the maxium, or below about 40%, so getting an oversized PSU that you typically run under 40% does waste more power.
They already do work that way. That's why a drive with 3 platters gives 50% more sequential throughput than one with only two.
Take any drive, leave some space unpartitioned at the end, and congradulations, you have overprovisioned the drive. Don't need fancy firmware or tools to overprovision.
Not to mention that unless you aren't using TRIM or try to fill it up to 100%, overprovisioning serves no purpose.