Intel engineer discusses their dual-core design

[Guest]

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

David Schwartz wrote:
> "keith" <krw@att.bizzzz> wrote in message
> news😛an.2005.08.26.02.02.30.696372@att.bizzzz...
>
>
>>On Wed, 24 Aug 2005 20:54:31 -0700, David Schwartz wrote:
>
>
>>>>Only because they couldn't. They *were* going to do an MCM.
>
>
>>> Which means that "dual core" must include an MCM.
>
>
>>Horse-hockey. "Two processors in a package" == dual core, must include
>>the IBM 3168 of thirty years ago, then. One package (as big as a
>>box-car), two processors. You Intel apologists are truely amazing.
>
>
> Why would you waste everyone's time with that type of stupidity. No
> definition is sufficiently precise to state, with no ambiguity, precisely
> what is and isn't covered by that definition.
>
>
>>>>>Second of all, a "dual core" is two processors in one physical
>>>>>package.
>
>
>>>>Are you always this stupid?
>
>
>>> Are you always this rude?
>
>
>>Rude? Perhaps. I prefer to think of it as terse. You *are* stupid, if
>>you buy into Intel's garbage.
>
>
> I have no idea what you're talking about.
>
>
>>>http://news.zdnet.com/2100-9584_22-5589445.html
>>>
>>> I can post dozens of other references that show that the phrase
>>> "dual
>>>core" can be used to refer to two CPUs in a single package, rather than
>>>on a single die.
>
>
>>Oh, wow! You can post all sorts of Intel propaganda. I'm truely amazed.
>
>
> Ahh yes, it must be a conspiracy. It can't be that you're wrong and
> everyone else is right. It must be that you're right and everyone else is
> stupid.
>
> DS
>
>
Well, I've been around for a pretty long time and I never heard "dual
core" apply to anything other than a single chip with two processor
cores on it. Dual Processor, sure. But "core" has always been a chip
concept.

del

--
Del Cecchi
"This post is my own and doesn’t necessarily represent IBM’s positions,
strategies or opinions.”

 

[Jack]

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

Felger Carbon <fmsfnf@jfoops.net> wrote:
: "David Schwartz" <davids@webmaster.com> wrote in message
: news:dem3dv$cs6$1@nntp.webmaster.com...
<snip>

:: Ahh yes, it must be a conspiracy. It can't be that you're
:: wrong and everyone else is right. It must be that you're right and
:: everyone else is stupid.
:
: It was just reported that the earth has a solid core that rotates
: inside a second, molten core at a different rate. That means the
: earth has a dual core in a single package, and (since our glorious
: leader believes in creationism) has had two cores for several
: thousand years before either Intel or AMD got around to it. ;-)

Oh, now that is just tooooo funny! LOL! :-O

j.

 

[Guest]

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

In comp.sys.ibm.pc.hardware.chips Felger Carbon <fmsfnf@jfoops.net> wrote:
> It was just reported that the earth has a solid core that
> rotates inside a second, molten core at a different rate.

The dual core has been known for 30+ years. The differing
rate (degrees per year) is the new discovery inferred from
inner (solid) core non-uniformities.

> That means the earth has a dual core in a single package,
> and (since our glorious leader believes in creationism)

Hmm ... I think you're stretching the bounds of sarcasm
to breaking. Who you consider your leader and what you consider
glory are personal matters. You ought not to presume "our".

-- Robert

 

[Guest]

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

keith wrote:
> On Thu, 25 Aug 2005 04:44:05 -0700, YKhan wrote:
>
>
>>Rob Stow wrote:
>>
>>>More anecdotal evidence: I build a few custom systems every
>>>month for friends, friends-of-friends, etc. 37 so far this year.
>>>
>>>A year ago about one third of the people wanted me to build P4 or
>>>Xeon systems for them. In the last 5 or 6 months I have not had
>>>one person ask for a P4 or Xeon box: everyone wanted Opterons
>>>or Athlon64s, except for one Pentium M and one AthlonFX.
>>
>>Opterons & Xeons? Are you building servers for friends of friends?
>
>
>
> ...and what is wrong with Opterons? Had one here for well over a year.
> Amazingly the price hasn't dropped.
>

A year already? Jesus! Seems like just yesterday you were
talking about buying the parts and putting it all together.

 

[keith]

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

On Fri, 26 Aug 2005 08:03:07 +0000, Felger Carbon wrote:

> "David Schwartz" <davids@webmaster.com> wrote in message
> news:dem3dv$cs6$1@nntp.webmaster.com...
>>
>> "keith" <krw@att.bizzzz> wrote in message
>> news😛an.2005.08.26.02.02.30.696372@att.bizzzz...
>>
> <big snip>
>
>> >> I can post dozens of other references that show that the
> phrase
>> >> "dual
>> >> core" can be used to refer to two CPUs in a single package,
> rather than
>> >> on a single die.
>>
>> > Oh, wow! You can post all sorts of Intel propaganda. I'm truely
> amazed.
>>
>> Ahh yes, it must be a conspiracy. It can't be that you're wrong
> and
>> everyone else is right. It must be that you're right and everyone
> else is
>> stupid.
>
> It was just reported that the earth has a solid core that rotates
> inside a second, molten core at a different rate. That means the
> earth has a dual core in a single package, and (since our glorious
> leader believes in creationism) has had two cores for several thousand
> years before either Intel or AMD got around to it. ;-)

Perhaps, but even the almighty Felger Carbon can't detect a .3-.5 degree
rise per year in a processor. Maybe you ought to go compare that with
your global-warming chickens. ;-)

--
Keith

 

[keith]

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

On Fri, 26 Aug 2005 14:10:42 +0000, Rob Stow wrote:

