The AMD MPX (dual Athlon) chipset also supports memory scrubbing.
Wow, you're right! I checked the AMD 762 data sheet, and was ready to reply to correct you, when I saw the reference to the AMD 762 System Controller Software/BIOS Design Guide (AMD document 24462 rev D dated March 2002). I downloaded it, and sure enough, scrubbing is documented starting on page 178. Thanks for correcting me!
Now I'll have to see whether my BIOS is actually enabling it.
Most if not all prior x86 chipsets that supported ECC did a fairly half-assed job of it. They didn't report the location of a detected error (whether correctable or not), but instead only the base address of a block of memory which contained the error.
It appears that the Opteron can report the actual address of any detected errors. Plus, it can report details of ECC errors in its caches.
But the coolest feature is that it supports memory scrubbing, a feature I'd previously not seen in a microprocessor or chipset since the iAPX 432 memory controller back in 1983.
When a SEU causes a single-bit error in a word of memory, the ECC is capable of correcting it when the word is read. But if that word doesn't get read again for a long time, it's possible that a second SEU might happen in the same word, which would then be an uncorrectable error. With memory scrubbing, the memory controller uses a small portion of the memory bandwidth to scan the entire memory, correcting any single-bit errors that are found, so that the probability of a two-bit (or more) uncorrectable error is greatly reduced.
My last several computers (including a dual Athlon using the 760MPX chip set, and a DEC Alpha) had ECC, but not scrubbing. I considered writing a Linux program to scrub the memory by direct access to/dev/mem, but this has the disadvantage of thrashing the processor's caches. By implementing scrubbing in hardware, the Opteron avoids that problem.
The Opteron has a Scrub Control Register that is used to enable or disable scrubbing and control the rate. There are independent scrubbing controls for the L1 data cache, L2 cache, and
main memory.
Those of us that want high reliability really welcome this feature. Well done, AMD!
By the way, it should be noted that it is typical for a PC with 128 megabytes of memory to get a single bit error several times a week. On my Alpha, I routinely saw corrected error log messages in the syslog, which gave me much more confidence in the system than the way that most PCs simply fail to even detect memory errors, let alone correct them. The log messages are also useful in that you can determine whether you have some memory that is getting marginal. For instance, at one point I started getting a much higher rate of corrected errors on one particular SIMM. There may have been a slight amount of oxidation or corrosion on the contacts, or they may have just worked themselves loose a bit. Cleaning the contacts and reseating the SIMM solved the problem with only a few minutes of down time, instead of what probably would have been hours of down time had the errors gone unnoticed.
The results of an undetected error vary considerably; it may be in memory that is not in use at the time, or it could be in the midst of the operating system, an application, or user data.
The block diagram on page 11 of the the data sheet even shows the 128 MEMDATA pins.
And it just as clearly shows only one set of address lines. Which is fairly definitive evidence that there's only one memory channel. It just happens to support 128-bit wide memory.
Yes, that does give you a lot of memory bandwidth. No, that doesn't make it "dual channel".
By my count, there are 44 unused pins on the 940-pin package. Some of those may in fact be undocumented test pins, or be intended for other uses on future parts. But even assuming that all 44 pins could be used for another memory controller, that wouldn't be sufficient for another DDR controller, which requires 201 pins (129 if you'd settle for only 72 bit data with ECC, or 121 if you'd settle for only 64 bit data). Reference pages 45-46 of the data sheet.
So a useful additional memory controller will NOT fit the same package.
The announced Opteron parts do not have dual DDR memory channels. They would need even more pins on the
package, and it already has 940! But I imagine the source for the confusion in the early reports is that
the single channel does support
the optional use of 128-bit wide memory (144 bits including ECC). This would most commonly be implemented
using pairs of 64-bit (or 72-bit with ECC) DDR DIMMs. It can support up to four pairs of DIMMs at up
to DDR266 speed (PC-2100) or two pairs of DIMMs at DDR333 (PC-2700).
The various motherboard photos seem to indicate that their are DIMM sockets to accomodate 128-bit memory.
I would hope that the various benchmarks have been done with this configuration, since it obviously
increases the memory bandwidth considerably.
Reference: page 15 of the AMD Opteron Processor data sheet, AMD document 23932 rev 3.00 dated April 2003.
Every Space shuttle is almost completely taken apart, and then reassembled,
What they do isn't even close to completely taking it apart. However, they do perform an amazing amount of work on them to ready them for the next launch.
there is a reason why it costs between 50-500 mil to send the shuttle up there ONCE
Even NASA's use of creative accounting gives numbers much higher than that. And independent experts claim that the cost is closer to a billion dollars per mission.
As it turns out, the supposed benefits of the Shuttle being "reusable" are questionable at best. It would probably be substantially less expensive to simply use fully expendable vehicles. The technology of the 1970s simply wasn't up to the task.
Possibly current technology might be, but NASA clearly chose the wrong candidate for the X-33 space plane program. NASA always prefers to build things out of unobtanium rather than tried-and-proven hardware and materials, but the Lockheed-Martin design required more unobtainium than even NASA could find. If they'd chosen to continue
the Delta Clipper program instead, we might actually have had a considerably more practical reusable vehicle by now. _Halfway to Anywhere_ by G. Harry Stine provides an interesting account of the Delta Clipper program, including the politics that killed it off. It's out of print, but copies are still readily available.
But repairing a space craft with billions of highly specialized parts
This number is also off by at least an order of
magnitude. But your point is quite valid.
NASA Administrator O'Keefe seems optimistic that they will be able to return the shuttle fleet to flight by the end of the year since there has been no show-stopping problems which have been discovered during the investigation.
In other words, they can't really do anything to prevent this from happening again.
Note that even though they plan to use military spysats to
examine the shuttle after launch, they can't do
anything about damage unless they:
launch into an orbit that can dock with the space station, or have enough maneuvering ability to get there
have another shuttle ready to launch nearly immediately even so, they would have to skip some of the normal countdown, and it's unclear that there would be a reasonable probability of a second launch before the first shuttle's consumables are expended
have an unmanned rocket ready to be launched with consumables to resupply the shuttle until some other rescue mission can be cobbled together
After the Columbia disaster, the Japanese government was quick to announce that no Japanese
astronauts would fly on the shuttle until it is determined to be safe. I guess we can expect to see no future Japanese astronauts on the shuttle, since it was never determined to be safe in the past, nor will it be in the future. Some things are worth doing even if they aren't safe.
Perhaps if more ISPs took action, we might see the backbone providers doing so as well?
Much though I hate spam (I get several hundred a day), I certainly hope you're not proposing that the backbone providers should try to classify or filter traffic. This should be done near the edge of the internet, not in the middle. The risk of misidentification is too high.
I fully expected that they would store the Office documents as a big blob of binary data, base64 or base95 encoded, in an XML wrapper. Technically that would be a fully standards-compliant XML file, but in practice it would be completely useless.
So it's not surprising that they haven't made their XML format completely transparent and uniform, but rather it is surprising that they haven't made it completely opaque.
As for Alto's being rarer than an Apple I, that would mean fewer than 150.
I don't mean rarer in the sense that fewer were made. Several thousand Altos were made, vs. perhaps 200 Apple Is.
But I think there are fewer surviving Altos than surviving Apple Is. There are believed to be under 20 Apple Is left.
The last Alto that a friend sold went for $5K about three years ago. Even though the economy has tanked since then, I seriously doubt that an Alto would sell for any less than that now. Although there were more Altos made than Apple Is, there may be fewer Altos left in existence. It was easier for someone with an Apple I to store it in their garage or basement. Also, most Altos were not in private hands, so when they were no longer needed they got scrapped.
On the other hand, it's much easier to find a second-generation Star system, the Xerox 6085, known as the Daybreak. As of a year ago, people around here were still giving those away.
Getting the Star software running is much harder than acquiring the hardware. Generally you need a server as well (typically an 8090 Daylight), and a license key. It is possible to get it running standalone, but that's not how it was normally used.
The software was renamed from Star to Globalview. There actually was a Windows version of it, GVWin.
GVWin was still written in Mesa. Fuji/Xerox also had a product that implemented the Mesa byte code interpreter on a PC.
Since Microsoft owns the software they write, it is not possible for them to make illegal copies of it, nor is it possible for them to illegally give you a copy (at least in terms of copyright). And if they do give you a copy, it is legal for you to posess the copy, regardless of what it may claim on the label. Just because they write "illegal without separate license" on the label doesn't make it so -- Microsoft doesn't have the power to write new laws, no matter how much they'd like to think so. [*]
They can only limit you from doing further copying. [**]
AFAIK, there is no way they can legally prevent you from lending the disc which they gave you to another party. Copyright law does prohibit renting it out, though.
Eric
[*] If Microsoft wants new laws, they get them the same way as anyone else would, by buying Congressmen. Of course, Microsoft can afford to buy more Congressmen than most other companies.
[**] There is apparently conflicting case law on whether running software from a disc constitutes making a copy (in memory) within the meaning of copyright law.
Last year I did some work on
Altogether,
a microcode-level Alto simulator. It does not
yet include simulation of the disk or 3 Mbps Ethernet hardware, which will be necessary
in order to boot useful Alto software.
Because almost all of the interesting Alto software used the writable control store, it is important to simulate the Alto at the microcode level. The Alto used horizontal microcode, so several operations are done in each clock cycle, which IIRC was 170 ns. On an Athlon XP 1900+, the CPU simulation runs at about 1/4 real time. In order to obtain better performance, it will be necessary to do quite a bit of optimization, possibly including binary translation of the microcode into native host code.
There's no packaged release of the Altogether code, but it can be checked out from CVS.
Since it reports a size of 1769.2 MB, am I correct in thinking that redhat9.torrent only includes the binary ISOs? Does anyone have the source ISOs on BitTorrent?
I've got a download of the source ISOs going from RHN, but it looks like it will take more than a week to complete, whereas I'm getting >200 KB/s download and >100 KB/s upload with BitTorrent.
Therefore, writing a new software tool that reduces the amount of overall work a programmer has to do is a sign of laziness.
I'm guessing that you have some emotional baggage associated with the word "lazy", that isn't part of the definition. When I say that programmers are lazy, that's praise, not vituperation.
C (and C++) are terrible tools for software engineering. Yes, it's possible to write robust code in C or C++, but the language doesn't do much to make it easy. And since programmers are basically lazy[*]...
Using a better language doesn't completely prevent software defects, but it can eliminate a large class of exploitable security problems.
Some more suitable languages include Ada, Java, Modula-3, Sather, Scheme, and Smalltalk. There are, of course, many others as well. Some of these impose a non-trivial performance penalty compared to C and C++, but some of them don't.
C.A.R. Hoare, in his 1980 ACM Turing Award Lecture, made the insightful observation:
...there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature. It also requires a willingness to accept objectives which are limited by physical, logical, and technological constraints, and to accept a compromise when conflicting objectives cannot be met. No committee will ever do this until it is too late.
Given how difficult it is to write robust software, it astonishes me that it is still common practice to use languages that offer essentially no help in avoiding common mistakes.
[*] Laziness in programmers is a virtue! Most new software tools are developed because a programmer somewhere was too lazy to keep doing things the same old way.
I used to be annoyed at how Congress would waste time passing ridiculous resolutions making a particular day "Nation Cauliflower Day" and the like. But now I'm in favor of them spending more time on such things, because that leaves them less time to enact bad legislation like the DMCA.
Be thankful that you don't actually get as much government as you pay for!
You can run SLIP just fine on an 11/20. Having an Ethernet connection is not a prerequisite to being connected to the internet. But it was very common to add BA11 expansion boxes of various sorts to the 11/20. I'm not sure what you mean by timing issues, as the 11/20 uses standard Unibus timing.
It's entirely possible to run Unix on several models that predate the 11/70, including the 11/40 and 11/45. The C version of Unix was originally developed on the 11/40.
The PDP-11/70 isn't that difficult to run and maintain. But it is rather large (physically).
I have almost every PDP-11 model, and several of some, but I'm still looking for an 11/45. The 11/44 is a nice machine, and is the is the one I use the most. It was the last of the TTL PDP-11 designs; all models designed after that, such as the MicroPDP-11/73, use the F11 or J11
microprocessors.
The BA23 is a terrible case. Aside from having only two drive bays and an anemic power supply, it is difficult to run cabling for options, especially if you want disks other than the RD5x. Also, many of the BA23s available surplus have not had the power supply cable retrofit, and the old power supply cables are prone to burning up. If you have a choice, get the BA123 "World Box" instead. It's a much nicer case, and will work with the 11/23, 11/53, 11/83, and 11/93 processors.
Not even close.
People have run web browsers on PDP-11s. The PDP-11 was introduced twelve years before the Commodore 64.
I suspect that people have run web browsers on computers even older than that.
Not bad, but I really want the 3.5-inch drives to be in individual trays. So what I'm really looking for is a tower case with 10-12 exposed 5.25-inch bays and NO 3.5-inch bays. That way I can install either the single IDE trays, or the AMS cages.
It used to be fairly easy to find cases with 8 exposed 5.25-inch bays. There were even double-wide cases with a lot of 5.25-inch bays. But they seem to have become rare.
I think my approach to that would have been to get a tower case with between nine and twelve 5.25-inch bays, then use three or four of the raid cages that fit five 1-inch tall 3.5-inch drives into three bays:
AMS DK-035A (ignore the Ultra SCSI reference on that page, the A suffix is for ATA), available for $159 from
Central Computer
I just set up an eight drive RAID using one of those, and one 3-drive-in-2-bay version, the
DK-023A ($119 from Central Computer). That way
eight removable trays fit in my 5-bay 4U rack mount case.
I used a
3ware Escalade 7500-8 RAID card rather than Linux software RAID, but there's no reason
why it wouldn't have worked with software RAID. I just couldn't find a "dumb" eight-port ATA-133 card. (And I like the 3ware cards.)
I initially tried to use Serial ATA, using the
Promise SATA150-TX4 4-port Serial ATA controller and some Highpoint RocketHead 100 Serial ATA adapters for the drives. The Highpoint web site claims that the RocketHead 100 is not available for sale as a separate product, but lots of retailers including Central Computer seem to have them. The cabling was *much* nicer, but to make the SATA150 work with Linux a binary-only driver was required, so I decided not to use it until there's a driver available in source form.
I thought about using the
3ware Escalade 8500, which is the Serial ATA version of the 7500, but there's quite a price premium, so I decided to stick with parallel ATA for now. Maybe next year I'll set up a bigger RAID using Serial ATA.
Slashdot Mirror
Now I'll have to see whether my BIOS is actually enabling it.
It appears that the Opteron can report the actual address of any detected errors. Plus, it can report details of ECC errors in its caches.
But the coolest feature is that it supports memory scrubbing, a feature I'd previously not seen in a microprocessor or chipset since the iAPX 432 memory controller back in 1983.
When a SEU causes a single-bit error in a word of memory, the ECC is capable of correcting it when the word is read. But if that word doesn't get read again for a long time, it's possible that a second SEU might happen in the same word, which would then be an uncorrectable error. With memory scrubbing, the memory controller uses a small portion of the memory bandwidth to scan the entire memory, correcting any single-bit errors that are found, so that the probability of a two-bit (or more) uncorrectable error is greatly reduced.
My last several computers (including a dual Athlon using the 760MPX chip set, and a DEC Alpha) had ECC, but not scrubbing. I considered writing a Linux program to scrub the memory by direct access to /dev/mem, but this has the disadvantage of thrashing the processor's caches. By implementing scrubbing in hardware, the Opteron avoids that problem.
The Opteron has a Scrub Control Register that is used to enable or disable scrubbing and control the rate. There are independent scrubbing controls for the L1 data cache, L2 cache, and main memory.
Those of us that want high reliability really welcome this feature. Well done, AMD!
By the way, it should be noted that it is typical for a PC with 128 megabytes of memory to get a single bit error several times a week. On my Alpha, I routinely saw corrected error log messages in the syslog, which gave me much more confidence in the system than the way that most PCs simply fail to even detect memory errors, let alone correct them. The log messages are also useful in that you can determine whether you have some memory that is getting marginal. For instance, at one point I started getting a much higher rate of corrected errors on one particular SIMM. There may have been a slight amount of oxidation or corrosion on the contacts, or they may have just worked themselves loose a bit. Cleaning the contacts and reseating the SIMM solved the problem with only a few minutes of down time, instead of what probably would have been hours of down time had the errors gone unnoticed.
The results of an undetected error vary considerably; it may be in memory that is not in use at the time, or it could be in the midst of the operating system, an application, or user data.
Yes, that does give you a lot of memory bandwidth. No, that doesn't make it "dual channel".
So a useful additional memory controller will NOT fit the same package.
The various motherboard photos seem to indicate that their are DIMM sockets to accomodate 128-bit memory. I would hope that the various benchmarks have been done with this configuration, since it obviously increases the memory bandwidth considerably.
Reference: page 15 of the AMD Opteron Processor data sheet, AMD document 23932 rev 3.00 dated April 2003.
As it turns out, the supposed benefits of the Shuttle being "reusable" are questionable at best. It would probably be substantially less expensive to simply use fully expendable vehicles. The technology of the 1970s simply wasn't up to the task.
Possibly current technology might be, but NASA clearly chose the wrong candidate for the X-33 space plane program. NASA always prefers to build things out of unobtanium rather than tried-and-proven hardware and materials, but the Lockheed-Martin design required more unobtainium than even NASA could find. If they'd chosen to continue the Delta Clipper program instead, we might actually have had a considerably more practical reusable vehicle by now. _Halfway to Anywhere_ by G. Harry Stine provides an interesting account of the Delta Clipper program, including the politics that killed it off. It's out of print, but copies are still readily available.
This number is also off by at least an order of magnitude. But your point is quite valid.Note that even though they plan to use military spysats to examine the shuttle after launch, they can't do anything about damage unless they:
- launch into an orbit that can dock with the space station, or have enough maneuvering ability to get there
- have another shuttle ready to launch nearly immediately even so, they would have to skip some of the normal countdown, and it's unclear that there would be a reasonable probability of a second launch before the first shuttle's consumables are expended
- have an unmanned rocket ready to be launched with consumables to resupply the shuttle until some other rescue mission can be cobbled together
After the Columbia disaster, the Japanese government was quick to announce that no Japanese astronauts would fly on the shuttle until it is determined to be safe. I guess we can expect to see no future Japanese astronauts on the shuttle, since it was never determined to be safe in the past, nor will it be in the future. Some things are worth doing even if they aren't safe.So it's not surprising that they haven't made their XML format completely transparent and uniform, but rather it is surprising that they haven't made it completely opaque.
With Linux, when you want to transfer the license, you have to pay a transfer fee of 72.8 times the original license cost!
On the other hand, it's much easier to find a second-generation Star system, the Xerox 6085, known as the Daybreak. As of a year ago, people around here were still giving those away.
Getting the Star software running is much harder than acquiring the hardware. Generally you need a server as well (typically an 8090 Daylight), and a license key. It is possible to get it running standalone, but that's not how it was normally used.
The software was renamed from Star to Globalview. There actually was a Windows version of it, GVWin. GVWin was still written in Mesa. Fuji/Xerox also had a product that implemented the Mesa byte code interpreter on a PC.
They can only limit you from doing further copying. [**]
AFAIK, there is no way they can legally prevent you from lending the disc which they gave you to another party. Copyright law does prohibit renting it out, though.
Eric
[*] If Microsoft wants new laws, they get them the same way as anyone else would, by buying Congressmen. Of course, Microsoft can afford to buy more Congressmen than most other companies.
[**] There is apparently conflicting case law on whether running software from a disc constitutes making a copy (in memory) within the meaning of copyright law.
Because almost all of the interesting Alto software used the writable control store, it is important to simulate the Alto at the microcode level. The Alto used horizontal microcode, so several operations are done in each clock cycle, which IIRC was 170 ns. On an Athlon XP 1900+, the CPU simulation runs at about 1/4 real time. In order to obtain better performance, it will be necessary to do quite a bit of optimization, possibly including binary translation of the microcode into native host code.
There's no packaged release of the Altogether code, but it can be checked out from CVS.
I've got a download of the source ISOs going from RHN, but it looks like it will take more than a week to complete, whereas I'm getting >200 KB/s download and >100 KB/s upload with BitTorrent.
Therefore, writing a new software tool that reduces the amount of overall work a programmer has to do is a sign of laziness.
I'm guessing that you have some emotional baggage associated with the word "lazy", that isn't part of the definition. When I say that programmers are lazy, that's praise, not vituperation.
C# having some of the advantages of Java, but not all. They deliberately did NOT make it fully type-safe, which is one of Java's strong points.
Using a better language doesn't completely prevent software defects, but it can eliminate a large class of exploitable security problems.
Some more suitable languages include Ada, Java, Modula-3, Sather, Scheme, and Smalltalk. There are, of course, many others as well. Some of these impose a non-trivial performance penalty compared to C and C++, but some of them don't.
Some time back I was involved in a thread about programming language support for reliable software, in which I compared C to a table saw with no finger guard.
C.A.R. Hoare, in his 1980 ACM Turing Award Lecture, made the insightful observation:
Given how difficult it is to write robust software, it astonishes me that it is still common practice to use languages that offer essentially no help in avoiding common mistakes.
Microsoft is correct, however, that better education would improve things. Marc Donner posted an insightful comparison between how programming and writing are taught.
Eric
[*] Laziness in programmers is a virtue! Most new software tools are developed because a programmer somewhere was too lazy to keep doing things the same old way.
Be thankful that you don't actually get as much government as you pay for!
It's entirely possible to run Unix on several models that predate the 11/70, including the 11/40 and 11/45. The C version of Unix was originally developed on the 11/40.
The PDP-11/70 isn't that difficult to run and maintain. But it is rather large (physically).
I have almost every PDP-11 model, and several of some, but I'm still looking for an 11/45. The 11/44 is a nice machine, and is the is the one I use the most. It was the last of the TTL PDP-11 designs; all models designed after that, such as the MicroPDP-11/73, use the F11 or J11 microprocessors.
The BA23 is a terrible case. Aside from having only two drive bays and an anemic power supply, it is difficult to run cabling for options, especially if you want disks other than the RD5x. Also, many of the BA23s available surplus have not had the power supply cable retrofit, and the old power supply cables are prone to burning up. If you have a choice, get the BA123 "World Box" instead. It's a much nicer case, and will work with the 11/23, 11/53, 11/83, and 11/93 processors.
Not even close. People have run web browsers on PDP-11s. The PDP-11 was introduced twelve years before the Commodore 64. I suspect that people have run web browsers on computers even older than that.
It used to be fairly easy to find cases with 8 exposed 5.25-inch bays. There were even double-wide cases with a lot of 5.25-inch bays. But they seem to have become rare.
Maybe I'll just start building my own.
Give it another six months to a year, and SATA stuff should be common as dirt. But that's small consolation to someone that wants it now.
AMS DK-035A (ignore the Ultra SCSI reference on that page, the A suffix is for ATA), available for $159 from Central Computer
I just set up an eight drive RAID using one of those, and one 3-drive-in-2-bay version, the DK-023A ($119 from Central Computer). That way eight removable trays fit in my 5-bay 4U rack mount case.
I used a 3ware Escalade 7500-8 RAID card rather than Linux software RAID, but there's no reason why it wouldn't have worked with software RAID. I just couldn't find a "dumb" eight-port ATA-133 card. (And I like the 3ware cards.)
I initially tried to use Serial ATA, using the Promise SATA150-TX4 4-port Serial ATA controller and some Highpoint RocketHead 100 Serial ATA adapters for the drives. The Highpoint web site claims that the RocketHead 100 is not available for sale as a separate product, but lots of retailers including Central Computer seem to have them. The cabling was *much* nicer, but to make the SATA150 work with Linux a binary-only driver was required, so I decided not to use it until there's a driver available in source form.
I thought about using the 3ware Escalade 8500, which is the Serial ATA version of the 7500, but there's quite a price premium, so I decided to stick with parallel ATA for now. Maybe next year I'll set up a bigger RAID using Serial ATA.