Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

I've been building PCs for a few years now, and since Socket 7 I have
preferred Intel motherboard chipsets (tho generally not Intel mobos).

I recently moved from generic 865G motherboards to using Intel's
Bayfield, which is a full-ATX based on that chipset.

I've found reliability to be more erratic than I'd previously
considered acceptable for motherboards. A couple of outright
failures, but more often it's been general flakiness (e.g. locking up
at temps other sample boards don't lock up, or locking up at
particular points in the MemTest suite).

Also, usually when a processor core is shrunk, the new chips will run
cooler at a given clock speed. Once again, Prescott has defied the
usual expectations; even the modest Celeron 2.4GHz tends to push what
Bayfield calls "Zone 2" to 42C - 47C, with some Bayfield motherboards
regularly locking up at 42C and others being happy at full temp.

What's been other ppl's mileage on this stuff?



>--------------- ---- --- -- - - - -
I'm baaaack!
>--------------- ---- --- -- - - - -

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Mon, 06 Dec 2004 00:45:44 +0200, "cquirke (MVP Win9x)"
<cquirkenews@nospam.mvps.org> wrote:

>I've been building PCs for a few years now, and since Socket 7 I have
>preferred Intel motherboard chipsets (tho generally not Intel mobos).
>
>I recently moved from generic 865G motherboards to using Intel's
>Bayfield, which is a full-ATX based on that chipset.
>
>I've found reliability to be more erratic than I'd previously
>considered acceptable for motherboards. A couple of outright
>failures, but more often it's been general flakiness (e.g. locking up
>at temps other sample boards don't lock up, or locking up at
>particular points in the MemTest suite).

Intel's boards aren't really all that different from any other
company, and not really any more reliable either. I don't know about
this particular model, but all companies have the odd board that just
doesn't match up with others.

>Also, usually when a processor core is shrunk, the new chips will run
>cooler at a given clock speed. Once again, Prescott has defied the
>usual expectations;

You are forgetting that the Prescott is NOT a core shrink at all, but
rather a major overhaul of the whole chip design. The reason why the
Prescott consumes more power than the Northwood before it is that
Intel more than doubled the number of transistors (from ~55M to
~125M).

On a per-transistor basis, Intel's Prescott shows just as much of a
power consumption drop as previous die shrinks (ie "Willamette" P4 at
180nm to "Northwood" P4 at 130nm), but when you factor in the large
increase in transistor count, it's no surprise that the chip consumes
more power.

Of course, the question that none of us have been able to answer is
why in the heck did Intel more than double the transistor count
without a really noticeable improvement in performance?! But I
digress..

> even the modest Celeron 2.4GHz tends to push what
>Bayfield calls "Zone 2" to 42C - 47C, with some Bayfield motherboards
>regularly locking up at 42C and others being happy at full temp.

I'm not quite sure where "Zone 2" is in this board, but it sounds like
perhaps your not getting very much airflow through the case? It
doesn't do much good to remove the heat from your processor if that
heat isn't subsequently being moved out of the case.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Mon, 06 Dec 2004 06:53:10 -0500, Tony Hill
>On Mon, 06 Dec 2004 00:45:44 +0200, "cquirke (MVP Win9x)"

>>I've been building PCs for a few years now, and since Socket 7 I have
>>preferred Intel motherboard chipsets (tho generally not Intel mobos).
>>I recently moved from generic 865G motherboards to using Intel's
>>Bayfield, which is a full-ATX based on that chipset.

>>I've found reliability to be more erratic than I'd previously
>>considered acceptable for motherboards. A couple of outright
>>failures, but more often it's been general flakiness

>Intel's boards aren't really all that different from any other
>company, and not really any more reliable either.

What I didn't expect was, *less* reliability. Mobo failures, DoA, or
turning up as baddie on swap testing were very rare before Bayfield,
other than the capacitor failures that is.

>I don't know about this particular model, but all companies have
>the odd board that just doesn't match up with others.

This isn't base on one baddie, but a few over several months.

>>Also, usually when a processor core is shrunk, the new chips will run
>>cooler at a given clock speed. Once again, Prescott has defied the
>>usual expectations;

>You are forgetting that the Prescott is NOT a core shrink at all, but
>rather a major overhaul of the whole chip design. The reason why the
>Prescott consumes more power than the Northwood before it is that
>Intel more than doubled the number of transistors (from ~55M to
>~125M).

I know L2 counts a lot for that, but where did the rest go? Usually
they either simplify at a mild performance hit, and/or add
functionalities like new SIMD opcodes. Does HT take up so many
trannies? If so, how does that affect no-HT Celeron? My mileage is
based on Prescott Celeron, which as slightly faster base speed and L2
pushed from 128k to 256k and not much else. In fact, deeper pipelines
are said to lose most of what L2 gains, at current GHz.

>Of course, the question that none of us have been able to answer is
>why in the heck did Intel more than double the transistor count
>without a really noticeable improvement in performance?!