> keith wrote:
>> On Thu, 25 Aug 2005 04:44:05 -0700, YKhan wrote:
>>
>>
>>>Rob Stow wrote:
>>>
>>>>More anecdotal evidence: I build a few custom systems every
>>>>month for friends, friends-of-friends, etc. 37 so far this year.
>>>>
>>>>A year ago about one third of the people wanted me to build P4 or
>>>>Xeon systems for them. In the last 5 or 6 months I have not had
>>>>one person ask for a P4 or Xeon box: everyone wanted Opterons
>>>>or Athlon64s, except for one Pentium M and one AthlonFX.
>>>
>>>Opterons & Xeons? Are you building servers for friends of friends?
>>
>>
>>
>> ...and what is wrong with Opterons? Had one here for well over a year.
>> Amazingly the price hasn't dropped.
>>
>
> A year already? Jesus! Seems like just yesterday you were
> talking about buying the parts and putting it all together.

Yep, Time flies when you're having fun! ;-) It was all together in June
of last year. I still haven't gotten the SATA controller working under
Linux though, so have a 160GB drive sitting there warming the room.

--
Keith

 

[pankaj]

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

George Macdonald wrote:

>
> AMD's approach recently has been to target collaboration and sponsorship
> with high tech activities, mostly in some form of sports. I wonder how
> this is panning out: e.g. has the Lance Armstrong/Discovery Team connection
> been worth anything to them? How about the Sauber & Ferrari F1 connection?
> I don't watch NASCAR but that might be a more worthwhile avenue for their
> collaboration/sponsorship efforts in the U.S. market??
>
> --
> Rgds, George Macdonald

