By: Brendan (btrotter.delete@this.gmail.com), June 30, 2007 9:25 am
Room: Moderated Discussions
Hi,
philt (ptay1685@bigpond.net.au) on 6/30/07 wrote:
---------------------------
>Brendan (btrotter@gmail.com) on 6/30/07 wrote:
>---------------------------
>>philt (ptay1685@bigpond.net.au) on 6/29/07 wrote:
>>---------------------------
>>>Andi Kleen (ak-rwt@muc.de) on 6/29/07 wrote:
>>>---------------------------
>>>>Depends. A lot are in very contrived circumstances
>>>>that are unlikely to be hit in any real situation
>>>>(usually found then with randomized tests)
>>>>
>>>
>>>That word "unlikely" is rather worrying. I prefer "never".
>>
>>Imagine a list of errata for your car, which includes things like "the engine may
>>stall if it's submersed in water" and "the tires tend to blow up when the car approaches
>>the speed of sound". Would you rather these things aren't listed in the errata (so
>>that people doing really strange things like driving underwater or trying to set
>>land-speed records don't know about the problem), or would you rather the car manufacturer
>>spent billions of dollars fixing these "defects" and passed the costs onto the purchaser?
>>
>
>These things you are listing are limitations imposed by design, not by accident.
>They are not defects. The reason the word "errata" is used is because it indicates
>"errors", e.g. they are unintentional. They (usually, often) cause behaviour that
>is unpredictable and therefor wholly undesireable for something to be programmed
>where predictability is mandatory. So a car that cannot run underwater is fine for
>its intended purpose, whearas a cpu that can do the unexpected and cause program exceptions or invalid data is not.
Maybe my anology could've been better. If the paint was chipped deep in the engine bay of your nice new car, and the manufacturer listed "possibility of chipped paint" in their list of errata, would you really care?
>It is not however expected that an engine will run under water. And neither does
>Intel mention "do not connect the cpu directly to the AC mains" either in their errata.
Intel's documentation (for all of their CPUs dating back to Pentium or earlier) has a lot of information for electrical characteristics, maximum/minimum tolerances, bus signalling, thermal envelopes, etc. It's not in the programming manuals though - there's "hardware developer manuals" for that.
The errata deals with behaviour that contradicts what the documentation says, and therefore they don't need to state that the CPU shouldn't be connected directly to AC mains as the hardware documentation does state that the CPU requires certain voltages within specific tolerances.
>I really fail to see any rationale behind this argument of yours.
It's simple really. There's nothing in any of the Core2 errata that any normal end-user or application programmer should care about (just like normal car drivers/owners don't care about some silly paint chip where no-one can see it, or an inability to drive underwater or reach the speed of sound).
OS developers and BIOS writers might need to worry about roughly 2% of the errata (but they aren't "normal end-users"). It's a complete non-event.
The problem is that the list of errata is difficult for "normal end-users" to understand. They read something like "PREFETCHh Instructions May Not be Executed when Alignment Check (AC) is Enabled" and start to panic thinking all their data will be lost, when in reality the worst that will happen is some software might (in rare cases) run a tiny little bit slower. Usually this doesn't matter much because usually "normal end-users" don't see or hear anything about the list of errata, but now and then some moron journalist (or perhaps an ill-informed OpenBSD developer) gets the wrong idea and start getting normal end-user's worried about nothing.
Let me ask, have you read (and understood) the errata we're talking about? If you have, which specific item (items?) are you actually worried about?
Also, to put your concerns in perspective, are you using ECC RAM, an uninterruptible power supply and a fault tolerant RAID array for disk storage? If you're not, then I can guarantee you've got more important things to worry about...
Cheers,
Brendan
philt (ptay1685@bigpond.net.au) on 6/30/07 wrote:
---------------------------
>Brendan (btrotter@gmail.com) on 6/30/07 wrote:
>---------------------------
>>philt (ptay1685@bigpond.net.au) on 6/29/07 wrote:
>>---------------------------
>>>Andi Kleen (ak-rwt@muc.de) on 6/29/07 wrote:
>>>---------------------------
>>>>Depends. A lot are in very contrived circumstances
>>>>that are unlikely to be hit in any real situation
>>>>(usually found then with randomized tests)
>>>>
>>>
>>>That word "unlikely" is rather worrying. I prefer "never".
>>
>>Imagine a list of errata for your car, which includes things like "the engine may
>>stall if it's submersed in water" and "the tires tend to blow up when the car approaches
>>the speed of sound". Would you rather these things aren't listed in the errata (so
>>that people doing really strange things like driving underwater or trying to set
>>land-speed records don't know about the problem), or would you rather the car manufacturer
>>spent billions of dollars fixing these "defects" and passed the costs onto the purchaser?
>>
>
>These things you are listing are limitations imposed by design, not by accident.
>They are not defects. The reason the word "errata" is used is because it indicates
>"errors", e.g. they are unintentional. They (usually, often) cause behaviour that
>is unpredictable and therefor wholly undesireable for something to be programmed
>where predictability is mandatory. So a car that cannot run underwater is fine for
>its intended purpose, whearas a cpu that can do the unexpected and cause program exceptions or invalid data is not.
Maybe my anology could've been better. If the paint was chipped deep in the engine bay of your nice new car, and the manufacturer listed "possibility of chipped paint" in their list of errata, would you really care?
>It is not however expected that an engine will run under water. And neither does
>Intel mention "do not connect the cpu directly to the AC mains" either in their errata.
Intel's documentation (for all of their CPUs dating back to Pentium or earlier) has a lot of information for electrical characteristics, maximum/minimum tolerances, bus signalling, thermal envelopes, etc. It's not in the programming manuals though - there's "hardware developer manuals" for that.
The errata deals with behaviour that contradicts what the documentation says, and therefore they don't need to state that the CPU shouldn't be connected directly to AC mains as the hardware documentation does state that the CPU requires certain voltages within specific tolerances.
>I really fail to see any rationale behind this argument of yours.
It's simple really. There's nothing in any of the Core2 errata that any normal end-user or application programmer should care about (just like normal car drivers/owners don't care about some silly paint chip where no-one can see it, or an inability to drive underwater or reach the speed of sound).
OS developers and BIOS writers might need to worry about roughly 2% of the errata (but they aren't "normal end-users"). It's a complete non-event.
The problem is that the list of errata is difficult for "normal end-users" to understand. They read something like "PREFETCHh Instructions May Not be Executed when Alignment Check (AC) is Enabled" and start to panic thinking all their data will be lost, when in reality the worst that will happen is some software might (in rare cases) run a tiny little bit slower. Usually this doesn't matter much because usually "normal end-users" don't see or hear anything about the list of errata, but now and then some moron journalist (or perhaps an ill-informed OpenBSD developer) gets the wrong idea and start getting normal end-user's worried about nothing.
Let me ask, have you read (and understood) the errata we're talking about? If you have, which specific item (items?) are you actually worried about?
Also, to put your concerns in perspective, are you using ECC RAM, an uninterruptible power supply and a fault tolerant RAID array for disk storage? If you're not, then I can guarantee you've got more important things to worry about...
Cheers,
Brendan