Law of Diminishing Returns? Moore predicted double the trannies every
18 months, and it's the extrapolation of others that assume this means
twice the speed. There's only so much you can do by increasing
"processing about processing" - so I expect full multi-CPU dies next.

>> even the modest Celeron 2.4GHz tends to push what
>>Bayfield calls "Zone 2" to 42C - 47C, with some Bayfield motherboards
>>regularly locking up at 42C and others being happy at full temp.

>I'm not quite sure where "Zone 2" is in this board

Exactlty - and neither manual nor board map show where these sensors
are, nor could I find info at Intel's site.

>perhaps your not getting very much airflow through the case? It
>doesn't do much good to remove the heat from your processor if that
>heat isn't subsequently being moved out of the case.

I had to move from one case design that had PSU vertically in front of
CPU, which I suspect created a hot pocket at top of case between the
PSU and CPU assembly. Extra case fans didn't help.

But even with the larger case design that has horizontal PSU above the
mobo, I still see heat issues. As a non-overclocker who generally
uses modest (Celeron) chips with boxed fans that have been fine until
now, I'm surprised to see these sort of heat problems.



>--------------- ---- --- -- - - - -
I'm baaaack!
>--------------- ---- --- -- - - - -

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Mon, 06 Dec 2004 20:35:07 +0200, "cquirke (MVP Win9x)"
<cquirkenews@nospam.mvps.org> wrote:

>On Mon, 06 Dec 2004 06:53:10 -0500, Tony Hill
>>On Mon, 06 Dec 2004 00:45:44 +0200, "cquirke (MVP Win9x)"
>
>>I don't know about this particular model, but all companies have
>>the odd board that just doesn't match up with others.
>
>This isn't base on one baddie, but a few over several months.

It may simply be that this model of board is a bad design, not just
one sample of the board. If the problems are one of design, than that
is entirely possible.

>>You are forgetting that the Prescott is NOT a core shrink at all, but
>>rather a major overhaul of the whole chip design. The reason why the
>>Prescott consumes more power than the Northwood before it is that
>>Intel more than doubled the number of transistors (from ~55M to
>>~125M).
>
>I know L2 counts a lot for that, but where did the rest go? Usually
>they either simplify at a mild performance hit, and/or add
>functionalities like new SIMD opcodes.

That's the real question now isn't it.. The extra L2 cache counts for
about 30-35M transistors (6 transistors per bit, 9 bits per bit due to
ECC and 512KBytes + some redundancy). Others are just used for
testing and not actually enabled for normal use. Others still were
added for the extra 11 instructions that make up SIMD. A few of them
are also there for the 64-bit EM64T support (present but disabled on
most chips).

In the end though, it still seems like a LOT of extra transistors
given the nearly non-existent performance gains (an occasional
performance loses).

> Does HT take up so many trannies?

Hyperthreading was implemented in Northwood, and while it was slightly
changed in Prescott (including the addition of two new instructions),
it doesn't seem to have improved performance at all.

> If so, how does that affect no-HT Celeron?

AFAIK the Celeron uses the exact same core, just with hyperthreading
disabled.

> My mileage is
>based on Prescott Celeron, which as slightly faster base speed and L2
>pushed from 128k to 256k and not much else. In fact, deeper pipelines
>are said to lose most of what L2 gains, at current GHz.

The Prescott-based Celeron D chips are quite a bit faster, clock for
clock, than the older Northwood-based Celeron chips. The old Celeron
was SEVERELY data-starved due to the two-fold hit of small cache and
low bus speed. The Celeron D doubled the L1 data cache, improved the
trace cache, doubled the L2 cache and bumped up the bus speed. The
end result was about a 20% improvement in per-clock performance
relative to the old chip.

Still, almost none of that improvement came from any changes in the
processor core itself (though I suppose we should consider L1 cache
and trace cache as part of the processor core).

>>Of course, the question that none of us have been able to answer is
>>why in the heck did Intel more than double the transistor count
>>without a really noticeable improvement in performance?!
>
>Law of Diminishing Returns? Moore predicted double the trannies every
>18 months, and it's the extrapolation of others that assume this means
>twice the speed. There's only so much you can do by increasing
>"processing about processing" - so I expect full multi-CPU dies next.

As I do, and I'm sure that the diminishing returns is part of it.
Still, AMD's Athlon64 die has less than twice as many transistors as
the AthlonXP and it saw a fairly measurable improvement in
performance. Admittedly that was mostly due to integrating the memory
controller, but that simply raises the question of "why didn't Intel
do that?!"... but I suppose that's another discussion that's already
going on in this newsgroup :>

>>> even the modest Celeron 2.4GHz tends to push what
>>>Bayfield calls "Zone 2" to 42C - 47C, with some Bayfield motherboards
>>>regularly locking up at 42C and others being happy at full temp.
>
>>I'm not quite sure where "Zone 2" is in this board
>
>Exactlty - and neither manual nor board map show where these sensors
>are, nor could I find info at Intel's site.
>
>>perhaps your not getting very much airflow through the case? It
>>doesn't do much good to remove the heat from your processor if that
>>heat isn't subsequently being moved out of the case.
>
>I had to move from one case design that had PSU vertically in front of
>CPU, which I suspect created a hot pocket at top of case between the
>PSU and CPU assembly. Extra case fans didn't help.
>
>But even with the larger case design that has horizontal PSU above the
>mobo, I still see heat issues. As a non-overclocker who generally
>uses modest (Celeron) chips with boxed fans that have been fine until
>now, I'm surprised to see these sort of heat problems.