For AMD, its a step in the right direction, but I dont think they
should spend too much of their energy (and money) at this stage to make
it a brand name. (As Tony has mentioned above, to an average consumer,
it doesnt matter whats inside the computer. They buy Dell or HP or ...)
They should concentrate on getting market share while making money. I
think Hector Ruiz is doing a good job at it. He may not have gained any
market share as yet, but he sure has realized that he cannot gain it by
reducing the price 25% below Intels's, as Jerry tried to do. Intel
wants them to be around 15% market share irresepctive of the price.
Intel desperately wants AMD to be around, as they dont want to be
labelled a monopoly. Hector has realized these facts and if you have
noticed, the average price of the lower end chips (money losing) has
gone up over the last few years. Intel has been very shrewd in their
pricing strategy. They want AMD at 15%, but dont want them to make any
money, which can be used to stage a comeback anytime. Every dollar of
the cpu price is set to make sure that in the equation , AMD's
profitability is just around 0. And what cannot be done with price, it
is done with strong-arming OEMs. (I really dont want to start another
argument here

Regards,
Pankaj

 

[Guest]

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

Bill Davidsen <davidsen@deathstar.prodigy.com> wrote:
> Here's a more interesting question: Intel built the D/C chips on P4
> rather than P-M, presumably so they could offer the ht model at a huge
> premium.

Or because they had all the existing cache/bus arbitration logic designed
for the Netburst Xeon/Nocona which was not far off in design from the
P4/Prescott, whereas no such logic had yet been designed for the P-M.

> Given the low power and far better performance of the P-M in terms of
> work/watt and work/clock, why not a dual core Pentium-M? Then when the
> better P4 D/C chip is ready they could offer that?
>
> Just curious as to the logic for the decision if anyone has any insight.

Because it was much less design work and validation to do it with a
P4/Netburst core, I'd imagine.

--
Nate Edel http://www.cubiclehermit.com/

"I do have a cause, though. It is Obscenity. I'm for it." - Tom Lehrer

 

[Guest]

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

> My question then is:
> (1) The readers of this group are probably more tech savvy than average,
> so would you say that you have followed my downward opinion of Sony over
> the past 10 yrs?

Having had the chance to try a fair number of digital cameras over tha
last few years, in the $700-1200 range, including the top rated
Konica-Minolta, I will stick with Sony. My daughter does professional
photography as part of her job, and gets to use equipment bought with a
government budget (30 inch monitor type budget). She bought a Sony with
her own money, too.

Did a lot of shopping and wound up with a Sony camcorder as well, after
deciding on something else from specs and then trying both.

> (2) Now, going into the wider population, do you think Sony has fallen
> from a premium brand to just one among many?

That's harder to say, I get the impression that most people still
percieve them as one of the better brands.

--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com

 

[Guest]

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

> Yep, Time flies when you're having fun! ;-) It was all together in June
> of last year. I still haven't gotten the SATA controller working under
> Linux though, so have a 160GB drive sitting there warming the room.
>
I assume you're running a recent kernel, but 2.6.13 probes the PCI bus
itself instead of trusting the BIOS to do it (may be an option, it's
just out yesterday). Whatever came with FC4 found the controller in my
ASUS board, but I haven't put a drive on it, having a stock of fast PATA
left.

To address the original point YK raised, Intel still has the clear lead
in low power for mobile. And they spend more on research, so the
technical lead may be due to choosing a better direction than having
better people. Intel is likely to play a top game of catchup.

As for Intel offering a big discount to vendors who sell only Intel
CPUs, how is that different from Microsoft doing the same thing. I can't
buy a brand name laptop with Linux, and worse I have to pay for Windows
I never use. Nice that there are a few vendors who don't follow that
path, but they do cater to a niche market.

My next system will almost definitely be Intel dualie, but I have used a
fair number of AMD CPUs in the last few years, so it's not a brand
loyalty decision, just where I think I should go first.

--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com

 

[Guest]

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

Bernd Paysan wrote:
> Felger Carbon wrote:
>
>>Intel, in their Prescott line, understates the design power and gets
>>away with it because of thermal throttling. AMD, in their 90nm line,
>>_understates_ the design power (by a _considerable_ margin in my
>
> overstates
>
>
>>Sempron 754 2600+ CPUs) because they're still selling .13u parts for
>>big bucks. Now, the slow Sempron 754 parts are even available in
>>AMD64. I recommend them strongly. I know AMD sez 62W "design power",
>>but you'd need a downhill run and a tailwind and a 40W light bulb
>>helping to get anywhere near 62W.
>
>
> "Thermal Design Power" (TDP) is defined as the maximum amount of heat a
> cooler has to take away under defined conditions (given die temperature and
> air temperature). I.e. you define a temperature difference delta T, and a
> power P, and the cooler has to make sure that for a given P the delta T is
> met.
>
> AFAIK, AMD didn't change the TDP definition when going to 90nm, but they
> lowered the maximum temperature rating for their dies. So in reality, you
> have a lower delta T to reach, but with the given TDP (for cooler
> designers), they simply overstate the TDP, with the same effect. AMD also
> doesn't have thermal throttling, so the TDP really must fit into a
> worst-case szenario, while Intel allows programs like CPUburn to exceed the
> power - the idea is that in typical use, power bursts like that are short,
> and you can prevent damage by throttling.
>
> If you really need the CPU power to run long simulations/encodings/game
> sessions/whatever, and you buy Intel, then you also need a cooler that can
> handle more than Intel asks.
>
That's exceptionally well stated. It also is a clear explanation of
throttling benefits and performance issues, which could help people make
a brand decision.

--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com

 

[Guest]

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

On Tue, 30 Aug 2005 17:50:18 GMT, Bill Davidsen
<davidsen@deathstar.prodigy.com> wrote:

>Bernd Paysan wrote:
>> Felger Carbon wrote:
>>
>>>Intel, in their Prescott line, understates the design power and gets
>>>away with it because of thermal throttling. AMD, in their 90nm line,
>>>_understates_ the design power (by a _considerable_ margin in my
>>
>> overstates
>>
>>
>>>Sempron 754 2600+ CPUs) because they're still selling .13u parts for
>>>big bucks. Now, the slow Sempron 754 parts are even available in
>>>AMD64. I recommend them strongly. I know AMD sez 62W "design power",
>>>but you'd need a downhill run and a tailwind and a 40W light bulb
>>>helping to get anywhere near 62W.
>>
>>
>> "Thermal Design Power" (TDP) is defined as the maximum amount of heat a
>> cooler has to take away under defined conditions (given die temperature and
>> air temperature). I.e. you define a temperature difference delta T, and a
>> power P, and the cooler has to make sure that for a given P the delta T is
>> met.
>>
>> AFAIK, AMD didn't change the TDP definition when going to 90nm, but they
>> lowered the maximum temperature rating for their dies. So in reality, you
>> have a lower delta T to reach, but with the given TDP (for cooler
>> designers), they simply overstate the TDP, with the same effect. AMD also
>> doesn't have thermal throttling, so the TDP really must fit into a
>> worst-case szenario, while Intel allows programs like CPUburn to exceed the
>> power - the idea is that in typical use, power bursts like that are short,
>> and you can prevent damage by throttling.
>>
>> If you really need the CPU power to run long simulations/encodings/game
>> sessions/whatever, and you buy Intel, then you also need a cooler that can
>> handle more than Intel asks.
>>
>That's exceptionally well stated. It also is a clear explanation of
>throttling benefits and performance issues, which could help people make
>a brand decision.

A little empirical observation will, however, reveal that AMD does not need
thermal throttling - an even better criterion for "brand decision".

--
Rgds, George Macdonald

 

[Guest]

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

On Tue, 30 Aug 2005 17:38:11 GMT, Bill Davidsen
<davidsen@deathstar.prodigy.com> wrote:

>> Yep, Time flies when you're having fun! ;-) It was all together in June
>> of last year. I still haven't gotten the SATA controller working under
>> Linux though, so have a 160GB drive sitting there warming the room.
>>
>I assume you're running a recent kernel, but 2.6.13 probes the PCI bus
>itself instead of trusting the BIOS to do it (may be an option, it's
>just out yesterday). Whatever came with FC4 found the controller in my
>ASUS board, but I haven't put a drive on it, having a stock of fast PATA
>left.
>
>To address the original point YK raised, Intel still has the clear lead
>in low power for mobile. And they spend more on research, so the
>technical lead may be due to choosing a better direction than having
>better people. Intel is likely to play a top game of catchup.

I think that point has been made ad nauseum here: Intel has allowed
marketroids to dictate technical directions & policy. Recent events would
indicate that Intel is determined to continue with "spin" as their
strategy.

>As for Intel offering a big discount to vendors who sell only Intel
>CPUs, how is that different from Microsoft doing the same thing.

Have you not read the AMD complaint? It's much more than volume discounts:
demands to OEMs for exclusivity with threats of non-delivery of product
already contracted; same thing for large distributors; stealing AMD systems
from a promotional event; bribing retailers, with whom they have no direct
business relationship, to exclude any AMD systems from shelf space.
There's a long list - sounds more like the Mob than an honest business.

--
Rgds, George Macdonald

 

[Guest]

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

On Tue, 30 Aug 2005 19:04:24 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:

>On Tue, 30 Aug 2005 17:50:18 GMT, Bill Davidsen
><davidsen@deathstar.prodigy.com> wrote:
>>> If you really need the CPU power to run long simulations/encodings/game
>>> sessions/whatever, and you buy Intel, then you also need a cooler that can
>>> handle more than Intel asks.
>>>
>>That's exceptionally well stated. It also is a clear explanation of
>>throttling benefits and performance issues, which could help people make
>>a brand decision.
>
>A little empirical observation will, however, reveal that AMD does not need
>thermal throttling - an even better criterion for "brand decision".

Under anything reassembling a typical situation, Intel processors
don't need thermal throttling either, even if you are running some
application that has CPU use pegged at 100% for long periods of time.
Intel's TDP numbers are rather pessimistic and there are VERY few
situations where actual power consumption ever exceeds that number,
even for just a short peak.

What's more, it's a sort of worst-case from the process standpoint.
As you probably know, processors of a giving speed grade and stepping
can and do have different power consumption figures for the same load.
Minor differences from the process side of things dictate this. And
finally, any normal cooler sold with Intel systems doesn't JUST meet
the specs with no room to spare, there is always at least a small
margin of error.

Long story short, if your processor is throttling, regardless of what
you're running on the PC, there's probably something wrong with your
setup. Either that or ambient temp is well above normal.

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

 

[Guest]

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

keith wrote:
> On Fri, 19 Aug 2005 15:28:58 +0000, Bill Davidsen wrote:
>
>
>>keith wrote:
>>
>>>On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>>>
>>>
>>>
>>>>http://www.macworld.com/news/2005/08/17/dualcore/index.php
>>>
>>>
>>>I simply found it an admission of how far (and for how long) their
>>>technological head is (and has been) up their corporate ass. Nine months
>>>in development isn't that big of a deal, given that the "cores" are
>>>already there. Years? Please! They don't simulate/verify in
>>>multi-processor environments? *Amazing*!
>>>
>>
>>If these cores are the desktop versions rather than Xeon, they were not
>>planned to be used in SMP, much less in dual core. I'd be interested to
>>get your spin on why they *would* test the desktop chip SMP.
>
>
> Spin? Like to load them words, eh? One reason to do SMP testing is that
> it's "easy" to test cache coherence with two processors. Two processors
> can bang the caches pretty hard against each other.

Not really, "spin" usually refers to how facts look from another
viewpoint, which is just what I was after. But if the chip has no SMP
logic, such testing would not be possible.
>
> Do you really think Intel has no SMP verification capabilities? Do they
> not "borrow" tools from one organization to another? There's more here
> than meets the eye. Someone dropped the ball, big time!

I really think the desktop P4 has no SMP capabilities, because they
would take real estate and need to be tested. Not features you want in
production.
>
>
>>Here's a more interesting question: Intel built the D/C chips on P4
>>rather than P-M, presumably so they could offer the ht model at a huge
>>premium. Given the low power and far better performance of the P-M in
>>terms of work/watt and work/clock, why not a dual core Pentium-M? Then
>>when the better P4 D/C chip is ready they could offer that?
>
>
> Absolutely. ...which makes the SMP verification issue even more
> strange.
>
>
>>Just curious as to the logic for the decision if anyone has any insight.
>
>
> Search me. I've given up trying to explain Intel's moves; too bizare.
>
In rethinking my question, I can see from a marketing point both HT and
64 bit are needed.

--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com

 

[keith]

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

On Tue, 30 Aug 2005 17:38:11 +0000, Bill Davidsen wrote:

>> Yep, Time flies when you're having fun! ;-) It was all together in June
>> of last year. I still haven't gotten the SATA controller working under
>> Linux though, so have a 160GB drive sitting there warming the room.
>>
> I assume you're running a recent kernel, > but 2.6.13 probes the PCI bus

2.65-7.155.29, according to "uname -a"

> itself instead of trusting the BIOS to do it (may be an option, it's
> just out yesterday). Whatever came with FC4 found the controller in my
> ASUS board, but I haven't put a drive on it, having a stock of fast PATA
> left.

I was quite dissapointed by SIL's lack of *working* SATA drivers, not to
mention Tyan's disinterest. I gave up and bought another 160GB PATA
drive.

> To address the original point YK raised, Intel still has the clear lead
> in low power for mobile. And they spend more on research, so the
> technical lead may be due to choosing a better direction than having
> better people. Intel is likely to play a top game of catchup.

They're focusing on mobile, there's no doubt there. At the same time
Intel is leaving the high performance market to AMD. I could kinda
figure that strategy, until it was quite clear taht Itanic hit the berg.
They've forfeited that market. ...to AMD from below, and IBM from above.

> As for Intel offering a big discount to vendors who sell only Intel
> CPUs, how is that different from Microsoft doing the same thing. I can't
> buy a brand name laptop with Linux, and worse I have to pay for Windows
> I never use. Nice that there are a few vendors who don't follow that
> path, but they do cater to a niche market.

1) It's not a discount. It's an exclusive deal. "Either you sell mine
*exclusively* or you get no deal." "Even if you sell only mine, you take
second banana to Mikey."

