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."
No only the price, the size of the drives. 18 years ago a 40 Mb HD has the size of a toaster...
The package said "Windows XP or better. Pentium Class Processor or better"... So I got a Mac with OS X
Moores Law for Microchips
(doubles every 18 mnths)
Porns Law For Storage?
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?
The one limited is network speed. Sure, if I've got enough room for a collection of 2 gigabyte raw avi movies, that's great. But if I can't get enough speed to download them quickly it will suck.
This has always bugged me... back in 1992, I had a 25MHz CPU, 8MB of RAM, a 660MB hard drive, 2.88MB floppies, and a 28.8 modem.
In 2003, I have a 2.2HGz CPU (88 times faster), 1024MB of RAM (128 times more), a 120GB hard drive (180 times more), 700MB CD-RWs (243 times bigger) yet only a 1Mbit (on a really good day!) network connection (about 35 times faster, no matter what the cable company claims.) And that's as fast as it has been for about 5 years now.
Where oh were is my 5Mbit cable modem? Heck, some poor bastards are still stuck using 56k modems...
It seems that network connections ony get faster in big bursts. In 1997, I had a 56k modem. In 1998, I had a 1Mbit DSL line. Maybe in 2008, I'll get fibre to my house.
"Tomorrow's forecast: a few sprinkles of genius with a chance of doom!" - Stewie Griffin
Drives today have 10.000 rpm or 15.000 rpm. Eight years ago the high end was 7200 rpm, 5400 before that...
;)
That's approximately a 2X performance increase per EIGHT YEARS. This is very very far from being impressive.
Disk seek time is dominated (today) by rotational latency. The fastest disks have seek times around 4ms, and that is pretty much the rotational latency on a 15000 rpm disk.
In order to improve disk performance (the seek time, not the throughput), disks need to spin faster. This does pose some interesting problems though...
A normal 3.5" drive has a platter with approximately 48mm radius, giving roughly 0.3 meter circumference. At 15000rpm the speed of the circumference is 75.4m/s.
Doing the math, this gives us a centripetal acceleration of v^2/r = 118435 m/s^2, or roughly 12085G. Sure as hell beats most drag racers out there (by more than a factor of 12000
The fun part is, that a simple doubling of the rotational speed, will do really interesting things to the acceleration (note the v^2 thing above).
A 30000rpm disk will have a centripetal acceleration of the circumference of approximately 48000G.
A mass-element at the circumference weighing one gram, will have a "pull" corresponding to (F=m*a) 118kg - which again will be approximately half a tonne on the 30000rpm disk.
You need to find a material that will weigh little, not deform under the given stress, and still have the necessary properties for use as a hard drive platter...
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.