Have you tried updating the BIOS on this board? Just a thought, but I
know a lot of these thermal sensors are VERY inaccurate and are really
just taking a wild guess at temperature. Often time a manufacturer
will have a bug in their temp sensor settings in the BIOS that causes
incorrect temp readings?

Along the same lines, do things inside the case (and/or heatsinks)
seem to be getting physically hot? 47C is pretty warm and should be
noticeable if the ambient air is that warm. On the other hand, if
it's just the processor that they are measuring, 47C is rather cool
and really shouldn't be a problem at all.

You might want to contact Intel tech support on this one. Chances are
that if you have experienced this on a few boards than hundreds of
other people have as well. Intel may have a solution to this already.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Wed, 08 Dec 2004 00:19:58 -0500, Tony Hill
>On Mon, 06 Dec 2004 20:35:07 +0200, "cquirke (MVP Win9x)"

>It may simply be that this model of board is a bad design, not just
>one sample of the board. If the problems are one of design, than that
>is entirely possible.

Yep, could be - it gets rev'd enough, tho so far the baddies haven't
all been of one particular -40x rev. Saw another one today; system is
fine except it locks on POST after reset; after ATX power cycle, POSTs
fine, etc. Same PSU and other goodies as usual.

>>>Prescott consumes more power than the Northwood before it
>>>Intel more than doubled the number of trans (~55M to ~125M).

>>I know L2 counts a lot for that, but where did the rest go?

>That's the real question now isn't it.. The extra L2 cache counts for
>about 30-35M transistors (6 transistors per bit, 9 bits per bit due to
>ECC and 512KBytes + some redundancy). Others are just used for
>testing and not actually enabled for normal use.

Aha! Think software that's more bloated but more reliable because
it's agregated from hi-level blocks, and think post-manufacturing
bugfixing CPUs via microcode pushed by BIOS or OS.

Think XP SP2 vs. Prescott issue, where a Prescott (or P4-EE) left at
Microcode rev 0 by BIOS cause SP2's Update.sys to lock up.

( http://cquirke.mvps.org/sp2intel.htm refers)

I expect some "slackness" where some stuff is left generalized a la
programmable logic array, to be comitted via microcode?

>In the end though, it still seems like a LOT of extra transistors
>given the nearly non-existent performance gains (an occasional
>performance loses).

On "losses", are you referring to the deeper pipelines?

>> Does HT take up so many trannies?
>> If so, how does that affect no-HT Celeron?

>AFAIK the Celeron uses the exact same core, just with hyperthreading
>disabled.

Bloody typical - no wonder Intel pushes P4 so hard, it's money for jam

>AMD's Athlon64 die has less than twice as many transistors as
>the AthlonXP and it saw a fairly measurable improvement in
>performance. Admittedly that was mostly due to integrating the memory
>controller, but that simply raises the question of "why didn't Intel
>do that?!"... but I suppose that's another discussion that's already
>going on in this newsgroup :>

Intel's been a bit sly in shoving their problems onto other ppl, e.g.

1) BIOS to maintain and push microcode update revs - how many
"required BIOS updates" are actually CPU hotfixes? As it is, the
"blame" for SP2 vs. Prescott has been dumped on motherboard and BIOS
vendors, whereas a date check on Intel's own mobo Prescott readiness
(esp. when in-channel stock versions are also checked) is interesting.

2) Pins on mobo instead of CPU; if the pins bend, it's the mobo
vendor's problem, and that may be another Intel mobo chipset sold
(seeing as Intel won't have to cough that up as warranty fix). Too
bad the user's impact from mobo swap (OS PnP, activation etc.) is way
higher than if it was just the CPU that needed replacement.

In this sense, I'd think of the current overload effect that can
happen when today's mobos meet tomorrow's RAM densities. If that
fries the memory controller, Intel would rather have that as the
motherboard vendor's problem rather than a CPU warranty swap..

>>But even with the larger case design that has horizontal PSU above the
>>mobo, I still see heat issues. As a non-overclocker who generally
>>uses modest (Celeron) chips with boxed fans that have been fine until
>>now, I'm surprised to see these sort of heat problems.

>Have you tried updating the BIOS on this board? Just a thought, but I
>know a lot of these thermal sensors are VERY inaccurate and are really
>just taking a wild guess at temperature. Often time a manufacturer
>will have a bug in their temp sensor settings in the BIOS that causes
>incorrect temp readings?

Interesting; I haven't rolled those dice, but note the newer board
revs (up to -409, -405 being the Prescott-ready threshold) with
Prescott are running just as hot. Prescott Celeron may run 10C higher
than "old" Celeron, e.g. 57C rather than 47C, and Zone 2 is often only
5-10C behind. So; 47C, 37C is fine, but while 57C may be OK for
processor, 47C is less OK for Zone 2. I've seen Zone 2 crack 50C.

>Along the same lines, do things inside the case (and/or heatsinks)
>seem to be getting physically hot? 47C is pretty warm and should be
>noticeable if the ambient air is that warm.

Yes, a hand on the top back of case does feel hot :-)