2) It's no different, in fact. That doesn't excuse Intel from strong-arm
tactics. BTW, the major reason I only went one generation (Win2K) with M$.

> My next system will almost definitely be Intel dualie, but I have used a
> fair number of AMD CPUs in the last few years, so it's not a brand
> loyalty decision, just where I think I should go first.

This makes no sense at all.

--
Keith

 

[keith]

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

On Tue, 30 Aug 2005 21:02:51 +0000, Bill Davidsen wrote:

> keith wrote:
>> On Fri, 19 Aug 2005 15:28:58 +0000, Bill Davidsen wrote:
>>
>>
>>>keith wrote:
>>>
>>>>On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>>>>
>>>>
>>>>
>>>>>http://www.macworld.com/news/2005/08/17/dualcore/index.php
>>>>
>>>>
>>>>I simply found it an admission of how far (and for how long) their
>>>>technological head is (and has been) up their corporate ass. Nine months
>>>>in development isn't that big of a deal, given that the "cores" are
>>>>already there. Years? Please! They don't simulate/verify in
>>>>multi-processor environments? *Amazing*!
>>>>
>>>
>>>If these cores are the desktop versions rather than Xeon, they were not
>>>planned to be used in SMP, much less in dual core. I'd be interested to
>>>get your spin on why they *would* test the desktop chip SMP.
>>
>>
>> Spin? Like to load them words, eh? One reason to do SMP testing is that
>> it's "easy" to test cache coherence with two processors. Two processors
>> can bang the caches pretty hard against each other.
>
> Not really, "spin" usually refers to how facts look from another
> viewpoint, which is just what I was after. But if the chip has no SMP
> logic, such testing would not be possible.

