By the way, if you want to think of it in terms of frequency of doubling, the numbers I gave correspond to DRAM doubling every 18.8 months, and disk doubling every 16.9 months. Again, this hardly justifies a claim of "a dozen times the force of Moore's law".
When comparing exponential growth over a twenty
year period, a linear factor of 12 hardly
qualifies as "leaving in the dust".
Making any claim about a linear factor such as 12x
beyond an already exponential rate over an 18-year period is just a ludicrous attempt at sensationalism. Were disk capacity expanding at a growth rate 12x that of DRAM for the last 18 years, we would now have disk drives that store roughly 10^30 bytes, rather than around 10^12 bytes.
In 1981, a state-of-the-art DRAM chip was 64 Kbit (2^16.00 bits), and a state-of-the-art 5.25-inch winchester hard drive was 5 Mbytes (2^25.25 bits). In 2003, a state of the art DRAM chip is 1 Gbit (2^30.00 bits), and a state-of-the -art 3.5-inch winchester hard drive is 250 Gbytes (2^40.86 bits). That's growth by a factor of 1.55 per year for DRAM, and a factor of 1.64 per year for disk.
Given only 22 years of historical data for comparison, I don't think one can really claim that the difference in growth rates is significant. It would be fair to simply say that both have grown by a factor of 1.6 per year.
As Kurzweil points out in his book
The Age of Spiritual Machines, even though Moore's Law was originally stated in terms of transistors, it actually extrapolates backward accurately for computing devices in general all the way back to the beginning of the 20th century (mechanical calculators), and there's no reason to believe that it won't similarly extend forward even when transistors eventually are replaced by a fundamentally different technology (for instance, nanoscale mechanical computing, or quantum electronics). Part of the rationale for making such a claim is that the same sort of power law has applied to many other technology areas. So it's not too surprising that disk storage density has grown exponentially.
Yeah, wow, 2x CD-ROMs were already around and MS came up with a new "standard" that said that they should run at 2x (later 4x). That's quite an innovation, and I really believe that vendors wouldn't have kept selling 2x and 4x CD-ROMs drives if MS hadn't introduced this standard. In fact, I'm sure the vendors would have decided that CD-ROMs were a bad idea and discontinued them entirely. So yes, let's give Microsoft all the credit for inventing CD-ROMs.
One thing I've never understood about Microsoft is its constant creation of new "architectures" for computing.
[...]
Is it some limitation of Wintel-compatible architecture
No, it's just so they can sell you warmed-over versions of the same old crap over and over. You wouldn't pay $200 to upgrade from Windows XP to Windows XP service pack 2, would you? But maybe you'd pay $200 to upgrade from Windows XP to "all-new" Windows Server 2003. So until they get customers to buy into the software rental model, they have to fake it if they want to keep charging you their annual software tax.
Previous deals with them produced both USB and cd-roms
Huh? Microsoft was not involved in the development of the CD-ROM standard (Yellow Book), nor did they do anything that was particularly necessary to making them popular. They eventually shipped MSCDEX for MS-DOS, but that wasn't until quite a while after CD-ROM support was available on the Apple II and Macintosh, and after third-party CD-ROM support for PCs was commonplace. If anything, they were late to the party, so I don't see how you can give them much credit.
And although MS was involved with USB, that was mainly developed by Intel.
Naturally any time some new kind of hardware comes around, its developers will ask MS to support it, but that's hardly reason to say that MS produced it.
And besides, someone will probably get Linux to work on this Athens thing anyways...
What makes you think that Athens won't require digitally signed software (TCPA/Palladium/whatever MS calls it this week)? Yes, people got Linux running on the Xbox, but only with a mod chip or by exploiting a bug in a specific game. I rather doubt that someone who buys an HP Athens computer is going to want to run Linux on it if that requires a hardware mod or running some lame game every time you want to boot.
I got up one morning, couldn't find my socks, so I called Information. She
said, "Hello, Information." I said, "I can't find my socks." She said,
"They're behind the couch." And they were!
There are two other possible explanations for why some code might be similar or identical:
Small chunks of code may result from multiple programmers solving the same problem. I've seen this firsthand, when a company accused me of stealing code from one of their embedded systems. I sent the company copies of the development snapshots of that piece of code from my open-source program, documenting its evolution, and the company was satisfied that I'd independently developed my code.
It's possible that the code was copied, but not by Linux. Can SCO prove that their developers weren't influenced by Linux code? Of course, if they can document when the code in question was written, it would be fairly easy to compare that to the Linux history, which is very well documented.
This seems quite reminiscent of the USL v. U.C. Regents case over the BSD release. USL maintained that the BSD code was tainted, but never cited any specific lines of code. USL decided to settle after the U.C. regents pointed out that USL was in violation of the license terms for the BSD code they were using in System V. At that point, USL probably realized that U.C. could force them to withdraw System V from the market and recall all existing copies in order to strip out the BSD code. Anyhow, as part of the settlement, CSRG did remove a few files that were said to be tainted, but since USL didn't indicate which files to remove, CSRG picked out a few of the files that were crufty and in need of replacement anyhow, and removed those.
Does anyone remember the letter that SCO sent out to customers back in the late 1990s, suggesting that customers would be better off with a professionally written and maintained operating system, rather than an amateur effort by a few hackers? It has a lot of other ridiculous comparisons like that. Someone (ESR?) wrote a parody letter refuting every one of their points.
I used to have the two letters posted outside my cube at a previous place of employment. I just tried to find them using Google, but I must not be using the right search terms.
what? The horizontal resolution is determined by a) the raster dimensions and b) whatever frequency space limiting was done in the encode stage. For non-interlaced content with no filtering, the addressable picture IS 720x480 (or 720x576).
No, that determines the number of horizontal pixels, but that is NOT what is measured by horizontal "lines of resolution". Reread my original posting. The measurement is deliberately made relative to picture height, not width, so that the horizontal and vertical resolution measurements are comparable.
No, only most video pixels are non-square. For example, 1080i HDTV at 16:9 aspect ratio has square pixels. Also, sometimes
NTSC video is sampled at only 640 pixels width in order to get square pixels.
Enjoy that while you can; the publishers are trying to come up with a Pay-per-Read system. Of course, those of us with any sense will refuse to buy such stuff, just as we refused to buy the original DivX.
When I first read Stallman's story
The Right to Read, I thought it was quite far-fetched, but considering events of the six years since it was published, it now seems like a legitimate concern.
1080i and 480i are measures of the vertical resolution of the signal. VHS is also 480i, though it isn't digital and the horizontal resolution is nowhere near as good as DVD.
Horizontal resolution is traditionally measured in lines per picture height (not width), so that the horizontal and vertical resolutions have the same scale. (Note that film resolution is normally measured in "line pairs", but video resolution is not.)
A DVD normally has 720 pixels horizontal by 480 vertical (interlaced). If it is mastered with Academy Ratio (4:3) video, that means it has 720 * 3/4 = 540 lines of horizontal resolution. By comparison, VHS has about 240 lines of horizontal resolution. Note that the horizontal resolution is different for anamorphic widescreen DVDs when played on suitable equipment, because of the different aspect ratio.
HDTV at 1080i has 1920 pixels horizontally, and 16:9 ratio, so it has 1920 * 9/16 = 1080 lines of horizontal resolution. Since the horizontal and vertical resolution are the same, the pixels are square, unlike most video formats.
Good point, I hadn't thought of that. Maybe that's what the various articles meant, though it would have been nice if it had been more clearly explained.
I fully agree. In the case of Linux, it isn't even necessary to add it to the kernel per se. A user-level process, running as root, can mmap()
chunks of/dev/mem (or all of it, if the amount of installed memory is not too much more than 1 GiB) and read it.
Whether it's done in the kernel or a user process, it will result in displacing useful data from the data cache. I had not characterized the performance hit, but as long as you don't want to scrub the entire memory space to quickly, it doesn't surprise me that the performance impact may not be too noticable.
A kernel-space scrubber could potentially disable interrupts for a very short period, disable the data cache, read some memory, then reenable everything. That trades off cache eviction for higher interrupt latency, which might be better under some circumstances.
Having scrubbing implemented by the memory controller is clearly the best option, so I'm pleased to see that AMD implemented that in the on-chip DDR controller of the Opteron, and in the AMD 762 system controller chip of the 760 MPX chip set.
Both my Asus and Tyan MPX-based boards have the option available in the BIOS.
Strange. My Asus has a BIOS setting for ECC, but no option for scrubbing. I've read the control register, and if I'm interpreting it correctly, scrubbing is NOT being turned on, even though I have ECC enabled. What BIOS version are you running on your Asus?
I don't have any problem with any AMD guys. I have a problem with magazines and web sites that claim that there are two DDR channels, a claim which AMD does not (AFAIK) make themselves. There's only one channel, which happens to have twice the data width. Yes, it has higher bandwidth (duh!).
But claiming that it has two channels is like claiming that a Ferarri is two cars, because it's twice as fast as a Honda. If it were two cars, it could go to two different places at once.
The Sparc architecture has supported memory scrubbing for quite some time.
That's good to know. I was referring to scrubbing being relatively new to PC class machines. Real computers have had such things for many years.
I think you're mistaken when you say it's normal for a PC to get single bit errors several times a week. On all the Sun boxes I work on if I'm getting single bit errors on any DIMM I replace it right away.
At the time I observed this behavior on the Alpha, I was initially concerned. But I got some statistics from several DRAM vendors and found that the error rate was well within spec. I have no idea whether the expected SEU rates for DRAM have changed for more recent parts.
A DIMM that begins to report single bit errors is most likely just hours away from a double bit error and that will definitely panic your box.
Not so. As long as there aren't an extremely high level of single-bit errors, the probability that a second error will occur in the same word is very small even for an extended period of time. The memory system can tolerate as much as a single bit error in every word, as long as two or more bits in the same word don't have errors.
There would be an increase in latency. I'm not sure how significant it would be, compared to the normal latency between two Opterons directly attached via HT with no tunnel between them.
Even though the Athlon 64 (nee Clawhammer) only has a single Hypertransport link, in principle it may be possible to use it in a dual processor SMP configuration without a "special" chipset. For instance, a motherboard could use two Athlon 64s with a single AMD-8131 Hypertransport PCI-X tunnel (or any other Hypertransport tunnel), and attach the two processors to the opposite ends of the HT tunnel.
Of course, such a configuration using the Athlon 64 will not be supported by AMD, since the Athlon 64 will not be rated for SMP use, but in practice it is likely to work, unless AMD actually disables the ccHT capability of the processor.
Slashdot Mirror
By the way, if you want to think of it in terms of frequency of doubling, the numbers I gave correspond to DRAM doubling every 18.8 months, and disk doubling every 16.9 months. Again, this hardly justifies a claim of "a dozen times the force of Moore's law".
In 1981, a state-of-the-art DRAM chip was 64 Kbit (2^16.00 bits), and a state-of-the-art 5.25-inch winchester hard drive was 5 Mbytes (2^25.25 bits). In 2003, a state of the art DRAM chip is 1 Gbit (2^30.00 bits), and a state-of-the -art 3.5-inch winchester hard drive is 250 Gbytes (2^40.86 bits). That's growth by a factor of 1.55 per year for DRAM, and a factor of 1.64 per year for disk. Given only 22 years of historical data for comparison, I don't think one can really claim that the difference in growth rates is significant. It would be fair to simply say that both have grown by a factor of 1.6 per year.
As Kurzweil points out in his book The Age of Spiritual Machines, even though Moore's Law was originally stated in terms of transistors, it actually extrapolates backward accurately for computing devices in general all the way back to the beginning of the 20th century (mechanical calculators), and there's no reason to believe that it won't similarly extend forward even when transistors eventually are replaced by a fundamentally different technology (for instance, nanoscale mechanical computing, or quantum electronics). Part of the rationale for making such a claim is that the same sort of power law has applied to many other technology areas. So it's not too surprising that disk storage density has grown exponentially.
And this is a problem because...?
Does anyone actually care? If so, why?
Geez.
And although MS was involved with USB, that was mainly developed by Intel.
Naturally any time some new kind of hardware comes around, its developers will ask MS to support it, but that's hardly reason to say that MS produced it.
You're not?
It does NOT generate any sympathy for Linux users, and it harms ViaWest and other ISPs.
-- Steven Wright
This seems quite reminiscent of the USL v. U.C. Regents case over the BSD release. USL maintained that the BSD code was tainted, but never cited any specific lines of code. USL decided to settle after the U.C. regents pointed out that USL was in violation of the license terms for the BSD code they were using in System V. At that point, USL probably realized that U.C. could force them to withdraw System V from the market and recall all existing copies in order to strip out the BSD code. Anyhow, as part of the settlement, CSRG did remove a few files that were said to be tainted, but since USL didn't indicate which files to remove, CSRG picked out a few of the files that were crufty and in need of replacement anyhow, and removed those.
Does anyone remember the letter that SCO sent out to customers back in the late 1990s, suggesting that customers would be better off with a professionally written and maintained operating system, rather than an amateur effort by a few hackers? It has a lot of other ridiculous comparisons like that. Someone (ESR?) wrote a parody letter refuting every one of their points.
I used to have the two letters posted outside my cube at a previous place of employment. I just tried to find them using Google, but I must not be using the right search terms.
For a reasonably definitive reference, I recommend A Technical Introduction to Digital Video by Charles Poynton.
No, only most video pixels are non-square. For example, 1080i HDTV at 16:9 aspect ratio has square pixels. Also, sometimes NTSC video is sampled at only 640 pixels width in order to get square pixels.When I first read Stallman's story The Right to Read, I thought it was quite far-fetched, but considering events of the six years since it was published, it now seems like a legitimate concern.
Horizontal resolution is traditionally measured in lines per picture height (not width), so that the horizontal and vertical resolutions have the same scale. (Note that film resolution is normally measured in "line pairs", but video resolution is not.)
A DVD normally has 720 pixels horizontal by 480 vertical (interlaced). If it is mastered with Academy Ratio (4:3) video, that means it has 720 * 3/4 = 540 lines of horizontal resolution. By comparison, VHS has about 240 lines of horizontal resolution. Note that the horizontal resolution is different for anamorphic widescreen DVDs when played on suitable equipment, because of the different aspect ratio.
HDTV at 1080i has 1920 pixels horizontally, and 16:9 ratio, so it has 1920 * 9/16 = 1080 lines of horizontal resolution. Since the horizontal and vertical resolution are the same, the pixels are square, unlike most video formats.
[Lyle] You'll be given cushy jobs!
[Crowd] Monorail! Monorail!
--Simpsons episode 9F10
Good point, I hadn't thought of that. Maybe that's what the various articles meant, though it would have been nice if it had been more clearly explained.
Whether it's done in the kernel or a user process, it will result in displacing useful data from the data cache. I had not characterized the performance hit, but as long as you don't want to scrub the entire memory space to quickly, it doesn't surprise me that the performance impact may not be too noticable.
A kernel-space scrubber could potentially disable interrupts for a very short period, disable the data cache, read some memory, then reenable everything. That trades off cache eviction for higher interrupt latency, which might be better under some circumstances.
Having scrubbing implemented by the memory controller is clearly the best option, so I'm pleased to see that AMD implemented that in the on-chip DDR controller of the Opteron, and in the AMD 762 system controller chip of the 760 MPX chip set.
But claiming that it has two channels is like claiming that a Ferarri is two cars, because it's twice as fast as a Honda. If it were two cars, it could go to two different places at once.
There would be an increase in latency. I'm not sure how significant it would be, compared to the normal latency between two Opterons directly attached via HT with no tunnel between them.
Of course, such a configuration using the Athlon 64 will not be supported by AMD, since the Athlon 64 will not be rated for SMP use, but in practice it is likely to work, unless AMD actually disables the ccHT capability of the processor.