>You might want to contact Intel tech support on this one. Chances are
>that if you have experienced this on a few boards than hundreds of
>other people have as well. Intel may have a solution to this already.

I've found it difficult to find an Intel support socket to plug such
formless questions into. I had an Intel marketing droid do a
touch-base (as in "feel free to email me if any queries" ) but a
synopsis of these concerns brought no response.

Which is why I took my impressions here, to see whether I wasn't the
only one with such issues. It's a certain amount of work to fully
test and document an issue, and that's more difficult when several
boards exhibit flakiness that are not a "hangin' offence" but
nonetheless fall short of even PC Chips expectations.



>--------------- ----- ---- --- -- - - -
Dreams are stack dumps of the soul
>--------------- ----- ---- --- -- - - -

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Thu, 09 Dec 2004 01:09:43 +0200, "cquirke (MVP Win9x)"
<cquirkenews@nospam.mvps.org> wrote:

>On Wed, 08 Dec 2004 00:19:58 -0500, Tony Hill
>>On Mon, 06 Dec 2004 20:35:07 +0200, "cquirke (MVP Win9x)"
>
>>It may simply be that this model of board is a bad design, not just
>>one sample of the board. If the problems are one of design, than that
>>is entirely possible.
>
>Yep, could be - it gets rev'd enough, tho so far the baddies haven't
>all been of one particular -40x rev. Saw another one today; system is
>fine except it locks on POST after reset; after ATX power cycle, POSTs
>fine, etc. Same PSU and other goodies as usual.

The basic thing I would take away from this is just to avoid Intel
motherboards. I've never been much of a fan, more expensive but
without any improvement in quality. In this case it seems to be a
drop in quality. These days I mostly recommend MSI for good quality
and price, though I've had ok luck with the bargain-basement Chaintech
board I have now (bought it on a whim because it was dirt-cheap).

>>That's the real question now isn't it.. The extra L2 cache counts for
>>about 30-35M transistors (6 transistors per bit, 9 bits per bit due to
>>ECC and 512KBytes + some redundancy). Others are just used for
>>testing and not actually enabled for normal use.
>
>Aha! Think software that's more bloated but more reliable because
>it's agregated from hi-level blocks, and think post-manufacturing
>bugfixing CPUs via microcode pushed by BIOS or OS.
>
>Think XP SP2 vs. Prescott issue, where a Prescott (or P4-EE) left at
>Microcode rev 0 by BIOS cause SP2's Update.sys to lock up.
>
>( http://cquirke.mvps.org/sp2intel.htm refers)
>
>I expect some "slackness" where some stuff is left generalized a la
>programmable logic array, to be comitted via microcode?

To a certain extent yes, though the same is true for older P4's and
the PIIIs before it.

>>In the end though, it still seems like a LOT of extra transistors
>>given the nearly non-existent performance gains (an occasional
>>performance loses).
>
>On "losses", are you referring to the deeper pipelines?

Yup. There may be some other situations where you could take a
performance hit, but the longer pipeline is the big one.

>>> Does HT take up so many trannies?
>>> If so, how does that affect no-HT Celeron?
>
>>AFAIK the Celeron uses the exact same core, just with hyperthreading
>>disabled.
>
>Bloody typical - no wonder Intel pushes P4 so hard, it's money for jam

Market segmentation. It's the magick behind Intel's profits.

>>AMD's Athlon64 die has less than twice as many transistors as
>>the AthlonXP and it saw a fairly measurable improvement in
>>performance. Admittedly that was mostly due to integrating the memory
>>controller, but that simply raises the question of "why didn't Intel
>>do that?!"... but I suppose that's another discussion that's already
>>going on in this newsgroup :>
>
>Intel's been a bit sly in shoving their problems onto other ppl, e.g.
>
>1) BIOS to maintain and push microcode update revs - how many
>"required BIOS updates" are actually CPU hotfixes? As it is, the
>"blame" for SP2 vs. Prescott has been dumped on motherboard and BIOS
>vendors, whereas a date check on Intel's own mobo Prescott readiness
>(esp. when in-channel stock versions are also checked) is interesting.

Hmm.. I hadn't seen that one before. It does seem like the sort of
thing that really should have been fixed by the motherboard vendors
with a BIOS update, after all revision 0 is REALLY early on in the
development process and they had probably updated it before the chips
ever shipped. This would be more an issue with people upgrading older
motherboards to new processors without first updating their BIOS,
which is always hit-and-miss.

Of course, the article linked above with a bit light on tech details,
and I couldn't really find just what the actual cause of the error
was.