The logic *is* there, though perhaps not brought out to the user.
Regardless, Intel *has* SMP verification capability. The only
excuse for such a stupid statement is that Intel has NIH burried so far
up their ass that even the exec's can't wiff the nonsense. They *have*
the test-cases.

>> Do you really think Intel has no SMP verification capabilities? Do
>> they not "borrow" tools from one organization to another? There's more
>> here than meets the eye. Someone dropped the ball, big time!
>
> I really think the desktop P4 has no SMP capabilities, because they
> would take real estate and need to be tested. Not features you want in
> production.

Irrelevant. They have SMP test and verification capability. If they
needed it for dual-core, they didn't have to invent new material. To
suggest such is simply silly.

>>
>>>Here's a more interesting question: Intel built the D/C chips on P4
>>>rather than P-M, presumably so they could offer the ht model at a huge
>>>premium. Given the low power and far better performance of the P-M in
>>>terms of work/watt and work/clock, why not a dual core Pentium-M? Then
>>>when the better P4 D/C chip is ready they could offer that?
>>
>>
>> Absolutely. ...which makes the SMP verification issue even more
>> strange.
>>
>>
>>>Just curious as to the logic for the decision if anyone has any
>>>insight.
>>
>>
>> Search me. I've given up trying to explain Intel's moves; too bizare.
>>
> In rethinking my question, I can see from a marketing point both HT and
> 64 bit are needed.

HT is a bust. Everyone knew 64bits was needed five years ago. Intel
tried to derail x86 and go with Itanic only. AMD decided otherwise.
Where is Itanic?

--
Keith

 

[Guest]

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

keith <krw@att.bizzzz> writes:

>> To address the original point YK raised, Intel still has the clear lead
>> in low power for mobile. [...]

> They're focusing on mobile, there's no doubt there. At the same time
> Intel is leaving the high performance market to AMD.

I think one important change is that the laptop market (like high
performance) used to be a high margin area. Now that laptop prices
have really plummeted, and Intel's laptop lead isn't as exclusive as
its Xeon business used to be (sure, Centrino is nice, but you can
always put together something similar based on AMD), it seems highly
unlikely that it will give anything near the same margins.

-k
--
If I haven't seen further, it is by standing in the footprints of giants

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch,alt.folklore.computers (More info?)

Bill Davidsen <davidsen@deathstar.prodigy.com> writes:
> They sure have sold you that "you need 64 bit" hype, haven't they?
> That's why Intel couldn't use P-M, AMD convinced people it was
> necessary to have 64 bits. HT is a free way to get 15-30% more
> performance out of a CPU, if that's a bust I wish someone would bust
> my gas mileage.

however, kernel smp overhead has been notorious for adding 15-30%
overhead ... which can result in a wash.

from 30+ years ago ... there was a project to add a second i-stream to
370/195. the issue was that 195 drained the pipeline on branches and
most codes ran at around half pipeline and half peak thruput. the hope
was that 2nd i-stream could get close to double hardware thruput (for
wide-range of codes) ... more than enuf to compensate for any
incremental kernel overhead going to smp kernel.

it was never produced. originally 370/195 was targeted at national
labs. and numerical intensive supercomputer type stuff. however, it
started to see some uptake in the TPF market (transaction processing
facility ... the renamed ACP ... airline control program ... which in
addition to be being used in large airline res. systems ... was
starting to see some deployment in large financial transaction
networks, therefor its name change). the codes in this market segment
was much more commercial oriented ... so a 2nd thread/i-stream might
benefit the customers workload.

the high-end TPF financial transaction market was seeing some uptake
of 195 as growth from 370/168 (195 even running commercial codes at
half peak could still be around twice thruput of 168). a big stumbling
block was that TPF (operating system) didn't have SMP support and
didn't get SMP until after 3081 time-frame in the 80s (the 3081
product was smp only ... but eventually they were forced to produce a
reduced priced, single-cpu 3083 for the TPF market).

the other issue was that 3033 eventually showed up on the scene which
was nearly the thruput of half-peak 195 (about even on commercial
codes).

for some folklore drift sjr was still running 370/195 and made it
available to internal shops for numerical intensive operations.
however, the batch backlog could be extremely long. Somebody at PASC
claimed that they were getting 3month turn-arounds (they eventually
setup a background and checkpoint process on their own 370/145 that
would absorbe spare cycles offshift ... and started getting slightly
better than 3 month turn-around for the same job).

one of the applications being run by the disk division on research's
195 was air-bearing simulation ... working out the details for
floating disk heads. they were also getting relatively poor turn
around.

the product test lab across the street in bldg. 15 got an early 3033
engineering machine for use in disk/processor/channel product test.

the disk engineering labs (bldg 14) and the product test labs (bldg
15) had been running all their testing "stand-alone" ... scheduled
machine time for a single 'testcell" at a time. the problem was that
standard operating system tended to quickly fail in an environment
with a lot of engineering devices being tested (MVS had a MTBF of 15
minutes in this environment).

