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."
Good lord! Are you serious??? You obviously never had to use debug to partition an esdi drive. You obviously have somehow missed the whole transition from 10Mb burst to 160Mb burst we've seen in the last few years. Scsi has, as well, gone from 8-bit with 5Mb transfer (scsi1) to 10Mb transfer @ 8bit or 20Mb transfer @ 16bit (scsi2), 40Mb transfer @ 16bit wide (scsi3) and now 80Mb transfer @ 16bit wide with ultra2. And while that's just what the *bus* can handle, I can promise you that the disks of today are far faster than the disks of even just a year ago.
Ask yourself...what restricts data fransfer speed? Several things, really. Density is actually a factor, as its an engineerign feat to get the disks spinning fast, so the more bits go past the heads during a given time, the more can be put on/pulled off. Also, the ability to process that data, which - guess what, has significantly increased. Then there's the length of time a head needs to spend to actually get a bit to seat at a N/S, 0/1 - materials platters are made of are constantly being improved, so that's far better. Then theres the mamangement of the data itself, algorythms for where to write what, etc. Again, substantially improving, constantly. And all I've discussed was scsi - ide has improved (has quantity on its side) far more than scsi has the last few years, too.
How in the WORLD could you say hard disks haven't gotten faster? Oh wait, I know how...because you are either being sarcastic, you're insane, or you simply have no idea what you're talking about. Did you just start using computers last week?
Consider the IBM XT 4.77MHz with a factory default formatted 17 sector per track MFM hard drive with a 6:1 interleave. The peak throughput of this machine was roughly 87 kilobytes per second.
... 3.06GHz, maybe a touch faster?
Now consider the new SATA machines with measured (not calculated) throughputs of 87 megabytes per second.
This is a 1,000x fold increase. For CPU processer throughput (speed) to keep up with this performance at the same rate, you would be able to buy a machine with a 4.77GHz CPU in it. Right now the fastest stock boxes are running what
CPUs have gotten faster. Hard drives have gotten faster faster.
Glonoinha the MebiByte Slayer
While it's nice that you took the time to rant about how much better of a programmer that you are then everyone else (the whole "If I didn't code it, it's crap" attitude really shines through), I think your scale is a bit off.
Lets say a library saves you a week. Now, lets say that like more people you use at least 4 libraries. Now, you've saved a month. A *month*, at which point you say you'll start to "consider" using external libraries. Well, I'm underpaid, but lets say you hired me to do this. By shaving a month off, you've saved over $3500 in my salary alone. And that's assuming that I (or anyone) could fully implement, *debug*, and "finish", a given complicated lib in 1 week. Great! Now, I quit, because I'm underpaid, and my replacement comes in. Now, I write good, well documented stuff, but it's not industry standard. So my replacement can't just sit down and pick up where I left off, but has to learn how *I* decided to implement libfoo. But it turns out that he's a lot like you, and thus 'he didn't write it, so it's crap'. And then *he* spends a month throwing away my stuff, and redoing it all. And on, and on, and on. There's a *reason* that things like Boost and Roguewave and Qt and Gtk and glib exist. And until you figure that out, you're doomed to be 1/10th as productive as you could be. Or, assuming that (as you claim) you've polished your libs to perfection and the productivity is there, I pity whomever has to take over your code. No, actually, I just pity you.
In general the problem is that while capacities have lept up, the rate at which we can read/write to those drives has not kept pace.
No, not really. The sustained transfer rate of HDDs has been steadily improving. It's obvious if you think about it. The drive stays the same size. The density goes up. The disc spins at the same rate or faster. Therefore, more data goes by the heads per unit time. This means trasfer rate will also increase. Specifically, this means that the transfer rate will scale linearly with the density of the disk.
What hasn't improved at the same rate as density is seek times. Seek times have always been the killer for mechanical storage mechanisms. They have to move something around and they have to obey Newton's laws.
In order for seek times to improve at the same rate as the rest of the drive impoves, we would need improvements in materials science and motor design which far exceeded those that increased density.
The other neat thing to think about is the spinning discs inside the HDD. Both those impovements I just mentioned might also allow you to spin the platters faster. This means that you could actually increase the transfer rate of your drive as well.
The immediate problem I can see is that moving something back and forth doesn't scale as nicely as storage density. Here's an example:
Say you've got something that you need to get from point A to B. Say you can do it in 1 microsecond. If you want to be able to do it in 1/2 microsecond, you need 4x more force. This means you need a motor with 4x more force, and a material that's 4x stiffer and 4x stronger.
Even if materials science, and motor designs were improving at a rate comparable to "Moore's Law", seek times wouldn't. Some things just don't scale the way we would like them to. Batteries are a good example.
Correction: You need a material that has 4x better strength to weight and stiffness to weight ratios.
It's also worth considering that you have to burn 4x more energy to move something from A to B twice as fast. Power dissipation in CPUs scales linearly with clock speed.
Life is too short to proofread.