>2) Pins on mobo instead of CPU; if the pins bend, it's the mobo
>vendor's problem, and that may be another Intel mobo chipset sold
>(seeing as Intel won't have to cough that up as warranty fix). Too
>bad the user's impact from mobo swap (OS PnP, activation etc.) is way
>higher than if it was just the CPU that needed replacement.

Fortunately this has turned out to be pretty much a non-issue. It
seems like this might actually be less likely to end up with bent pins
on the motherboard than on the processor.

>In this sense, I'd think of the current overload effect that can
>happen when today's mobos meet tomorrow's RAM densities. If that
>fries the memory controller, Intel would rather have that as the
>motherboard vendor's problem rather than a CPU warranty swap..

Hmm.. I think you might be digging a bit too hard for conspiracy
theories on this one, I don't think I've ever heard of memory
densities overloading a memory controller.

>>Have you tried updating the BIOS on this board? Just a thought, but I
>>know a lot of these thermal sensors are VERY inaccurate and are really
>>just taking a wild guess at temperature. Often time a manufacturer
>>will have a bug in their temp sensor settings in the BIOS that causes
>>incorrect temp readings?
>
>Interesting; I haven't rolled those dice, but note the newer board
>revs (up to -409, -405 being the Prescott-ready threshold) with
>Prescott are running just as hot. Prescott Celeron may run 10C higher
>than "old" Celeron, e.g. 57C rather than 47C, and Zone 2 is often only
>5-10C behind. So; 47C, 37C is fine, but while 57C may be OK for
>processor, 47C is less OK for Zone 2. I've seen Zone 2 crack 50C.

The fact that the chips run hotter doesn't seem all that unusual,
though it does seem pretty hot for the ambient air around the chip to
be so hot. Normally with decent airflow you can keep the inside of a
case pretty cool without much difficulties.

>>You might want to contact Intel tech support on this one. Chances are
>>that if you have experienced this on a few boards than hundreds of
>>other people have as well. Intel may have a solution to this already.
>
>I've found it difficult to find an Intel support socket to plug such
>formless questions into. I had an Intel marketing droid do a
>touch-base (as in "feel free to email me if any queries" ) but a
>synopsis of these concerns brought no response.

Sadly this seems to be pretty much the norm these days. Unfortunately
customers (in general) just are not willing to pay for support, so any
company that tries to offer decent support either has to drop such
notions or goes out of business.

>Which is why I took my impressions here, to see whether I wasn't the
>only one with such issues. It's a certain amount of work to fully
>test and document an issue, and that's more difficult when several
>boards exhibit flakiness that are not a "hangin' offence" but
>nonetheless fall short of even PC Chips expectations.

Well, I'm afraid I'm out of ideas on this one. I haven't worked with
the board, so I don't really know any specifics about it.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Fri, 10 Dec 2004 01:05:13 -0500, Tony Hill
>On Thu, 09 Dec 2004 01:09:43 +0200, "cquirke (MVP Win9x)"
>>On Wed, 08 Dec 2004 00:19:58 -0500, Tony Hill
>>>On Mon, 06 Dec 2004 20:35:07 +0200, "cquirke (MVP Win9x)"

>The basic thing I would take away from this is just to avoid Intel
>motherboards. I've never been much of a fan, more expensive but
>without any improvement in quality.

That was my take, too; I used to prefer generic motherboards based on
Intel chipsets. What changed was a rash of capacitor failures across
a wide range of generic motherboards (Gigabyte, Jetway, DFI), plus
that Intel-branded motherboards dropped into the same price range as
the generics, plus their BIOS became less ideosyncratic.

>>>The extra L2 cache counts for about 30-35M transistors (6
>>>transistors per bit, 9 bits per bit due to ECC and 512KBytes
>>>+ some redundancy). Others are just used for testing and
>>>not actually enabled for normal use.

>>Aha! Think software that's more bloated but more reliable because
>>it's agregated from hi-level blocks, and think post-manufacturing
>>bugfixing CPUs via microcode pushed by BIOS or OS.

>>I expect some "slackness" where some stuff is left generalized a la
>>programmable logic array, to be comitted via microcode?

>To a certain extent yes, though the same is true for older P4's and
>the PIIIs before it.

I'm thinking that the trend is increasing, perhaps. A bit like the
way MS Office bloated up between '95 and '2000.

>>Intel's been a bit sly in shoving their problems onto other ppl, e.g.

>>1) BIOS to maintain and push microcode update revs - how many
>>"required BIOS updates" are actually CPU hotfixes? As it is, the
>>"blame" for SP2 vs. Prescott has been dumped on motherboard and BIOS
>>vendors, whereas a date check on Intel's own mobo Prescott readiness
>>(esp. when in-channel stock versions are also checked) is interesting.

>Hmm.. I hadn't seen that one before. It does seem like the sort of
>thing that really should have been fixed by the motherboard vendors
>with a BIOS update, after all revision 0 is REALLY early on in the
>development process and they had probably updated it before the chips
>ever shipped. This would be more an issue with people upgrading older
>motherboards to new processors without first updating their BIOS,
>which is always hit-and-miss.

