Slashdot Mirror
Mass Storage Leaves Microchips in the Dust
Roland Piquepaille writes "This article from Wired Magazine looks at storage with a new angle. 'Right now I am sitting in front of a whirring 60-gigabyte hard disk that cost less than $100. Do the math: If back then 10 megabytes cost $1,000, then 60 gigabytes would have cost x, where x = $6,000,000 and "back then" = 18 years ago. I'm sitting in front of $6,000,000 worth of mass storage, measured at mid-1980s prices. We have Moore's law for microprocessors. But who's coined a law for hard disks? In mass storage we have seen a 60,000-fold fall in price -- more than a dozen times the force of Moore's law.' DeLong also looks at a non-distant future when a $100 mass storage device will hold a full terabyte. He also thinks that with disk space becoming cheaper and cheaper, we'll be tempted to archive everything about ourselves, including pictures and videos. This is in fact the goal of the Gordon's Bell project, MyLifeBits. You can learn more about the MyLifeBits project by reading this NewsFactor Network article. Check this column for more details."
Moore's law says nothing about price though. If you are going to compare hard disks to processors in the same general terms using Moore's law, shouldn't you compare increase in storage size to increase in processing power?
"I turn away with fright and horror from the lamentable evil of functions which do not have derivatives."
looked at another way, hard drive capacities have just been doubling faster than processor speeds.
If 10MB back then cost $1k then 1MB cost $100, so we just do the 60G/1M and get a 60,000 time increase in storage capacity for the same price. Doubling times would then be log(2)60k = 15.9 or so, or about once every 1.1 years over 18 years. Contrast this with moore's law which states that processor speeds double every 1.5 years.
The downside is that access times have tracked closer to a linear function.
By "process it all", he probably means being able to address the area on the disk (think extremes).
By go over into negative integers, integers are an allocated space in memory that holds a number...if the number is bigger than the allocated space, what does it do!? 11111111 + 1 = 00000000 (keeping 8 bits of data). Look up signed integers. Since it's just binary...how can you represent a negative number? Well, you can't directly, you do it with little tricks that everyone agrees on. Look it up...you obviously need to.
Dude, seriously, what the fuck are you talking about?
Seriously, dude, it might be nice to know what your talking about and speak English, instead of using phrases like "to clown on you".
Your cpu doesn't "process it all" now. If talks with what it needs do.
But the more and more data you have, the more likely you are to try and handle large quantities. Search every text file on your system, or merely scan and process a file at 600 DPI instead of 300.
I'm also pretty damn confused as to what you mean by negative integers? Hopefully that was some weak attempt at a buffer-overflow joke or a stack dump or something because the logical part of my brain
The logical part of your brain obviously never studied computers very much. In assembly, if you continue adding to a signed integer value, it will overflow to negative. In 16 bits, 32767 + 1 = -32768, IIRC. If you program in C or Fortran or any other language that doesn't check overflow, the same thing will happen. I've seen reports that I had transfered -2 GB this session, because the program overflowed at 4 GB. Same principle.
Why is it that everybody continues to equate [M|G]Hz with CPU speed? It's only a component. Those old 4.77Mhz boxes took several Hz to complete a single instruction. A modern Intel or AMD chip runs several instructions per cycle. So therefore, a current top of the line system actually runs 3-5 thousand times faster than the original PC/XT. (But it still takes a couple to 3 minutes or so to boot up.)
You've got some problems with your facts. But, since you're playing the math games that I like to play, I'll cut you some slack. And then I'll expound.
First off, disk access time is dominated by actuator movement (seek time). Rotational latency on a 15,000rpm disk is 2ms, not 4. The fastest 15K drives have 3.5-4ms seek time. Slower drives have slower actuators, meaning the ratio of seek time to rotational latency is about the same, 2:1.
Seek time on large drives is of no importance. Seek time on small drives is of supreme importance. Small drives should be used to store the OS, applications, and small data files. Rapid access to disparate regions of the disk is important since these drives are primarily limited by IO/sec. Large drives are used for mass data storage. Large data storage (media, in my case) is dominated naturally enough by large files whereas applications and user data tend to be tiny. My media drive, for example has about 11,000 files in 95GB, or about 110 seeks/GB. My OS/apps drive, on the other hand, has over 89,000 files in 5.75GB, or 16000 seeks/GB.
Consider that a high-end drive can handle perhaps 600 IO/sec, and a large IDE drive can handle perhaps 150. Clearly then we have a problem: usage patterns differing by 150:1 in terms of number of seeks are not matched well to drives differing by 4:1 in seek performance. As you've demonstrated, physics cannot allow us to increase SCSI's seek performance to 150X that of bulk IDE drives.
The only way to achieve that sort of performance is with solid state storage. RAM costs about $150/GB - let's see someone mass-produce consumer-grade SSDs. Call it the "drive accelerator" and build it into a removable HDD bay. I guarantee that 1GB of RAM caching the most-used files on a hard drive would see performance skyrocket. Sure, it would be expensive, but it would be cheaper than the 15k SCSI boot disk I have, and a whole lot faster.
High-speed Road Trip (18.000KPH)