I had undertaken to rewrite the i/o supervisor making operating system
bullet proof so that they could concurrently test multiple testcells
w/o requiring dedicated, scheduled stand-alone machine time (and w/o
failing)
http://www.garlic.com/~lynn/subtopic.html#disk

when the 3033 went into bldg. 15, this operating system was up and
running and heavy concurrent product test was consuming something
under 4-5 percent of the processor. so we setup an environment to make
use of these spare cpu cycles. one of the applications we setup to
provide thousands of cpu hrs processing was air-bearing simulation (in
support of working out details for floating disk heads).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

 

[Guest]

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

keith wrote:
> On Tue, 30 Aug 2005 21:02:51 +0000, Bill Davidsen wrote:
>
>
>>keith wrote:
>>
>>>On Fri, 19 Aug 2005 15:28:58 +0000, Bill Davidsen wrote:
>>>
>>>
>>>
>>>>keith wrote:
>>>>
>>>>
>>>>>On Wed, 17 Aug 2005 12:48:25 -0700, YKhan wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>http://www.macworld.com/news/2005/08/17/dualcore/index.php
>>>>>
>>>>>
>>>>>I simply found it an admission of how far (and for how long) their
>>>>>technological head is (and has been) up their corporate ass. Nine months
>>>>>in development isn't that big of a deal, given that the "cores" are
>>>>>already there. Years? Please! They don't simulate/verify in
>>>>>multi-processor environments? *Amazing*!
>>>>>
>>>>
>>>>If these cores are the desktop versions rather than Xeon, they were not
>>>>planned to be used in SMP, much less in dual core. I'd be interested to
>>>>get your spin on why they *would* test the desktop chip SMP.
>>>
>>>
>>>Spin? Like to load them words, eh? One reason to do SMP testing is that
>>>it's "easy" to test cache coherence with two processors. Two processors
>>>can bang the caches pretty hard against each other.
>>
>>Not really, "spin" usually refers to how facts look from another
>>viewpoint, which is just what I was after. But if the chip has no SMP
>>logic, such testing would not be possible.
>
>
> The logic *is* there, though perhaps not brought out to the user.
> Regardless, Intel *has* SMP verification capability. The only
> excuse for such a stupid statement is that Intel has NIH burried so far
> up their ass that even the exec's can't wiff the nonsense. They *have*
> the test-cases.

You keep saying this, please post a picture of an Intel P4 desktop chip
with some arrows pointing to the SMP logic you state is present, or stop
making the claim. How can Intel have capability to verify a non-existant
feature? Or provide a link to an official Intel statement that the
capability for SMP is present in non-Xeon chips.
>
>
>>>Do you really think Intel has no SMP verification capabilities? Do
>>>they not "borrow" tools from one organization to another? There's more
>>>here than meets the eye. Someone dropped the ball, big time!
>>
>>I really think the desktop P4 has no SMP capabilities, because they
>>would take real estate and need to be tested. Not features you want in
>>production.
>
>
> Irrelevant. They have SMP test and verification capability. If they
> needed it for dual-core, they didn't have to invent new material. To
> suggest such is simply silly.

I say there are no capabilities to test and you say that's irrelevant,
Intel can still test them. Please clarify.
>
>
>>>>Here's a more interesting question: Intel built the D/C chips on P4
>>>>rather than P-M, presumably so they could offer the ht model at a huge
>>>>premium. Given the low power and far better performance of the P-M in
>>>>terms of work/watt and work/clock, why not a dual core Pentium-M? Then
>>>>when the better P4 D/C chip is ready they could offer that?
>>>
>>>
>>>Absolutely. ...which makes the SMP verification issue even more
>>>strange.
>>>
>>>
>>>
>>>>Just curious as to the logic for the decision if anyone has any
>>>>insight.
>>>
>>>
>>>Search me. I've given up trying to explain Intel's moves; too bizare.
>>>
>>
>>In rethinking my question, I can see from a marketing point both HT and
>>64 bit are needed.
>
>
> HT is a bust. Everyone knew 64bits was needed five years ago. Intel
> tried to derail x86 and go with Itanic only. AMD decided otherwise.
> Where is Itanic?
>
They sure have sold you that "you need 64 bit" hype, haven't they?
That's why Intel couldn't use P-M, AMD convinced people it was necessary
to have 64 bits. HT is a free way to get 15-30% more performance out of
a CPU, if that's a bust I wish someone would bust my gas mileage.

--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch,alt.folklore.computers (More info?)

keith <krw@att.bizzzz> writes:
> Wasn't the 3033 a 3168 on steriods? ...complete with dual I-streams?

303x machines were organized to use the 303x channel director.

the 370/158 had integrated channels ... i.e. the 158 engine was
shared between the microcode that executed 370 instructions and
the microcode that executed channel (I/O) programs.

for the 303x channel director they took the 370/158 and removed
the microcode that executed 370 instructions leaving just
the channel execution microcode.

a 3031 was a 370/158 remapped to use a channel director box
i.e. a 3031 was a 370/158 that had the channel program microcode
removed ... leaving the engine dedicated to executing the
370 instruction microcode.

in some sense a single processor 3031 was a two 158-engine smp system
.... but with one of the 158 engines dedicated to running 370
instruction microcode and the other processor dedicated to running the
channel program microcode.

a 3032 was a 370/168 modified to use the 303x channel director.

a 3033 started out being a 370/168 wiring diagram remapped to new chip
technology. the 168 chip technology was 4 circuits per chip. the 3033
chip technology was about 20% faster but had about ten times as many
circuits per chip. the initial straight wiring remap would have
resulted in the 3033 being about 20% faster than 168-3 (using only 4
cicuits/chip). somewhere in the cycle, there was a decision to
redesign critical sections of the machine to better utilize the higher
circuit density ... which eventually resulted in the 3033 being about
50% faster than the 168-3.