It's more a matter of motherboard vendors trying to ship
Prescott-ready motherboards before Prescott itself was ready, perhaps.
We've seen this before; remember how some P55C-ready mobos would
wobble the clock speed on iP55C-233, because Intel changed the
electrical behavior of the 200/233MHz jumper? AFAICR what was pull-up
became pull-down, so if the mobo elecronic logic was same as iP54C,
the actual logic (voltage) level was left floating.

The question is: How soon/late did Intel finalize the microcode
revision level(s), and how effectively were these requirements
communicated to motherboard vendors?

One way to see into that, is to look at Intel's own mobo and BIOS revs
in Bayfield, and compare that to what was in the distributor's stock
at the time that Prescott started shipping here. I fed those details
to MS at the time of the SP2 vs. Prescott crisis, but can't remember
them now offhand - but I remember that even after Prescott was
standard, I'd still get served a Prescott-unready mobo rev at times.

>Of course, the article linked above with a bit light on tech details

I wrote it more in terms of the OS perspective, rather than the
hardware perspective. Not a lot more detail came to light in my
dealings with MS on this; I approached MS, Intel and (in my case)
Jetway, and only MS really fed back any tech detail.

In fact, most of the detail is conjectured from observation :-(

If you do a search at Intel's site for "microcode", e.g. if you wanted
to know what each microcode rev actually fixed, etc. you hit nothing -
it's like the whole process doesn't exist. You get great .pdf on
their own BIOS revs, and processor steppings, and mobo revs too (which
is distinct from BIOS) but nil below the stepping level of detail.

>and I couldn't really find just what the actual cause of the error
>was.

You can pin it down to Update.sys, which is larger in SP2 than SP1 and
(since I wrote that article early in the saga) which is now confirmed
to push microcode to the processor.

Speculation to why this is necessary, is that SP2 includes DirectX 9c,
which in turn has new floating-point pixel shading stuff. My guess is
that this uses (if available) the new SIMD, which has to be
microcode-rev'd up to work properly. This is the only reason I can
think of, why a Service Pack should care about processor rev.

The reason DirectX 9c is in what is ostensibly a security-orientated
SP2, is likely connected to MS's support policy for "old" versions,
which is geared to SP levels and release dates. I suspect it suits
them to push the latest version of subsystems such as WMP, IE, DirectX
etc. into each SP so that old versions of these can drop off the
support and patching maintenance map.

Speculation as to why Update.sys should lock up, starts from whether
it revs a processor that doesn't need rev (I seem to recall it does
not). If not, then all you need to look for are reasons why the
microcode update should lock the PC - and I'd suspect some sort of
processor state reset that loses context, and thus makes further
processing impossible. I read on a Linux-orientated site that some
microcode revs shouldn't be pushed after POST, for this reason.

You're more hooked into hardware (I dropped out of here until I needed
to come back to ask this question; I've been more involved in OS and
anti-malware stuff lately) so if you can find detail, I'd love to
know. I'm not much of a web maintainer (once I write a page, I seldom
go back to revise it) but if what detail there is is wrong, I'll fix.

>>2) Pins on mobo instead of CPU; if the pins bend, it's the mobo
>>vendor's problem. Too bad the user's impact from mobo swap
>>(OS PnP, activation etc.) is way higher than if it was just the
>>CPU that needed replacement.

>Fortunately this has turned out to be pretty much a non-issue. It
>seems like this might actually be less likely to end up with bent pins
>on the motherboard than on the processor.

I really, really hope so. As it is, I see plenty of old Socket 7 etc.
mobos where the plastic hooks for the HS/fan clips broke off.

>>In this sense, I'd think of the current overload effect that can
>>happen when today's mobos meet tomorrow's RAM densities. If that
>>fries the memory controller, Intel would rather have that as the
>>motherboard vendor's problem rather than a CPU warranty swap..

>Hmm.. I think you might be digging a bit too hard for conspiracy
>theories on this one, I don't think I've ever heard of memory
>densities overloading a memory controller.

No, but what does happen is that certain combinations of motherboard
and RAM don't work due to such issues, and that goes back to i820 etc.
It's easier for Intel to say "you need a better mobo" than "our
processor can't do that". Then again, Intel is heading into
Centrino-style CPU/chipset integration; if the current approach (big
dies with more trannies) is to hold, something has to be found for all
those trannies to do. Else making CPUs could get easy enough for
general chip makers (e.g.. nVidia et al) to climb in.

>>>Have you tried updating the BIOS on this board? Just a thought

>>Interesting; I haven't rolled those dice, but note the newer board
>>revs (up to -409, -405 being the Prescott-ready threshold) with
>>Prescott are running just as hot. Prescott Celeron may run 10C higher
>>than "old" Celeron, e.g. 57C rather than 47C, and Zone 2 is often only
>>5-10C behind. So; 47C, 37C is fine, but while 57C may be OK for
>>processor, 47C is less OK for Zone 2. I've seen Zone 2 crack 50C.

>The fact that the chips run hotter doesn't seem all that unusual,
>though it does seem pretty hot for the ambient air around the chip to
>be so hot. Normally with decent airflow you can keep the inside of a
>case pretty cool without much difficulties.

I haven't seen stock processors cooking up like this since PII-300
maxed out the .35u range, and even then, the rest of the box didn't
cook up. Then again, case makers hadn't tried so hard to regain the
smalller pre-ATX size by crowding the PSU deeper into the box.

>>>You might want to contact Intel tech support on this one. Chances are
>>>that if you have experienced this on a few boards than hundreds of
>>>other people have as well. Intel may have a solution to this already.

>>I've found it difficult to find an Intel support socket to plug such
>>formless questions into. I had an Intel marketing droid do a
>>touch-base (as in "feel free to email me if any queries" ) but a
>>synopsis of these concerns brought no response.

>Sadly this seems to be pretty much the norm these days. Unfortunately
>customers (in general) just are not willing to pay for support, so any
>company that tries to offer decent support either has to drop such
>notions or goes out of business.

I think tech-level support is a cost-effective way for vendors to
tackle this; effectively helps them to pass the buck <g> At one time,
Intel was better at this than MS, but their program became more and
more "small print taketh away", plus they shifted from Q&A at meetings
to no-feedback marketing push, that I lost interest.

MS still does little to communicate directly with small-volume techs
such as myself, though I think what's available on their web site is
way better, but in my case the MVP thing's been very good. In fact,
better comms with techs and builders is one of the things I've pushed
for, where the program has offered the chance to do so.

I've always liked AMD but mistrusted the motherboard chipsets I'd be
forced to build with (SiS, VIA). Noting that AMD's motherboard
chipsets usually use VIA for half the work. Has anything improved
there? What's nVidia's nForce track record been like so far?



>------------ ----- --- -- - - - -
Drugs are usually safe. Inject? (Y/n)
>------------ ----- --- -- - - - -

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Thu, 09 Dec 2004 01:09:43 +0200, "cquirke (MVP Win9x)"
<cquirkenews@nospam.mvps.org> wrote:

>Think XP SP2 vs. Prescott issue, where a Prescott (or P4-EE) left at
>Microcode rev 0 by BIOS cause SP2's Update.sys to lock up.
>
>( http://cquirke.mvps.org/sp2intel.htm refers)

Thanks for the URL Chris - it's a good start point for SP2 troubles. OT
for this thread, but have you come across the print server problem with
SP2, where it exceeds the TCP/IP queue request count and purposely goes
into heavy delay?

I have it on a LAN Manager "print server" running Win95 (yeah I know
but....) - SP2 just seems to go to sleep when a print is attempted or even
a printer properties attempt. There doesn't seem to be a registry
paramater - the only "fix" I've seen is a patch to a system file, which is
a bit too ugly for my liking. Turning off the Firewall mitigates very
slightly but the count and action seem to be hard coded in.

Apparently it's breaking print servers from several mfrs but you'd think
that M$ would not break their own stuff even if it *is* legacy.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Fri, 10 Dec 2004 19:35:20 -0500, George Macdonald
>On Thu, 09 Dec 2004 01:09:43 +0200, "cquirke (MVP Win9x)"

>>( http://cquirke.mvps.org/sp2intel.htm refers)

>Thanks for the URL Chris - it's a good start point for SP2 troubles. OT
>for this thread, but have you come across the print server problem with
>SP2, where it exceeds the TCP/IP queue request count and purposely goes
>into heavy delay?

That sounds like the TCP/IP throttling issue; it usually impacts
peer-to-peer file sharing apps. The intention is to limit the
effectiveness of malware-infested PCs in spreading out malware.

It's a controversial measure, as you can imagine; several scenarios
that genuinely require that traffic are impacted. The fix is to
revert or patch tcpip.sys (I think); a Google on ...

XP SP2 TCP/IP throttling

....should pick up coverage of this. It does!

http://www.microsoft.com/technet/p [...] .mspx#EHAA

<paste>

Limited number of simultaneous incomplete outbound TCP connection
attempts

Detailed description

The TCP/IP stack now limits the number of simultaneous incomplete
outbound TCP connection attempts. After the limit has been reached,
subsequent connection attempts are put in a queue and will be resolved
at a fixed rate. Under normal operation, when applications are
connecting to available hosts at valid IP addresses, no connection
rate-limiting will occur. When it does occur, a new event, with ID
4226, appears in the system’s event log.

Why is this change important? What threats does it help mitigate?

This change helps to limit the speed at which malicious programs, such
as viruses and worms, spread to uninfected computers. Malicious
programs often attempt to reach uninfected computers by opening
simultaneous connections to random IP addresses. Most of these random
addresses result in a failed connection, so a burst of such activity
on a computer is a signal that it may have been infected by a
malicious program.

</paste>

http://www.broadbandreports.com/shownews/56054

http://www.atrevido.net/blog/defau [...] 2004-09-22

http://forum.osnn.net/archive/index.php/t-39958.html

>I have it on a LAN Manager "print server" running Win95 (yeah I know
>but....) - SP2 just seems to go to sleep when a print is attempted or even
>a printer properties attempt. There doesn't seem to be a registry
>paramater - the only "fix" I've seen is a patch to a system file, which is
>a bit too ugly for my liking. Turning off the Firewall mitigates very
>slightly but the count and action seem to be hard coded in.

Doesn't sound like it fits? How many PCs on the LAN? Remember there
are limits on incoming connections for "desktop" Windows:
- 10: Win95xx, 98xx, NT Workstation, Windows 2000 Pro, WinXP Pro
- 5: WinME, WinXP Home

>Apparently it's breaking print servers from several mfrs but you'd think
>that M$ would not break their own stuff even if it *is* legacy.

Actually, SP2 does break some previously-advocated strategies, but IMO
it's a good thing - because those strategies were fundamentally unsafe
in the first place. When IE4 was trying to cadge market from
Netscape, MS basically sold our heads on a platter to web devs; now
that there's anger at just what web devs are allowed to do behind our
back, SP2 sets about trying to stuff the genie back in the bottle.

The irony is, Netscape's lack of these risky functionalities is a big
factor in its comeback. Users like it because it does less (dangerous
stuff) - tho it has holes of its own, and when stress-tested with
invalid or exploitative IFrame etc. it's less solid than IE.



>------------------ ----- ---- --- -- - - - -
The rights you save may be your own
>------------------ ----- ---- --- -- - - - -

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Sat, 11 Dec 2004 20:51:20 +0200, "cquirke (MVP Win9x)"
<cquirkenews@nospam.mvps.org> wrote:

>On Fri, 10 Dec 2004 19:35:20 -0500, George Macdonald
>>On Thu, 09 Dec 2004 01:09:43 +0200, "cquirke (MVP Win9x)"
>
>>>( http://cquirke.mvps.org/sp2intel.htm refers)
>
>>Thanks for the URL Chris - it's a good start point for SP2 troubles. OT
>>for this thread, but have you come across the print server problem with
>>SP2, where it exceeds the TCP/IP queue request count and purposely goes
>>into heavy delay?
>
>That sounds like the TCP/IP throttling issue; it usually impacts
>peer-to-peer file sharing apps. The intention is to limit the
>effectiveness of malware-infested PCs in spreading out malware.
>
>It's a controversial measure, as you can imagine; several scenarios
>that genuinely require that traffic are impacted. The fix is to
>revert or patch tcpip.sys (I think); a Google on ...
>
>XP SP2 TCP/IP throttling
>
>...should pick up coverage of this. It does!
>
>http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx#EHAA
>
><paste>
>
>Limited number of simultaneous incomplete outbound TCP connection
>attempts
>
>Detailed description
>
>The TCP/IP stack now limits the number of simultaneous incomplete
>outbound TCP connection attempts. After the limit has been reached,
>subsequent connection attempts are put in a queue and will be resolved
>at a fixed rate. Under normal operation, when applications are
>connecting to available hosts at valid IP addresses, no connection
>rate-limiting will occur. When it does occur, a new event, with ID
>4226, appears in the system’s event log.
>
>Why is this change important? What threats does it help mitigate?
>
>This change helps to limit the speed at which malicious programs, such
>as viruses and worms, spread to uninfected computers. Malicious
>programs often attempt to reach uninfected computers by opening
>simultaneous connections to random IP addresses. Most of these random
>addresses result in a failed connection, so a burst of such activity
>on a computer is a signal that it may have been infected by a
>malicious program.
>
></paste>
>
>http://www.broadbandreports.com/shownews/56054
>
>http://www.atrevido.net/blog/default.aspx?date=2004-09-22
>
>http://forum.osnn.net/archive/index.php/t-39958.html

Yeah that's it - it's been discussed in various places but the problem is
there is no fix! I haven't looked at his details yet because I'm not real
happy with a 3rd party code patch but http://www.lvllord.de/ has it - only
thing I've found so far.

>>I have it on a LAN Manager "print server" running Win95 (yeah I know
>>but....) - SP2 just seems to go to sleep when a print is attempted or even
>>a printer properties attempt. There doesn't seem to be a registry
>>paramater - the only "fix" I've seen is a patch to a system file, which is
>>a bit too ugly for my liking. Turning off the Firewall mitigates very
>>slightly but the count and action seem to be hard coded in.
>
>Doesn't sound like it fits? How many PCs on the LAN? Remember there
>are limits on incoming connections for "desktop" Windows:
> - 10: Win95xx, 98xx, NT Workstation, Windows 2000 Pro, WinXP Pro
> - 5: WinME, WinXP Home

What doesn't fit? This is our "downstairs printer" which two people use
and it's been working fine for years on our LAN, including with WinXP SP1
as a client. There's something about LAN Manager printing, possibly linked
to Lexmark's connection method, which causes a burst of TCP/IP packets...
which hits the limit. M$'s suggestion to "stop the application" is
asinine... because it's *their* application and there's no way to stop the
damned thing: right click on the printer icon and the bloody WinXP SP2
system goes into a coma. It *can't* be stopped... <tap><tap><tap>........