basic 3033 was single processor (modulo having up to three 303x
channel directors for 16 channels). you could get two-processor
(real) 3033 smp systems (not dual i-stream).

there was some internal issues with the 3031 being in competition with
4341 ... with the 4341 being significantly better price/performance.
A cluster of six 4341s also were cheaper than a 3033 also with much
better price/performance and higher aggregate thruput. Each 4341 could
have 16mbytes of real storage and 6channels for an aggregate of
96mbytes of real storage and 36 i/o channels. A single processor 3033
was still limited to 16 i/o channels and 16mbytes.

somewhat in recognition of the real stroage constraint on 3033 thruput
.... a hack was done to support 32mbytes of real storage even tho the
machines had only 16mbyte addressing. A standard page table entry had
16bits, 12bit page number (with 4k pages giving 24bit real storage
addrssing), 2 defined bits, and two undefined bits. The undefined bits
were remapped on the 3033 to be used in specifying real page
numbers. That allowed up to 14bit page number ... with 4k pages giving
up to 26bit real storage addressing (64mbytes). channel program idals
had been introduced with 370 ... allowing for up to 31bit real storage
addressing (even tho only 24bits were used). This allowed the
operating system to do page I/O into and out of storage above the
16mbyte line.

around the same time that the product test lab (bldg. 15) got their
3033, they also got a brand new engineering 4341 (for the same purpose
doing channel disk i/o testing). we could co-op the 4341 in much
the same way that the 3033 was co-oped. In fact, for a period of
time, I had better access to the 4341 for running tests than 4341
product people in endicott did; as a result I got asked to run some
number of benchmarks on the bldg. 15 4341 for the endicott 4341
product people. minor past refs:
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2002b.html#0 Microcode?
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002i.html#7 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#22 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#37 IBM was: CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#4 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2003.html#10 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof


some number of past posts on 303x channel director:
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/97.html#20 Why Mainframes?
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/2000c.html#69 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#21 S/360 development burnout?
http://www.garlic.com/~lynn/2000g.html#11 360/370 instruction cycle time
http://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002i.html#23 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002p.html#59 AMP vs SMP
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003g.html#32 One Processor is bad?
http://www.garlic.com/~lynn/2003.html#39 Flex Question
http://www.garlic.com/~lynn/2004d.html#12 real multi-tasking, multi-programming
http://www.garlic.com/~lynn/2004d.html#65 System/360 40 years old today
http://www.garlic.com/~lynn/2004e.html#51 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004f.html#21 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#50 Chained I/O's
http://www.garlic.com/~lynn/2004.html#9 Dyadic
http://www.garlic.com/~lynn/2004.html#10 Dyadic
http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor
http://www.garlic.com/~lynn/2004n.html#14 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005b.html#26 CAS and LL/SC
http://www.garlic.com/~lynn/2005d.html#62 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005h.html#40 Software for IBM 360/30
http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof


in the late 70s and early 80s, 4341 competed with and sold into the
same market segment as vax machines
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#9 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#10 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2002h.html#52 Bettman Archive in Trouble
http://www.garlic.com/~lynn/2002i.html#30 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#1 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2002k.html#3 misc. old benchmarks (4331 & 11/750)
http://www.garlic.com/~lynn/2003c.html#17 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#19 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#0 big buys was: Tubes in IBM 1620?
http://www.garlic.com/~lynn/2003d.html#33 Why only 24 bits on S/360?
http://www.garlic.com/~lynn/2003d.html#61 Another light on the map going out
http://www.garlic.com/~lynn/2003d.html#64 IBM was: VAX again: unix
http://www.garlic.com/~lynn/2003e.html#56 Reviving Multics
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003i.html#5 Name for this early transistor package?
http://www.garlic.com/~lynn/2003p.html#38 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2004f.html#39 Who said "The Mainframe is dead"?
http://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| questions
http://www.garlic.com/~lynn/2004.html#46 DE-skilling was Re: ServerPak Install via QuickLoad Product
http://www.garlic.com/~lynn/2004j.html#57 Monster(ous) sig (was Re: Vintage computers are better
http://www.garlic.com/~lynn/2004l.html#10 Complex Instructions
http://www.garlic.com/~lynn/2004m.html#59 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004m.html#63 RISCs too close to hardware?
http://www.garlic.com/~lynn/2004q.html#71 will there every be another commerically signficant new ISA?
http://www.garlic.com/~lynn/2005f.html#30 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#58 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#59 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005m.html#8 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#12 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#25 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005n.html#10 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#11 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#12 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#16 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#47 Anyone know whether VM/370 EDGAR is still available anywhere?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

 

[keith]

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

On Wed, 31 Aug 2005 10:33:25 +0200, Ketil Malde wrote:

> keith <krw@att.bizzzz> writes:
>
>>> To address the original point YK raised, Intel still has the clear lead
>>> in low power for mobile. [...]
>
>> They're focusing on mobile, there's no doubt there. At the same time
>> Intel is leaving the high performance market to AMD.
>
> I think one important change is that the laptop market (like high
> performance) used to be a high margin area. Now that laptop prices
> have really plummeted, and Intel's laptop lead isn't as exclusive as
> its Xeon business used to be (sure, Centrino is nice, but you can
> always put together something similar based on AMD), it seems highly
> unlikely that it will give anything near the same margins.

No argumennt here. The only "issue" is *may* be addressed by the
antitrust suits. Certainly AMD has shown itself to be able to com>

here. ...at least in the technical sense.


--
Keith

 

[keith]

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch,alt.folklore.computers (More info?)

On Wed, 31 Aug 2005 12:30:44 -0600, Anne & Lynn Wheeler wrote:

<snip>

> the other issue was that 3033 eventually showed up on the scene which
> was nearly the thruput of half-peak 195 (about even on commercial
> codes).

Wasn't the 3033 a 3168 on steriods? ...complete with dual I-streams?

> for some folklore drift sjr was still running 370/195 and made it
> available to internal shops for numerical intensive operations. however,
> the batch backlog could be extremely long. Somebody at PASC claimed that
> they were getting 3month turn-arounds (they eventually setup a
> background and checkpoint process on their own 370/145 that would
> absorbe spare cycles offshift ... and started getting slightly better
> than 3 month turn-around for the same job).

3mos? Wow. I had a friend that had a bank of '85s doing ASTAP (circuit
sim) for 72 hours at a crack over the weekends. His boss didn' tmuch like
the bill, but the "customer" (internal) wanted statistical tranisent runs.
....something today that could be done on this computer with some
version of Spice nin a few hours, no doubt.


> one of the applications being run by the disk division on research's 195
> was air-bearing simulation ... working out the details for floating disk
> heads. they were also getting relatively poor turn around.
>
> the product test lab across the street in bldg. 15 got an early 3033
> engineering machine for use in disk/processor/channel product test.

....and you swiped it. ;-) Aside: I worked on the 3033.

> the disk engineering labs (bldg 14) and the product test labs (bldg 15)
> had been running all their testing "stand-alone" ... scheduled machine
> time for a single 'testcell" at a time. the problem was that standard
> operating system tended to quickly fail in an environment with a lot of
> engineering devices being tested (MVS had a MTBF of 15 minutes in this
> environment).

At least you didn't *smoke* 'em. Customers *hated* that. Execs seemed to
hat us for it. ;-)

<snip>

> when the 3033 went into bldg. 15, this operating system was up and
> running and heavy concurrent product test was consuming something under
> 4-5 percent of the processor. so we setup an environment to make use of
> these spare cpu cycles. one of the applications we setup to provide
> thousands of cpu hrs processing was air-bearing simulation (in support
> of working out details for floating disk heads).

You "stole" the CPU cycles. We had a ton of the systems on site, but they
were off-limits to users (customer machines can't be toyed with). Indeed
I killed one customer's ES9000. I pushed it over the power-on cycles
looking for an intermittent bug. My boss had to buy all the TCMs. He
wasn't happy, but they wouldn't buy (or rent) me a $10 logic analyzer
either. So we spent weeks tracking down the bug and a few more patching
it.

--
Keith

 

[Guest]

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

On Tue, 30 Aug 2005 20:52:54 -0400, Tony Hill <hilla_nospam_20@yahoo.ca>
wrote:

>On Tue, 30 Aug 2005 19:04:24 -0400, George Macdonald
><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>
>>On Tue, 30 Aug 2005 17:50:18 GMT, Bill Davidsen
>><davidsen@deathstar.prodigy.com> wrote:
>>>> If you really need the CPU power to run long simulations/encodings/game
>>>> sessions/whatever, and you buy Intel, then you also need a cooler that can
>>>> handle more than Intel asks.
>>>>
>>>That's exceptionally well stated. It also is a clear explanation of
>>>throttling benefits and performance issues, which could help people make
>>>a brand decision.
>>
>>A little empirical observation will, however, reveal that AMD does not need
>>thermal throttling - an even better criterion for "brand decision".
>
>Under anything reassembling a typical situation, Intel processors
>don't need thermal throttling either, even if you are running some
>application that has CPU use pegged at 100% for long periods of time.
>Intel's TDP numbers are rather pessimistic and there are VERY few
>situations where actual power consumption ever exceeds that number,
>even for just a short peak.
>
>What's more, it's a sort of worst-case from the process standpoint.
>As you probably know, processors of a giving speed grade and stepping
>can and do have different power consumption figures for the same load.
>Minor differences from the process side of things dictate this.

I thought that was what binning was for - any resulting difference should
be minimal... unless Intel is binning too close the ragged edge.

> And
>finally, any normal cooler sold with Intel systems doesn't JUST meet
>the specs with no room to spare, there is always at least a small
>margin of error.

Not what anecdotal evidence here is saying - just a coupla weeks ago we had
someone who could not get his P4 to quit throttling with the Intel
heatsink: dddu8t$2gh4$1@nef.ens.fr and the resolution:
ddlc3t$2hku$1@nef.ens.fr Now it's always possible that he did not fit
Intel's sink properly, *twice*... OTOH he had no trouble with the
Zalman.<shrug>

I'm sure Rob Stow has commented here about Intel's heaters, the inference
being that Intel is pushing the temp envelope to err, keep up.

>Long story short, if your processor is throttling, regardless of what
>you're running on the PC, there's probably something wrong with your
>setup. Either that or ambient temp is well above normal.

My processor is not throttling - it's an Athlon64 3500+🙂 and it's running
~15C below max temp at full load in a warmish 26C ambient. This is a real
load, FP an' all. Though I've no recent experience with Intel, the stories
that they are running closer to the thermal limits do seem to have some
substance.

--
Rgds, George Macdonald

 

[Guest]

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

keith wrote:
> On Wed, 31 Aug 2005 12:30:44 -0600, Anne & Lynn Wheeler wrote:
>
> <snip>
>
>>the other issue was that 3033 eventually showed up on the scene which
>>was nearly the thruput of half-peak 195 (about even on commercial
>>codes).
>
>
> Wasn't the 3033 a 3168 on steriods? ...complete with dual I-streams?

Story I heard was it was a card for card remap from MST into HPCL-F MS255.
snip

--
Del Cecchi
"This post is my own and doesn’t necessarily represent IBM’s positions,
strategies or opinions.”