4.0Ghz P4 now officially cancelled

[Guest]

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

keith wrote:
>> The 36-bit limit being reported as 40-bit is another one.
>
> It seems this is so stupid that Intel must not have been serious about
> AMD64 at all. Amazingly *stupid*.

I like to think of it as shade-tree engineering. Screw together some parts,
and fix the bugs as you use them. Worked for automotive hotrodders. 🙂

>> But as for the DMA MMU, I think that just an extension of Xeon's
>> 36-bit physical memory limitations problem.
>
> Wonderful, but my understanding that the I/O MMU was only 32b.
> Stupid! Come on Intel! This stuff is *simple*! One can speculate
> that they're trying to slow down AMD64 by *not* being fully
> compatable.

I don't know too much about this specific problem. I think it was sited as a
possible reason for why Intel's 64-bit performance was so abysmal compared
to AMD's. I don't think it's actually an errata in the Intel docs. It may be
simply speculation from some testers as the reason for Intel's slowness in
64-bit.

I can't even see a DMA issue being a problem with the CPU, I think it's got
more to do with the chipset. Afterall, DMA is used by peripherals, not
processors.

>> NX and size limit bug would probably mean that Microsoft won't even
>> bother to support 64-bit mode on those early CPUs, at least not
>> without a firmware upgrade.
>
> ...but will they (ever) support AMD64 on processors that work as
> expected?

You mean AMD64 processors in general or Intel's implementations of AMD64?

Yousuf Khan

 

[Guest]

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

Tony Hill wrote:
> On Tue, 19 Oct 2004 20:51:32 -0400, "Yousuf Khan" <bbbl67@ezrs.com>
> wrote:
>>
>> George Macdonald wrote:
>>> Is Intel's EM64T really considered incompatible? I thought they'd
>>> gotten
>>> it close enough that it was no hassle to OS or software developers.
>>> If things get delayed more, there's gonna be a bunch of workstation
>>> software vendors (and their customers) who are gonna be pissed.
>>> OTOH maybe that's their punishment for "decertifying" Itanium.🙂
>>
>> No, it's not considered incompatible -- in theory. It's just
>> considered buggy. Stuff doesn't work like it should sometimes.
>
> And this is different from every other processor on the planet how
> exactly? There are only a few errata out there, and most are fixable
> through a microcode update, the others can be worked around. There
> are some minor gotcha's that OS developers (and compiler writers to a
> lesser extend) will have to watch out for, but not really any
> different from 32-bit x86.

Well, I think George was asking whether the AMD64 and EM64T instruction sets
are really two different animals altogether: like an orangutan compared to a
gorilla. My opinion is that they're much closer than that, sort of like two
brothers from the same mother chimpanzee.

Yousuf Khan

 

[Guest]

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

On Wed, 20 Oct 2004 19:56:33 GMT, "AJ" <ng@newsgroups.net> wrote:

>
>"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message news:2ri8n0t5ol1naldood6ev0ddlqovdo9bk4@4ax.com...
>> On Mon, 18 Oct 2004 19:30:03 GMT, "AJ" <ng@newsgroups.net> wrote:

>>>The 3 motherboard temp sensors on my PC as I type this are 28, 26, 26 C.
>>>(I plan on slowing down or replacing my case fans though. They are 92 mm
>>>Zalmans that have the resistor inline causing them to turn at 1600 rpm, but
>>>I can still hear them so I'm going to try to find even slower fans, perhaps
>>>PWM ones and a controller). That's why I like Northwoods over Prescotts:
>>>I can get much closer to silent computing.
>>
>> I think you're placing far too much faith in temp readings from your mbrd's
>> BIOS.
>
>Why? I'm not doing a scientific comparison for a magazine.

You're quoting temperature numbers as though they are actually accurate
temperature readings - they're *not*.

>> The mbrd mfrs can calibrate them to read anything you want
>
>They seem to be consistent across different boards.

They're not necessarily so - they can vary across different BIOS versions.

>>- there
>> have been several cases where they have responded to user concerns of high
>> reported CPU temps by lowering them, in a later BIOS, to the point they
>> read lower than the mbrd "system temp".
>
>As long as they are measured the same way, it's fine. The readings are
>hardly useless. Quite useful actually.

I did *not* say they are useless... I hope you're not suggesting such!

>> The fact is that such readings are not useful as an absolute measure of
>> temperature - the only use they really have is for detecting changes in
>> general system/CPU thermal behavior.
>
>I think most people report those readings here though. Most people don't
>have scientifically thermocoupled systems! The relative readings were
>relevant for this thread (pretty much measured the same way and are
>probably fairly consistent from board to board. I've built a few (5) of them
>and they all turn out the same (except for the +10C Prescott).

As I said, they are useful as relative changes for any given mbrd+CPU... to
detect, e.g., loss of cooling efficiency or a failing fan... for that
system.

Rgds, George Macdonald

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

 

[Guest]

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

On Wed, 20 Oct 2004 19:57:30 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:

>Tony's experiences do
>not inspire confidence in them.
>
>Rgds, George Macdonald

As I said, Tony is FOS. I tested this supposed 100% cpu usage when
moving the mouse and on my system it never went above 7%. Do some
homework, the truth is out there, and Tony ain't God.

 

[Guest]

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

On Thu, 21 Oct 2004 01:15:57 -0400, Tony Hill
<hilla_nospam_20@yahoo.ca> wrote:


>No I'm not using the latest drivers because they don't work on my
>system.

They work for everyone else.

 

[Guest]

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

On Wed, 20 Oct 2004 19:57:30 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:


>Did I say that they are the same? Despite your gratuitous response, there
>*have* been many years between then and now, during which their reputation
>stayed in the gutter. They damned near came apart at the seams a couple of
>times in the meantime and their non-OEM policy was ill-conceived in the
>face of the market. If they have put such things behind them all the
>better - competition is good and benefits us all. Tony's experiences do
>not inspire confidence in them.
>
>Rgds, George Macdonald

p.s. you need to get out more. Go visit some of the gaming groups and
you will clearly see that you dinosaurs are living in the past.
Amazing for a group that is supposed to know their hardware. You guys
obviously know dick about video cards.

 

[Guest]

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

On Wed, 20 Oct 2004 21:47:05 -0400, "Yousuf Khan" <bbbl67@ezrs.com> wrote:

>George Macdonald wrote:
>> M$ has defined the BIOS call protocols and structures for all the
>> different ways of interfacing to it and hardware from an OS --
>> tables, real and protected mode calls -- so the calls still exist in
>> theory. Whether any
>> are still used is a big mystery to me. Since mbrd monitoring is not
>> something that M$ is terribly interested in I'm not sure what the
>> situation might be there in particular.
>
>These days, BIOS tends to be used once and only once, during the bootup.
>Unlike in the olden days of DOS where BIOS was more or less an integral part
>of the OS, and it was used continuously by both applications and OS calls.

There *is* *still* a specification from M$ which allows for the OS to
interact with the BIOS and its tables when required. Like I said, three
different mechanisms; I don't know if we have anyone who writes BIOS code
lurking here who can clear up what is the most commonly chosen method for
current systems with a working ACPI... if such a thing actually exists.🙂

>These days the BIOS sets up an initial "environment" for the OS. The OS
>reads the various BIOS environment parameters and adopts them as its own,
>but it implements the code internally in Protected Mode, and it is free to
>ignore them if it wants.

It *can* be done that way and is for most of the common hardware, e.g.
protected mode drivers take over from BIOS code, though the OS *will*
change BIOS parameter tables in the NVRAM - in fact when you specify PnP OS
in BIOS Setup, the BIOS does a minimal hardware config to the NVRAM tables
and defers most of the hardware detection to the OS.

Everyone (nearly everyone ? 🙂) has had mbrds where the NVRAM tables got
screwed up by Win98 and required a "PnP Reset: Enabled" in the BIOS Setup
to correct things. I can't say definitely that I've actually seen this
with Win2K or WinXP but I have had small niggles which got cleared up by a
Reset of PnP Data... especially when changing add-in cards.

>> Your use of capital letters for Motherboard Monitor seems to indicate
>> the product of that name, which I quit using a while back, so I've no
>> idea what kind of results it gives in the situation at hand. I was
>> referring to the use of the monitoring software which comes on the
>> CD-ROM with the mbrd package.
>
>Yes, I was referring to the Mobo Monitor program itself. Most of the
>prepackaged monitoring software that come with motherboards tend to agree
>with Mobo Monitor readings, and Mobo Monitor tends to agree with BIOS status
>screen readings for the most part too. So I would assume that there is a
>standard way to interpret the data coming out of these monitoring chips.

Given the contortions that MBM authors had to go to for different mbrds,
some with proprietary SuperIO chips, that seems like a pretty big
assumption to me.🙂

Rgds, George Macdonald

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

 

[Guest]

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

On Thu, 21 Oct 2004 12:27:45 -0700, Bruce Mckown <no@email.here> wrote:

>On Wed, 20 Oct 2004 19:57:30 -0400, George Macdonald
><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>
>>Tony's experiences do
>>not inspire confidence in them.
>>
>>Rgds, George Macdonald
>
>As I said, Tony is FOS.

In at least one of the NGs crossposted to, Tony has established credibility
- you don't... remarks like FOS do not enhance your err, reputation.<shrug>

> I tested this supposed 100% cpu usage when
>moving the mouse and on my system it never went above 7%. Do some
>homework, the truth is out there, and Tony ain't God.

There *could* be differences in configurations which account for the
divergence here. As already mentioned, ATI has in the past tried to lay
blame elsewhere.

Rgds, George Macdonald

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

 

[Guest]

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

On Thu, 21 Oct 2004 12:35:20 -0700, Bruce Mckown <no@email.here> wrote:

>On Wed, 20 Oct 2004 19:57:30 -0400, George Macdonald
><fammacd=!SPAM^nothanks@tellurian.com> wrote:
>
>
>>Did I say that they are the same? Despite your gratuitous response, there
>>*have* been many years between then and now, during which their reputation
>>stayed in the gutter. They damned near came apart at the seams a couple of
>>times in the meantime and their non-OEM policy was ill-conceived in the
>>face of the market. If they have put such things behind them all the
>>better - competition is good and benefits us all. Tony's experiences do
>>not inspire confidence in them.
>>
>>Rgds, George Macdonald
>
>p.s. you need to get out more. Go visit some of the gaming groups and
>you will clearly see that you dinosaurs are living in the past.
>Amazing for a group that is supposed to know their hardware. You guys
>obviously know dick about video cards.

Your allegiance to ATI is *very* touching my boy! Now, move along please.

Rgds, George Macdonald

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

 

[Guest]

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

On Thu, 21 Oct 2004 03:21:56 -0400, "Yousuf Khan" <bbbl67@ezrs.com> wrote:

>Tony Hill wrote:
>> On Tue, 19 Oct 2004 20:51:32 -0400, "Yousuf Khan" <bbbl67@ezrs.com>
>> wrote:
>>>
>>> George Macdonald wrote:
>>>> Is Intel's EM64T really considered incompatible? I thought they'd
>>>> gotten
>>>> it close enough that it was no hassle to OS or software developers.
>>>> If things get delayed more, there's gonna be a bunch of workstation
>>>> software vendors (and their customers) who are gonna be pissed.
>>>> OTOH maybe that's their punishment for "decertifying" Itanium.🙂
>>>
>>> No, it's not considered incompatible -- in theory. It's just
>>> considered buggy. Stuff doesn't work like it should sometimes.
>>
>> And this is different from every other processor on the planet how
>> exactly? There are only a few errata out there, and most are fixable
>> through a microcode update, the others can be worked around. There
>> are some minor gotcha's that OS developers (and compiler writers to a
>> lesser extend) will have to watch out for, but not really any
>> different from 32-bit x86.
>
>Well, I think George was asking whether the AMD64 and EM64T instruction sets
>are really two different animals altogether: like an orangutan compared to a
>gorilla. My opinion is that they're much closer than that, sort of like two
>brothers from the same mother chimpanzee.

Well no, I was just asking about specific differences which would, e.g.,
make common code in OS & driver writing or compiler code generation err,
difficult. It had been my impression so far that this would not be the
case. E.g. though the 36-bit limitation is a difference, it is not a
significant one in terms of addressable physical memory within the next few
years, IMO.

Rgds, George Macdonald

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

 

[Guest]

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

In comp.sys.ibm.pc.hardware.chips Bruce Mckown <no@email.here> wrote:
> As I said, Tony is FOS. I tested this supposed 100% cpu
> usage when moving the mouse and on my system it never
> went above 7%.

How do you know you have the same ATI card or drivers as Tony?
Or anywhere near the same MS-Windows setup? I accept both
of your experiences as valid.

> Do some homework, the truth is out there, and Tony ain't God.

No one said he is. But personally, I find him more believeable
than you. By a long shot.

-- Robert

 

[Guest]

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

George Macdonald wrote:
> Well no, I was just asking about specific differences which would,
> e.g., make common code in OS & driver writing or compiler code
> generation err, difficult. It had been my impression so far that
> this would not be the case. E.g. though the 36-bit limitation is a
> difference, it is not a significant one in terms of addressable
> physical memory within the next few years, IMO.

No, I don't think there's all that much difference that a few minor
if...then statements can't take care of. Now that is if we're assuming that
the Intel parts are acting exactly as their own documentation suggests that
they will work.

As for the 36-bit limitation, that's not any kind of instruction set problem
either. That's just a processor external feature. It's no different than in
the olden days when we had 386SX and 386DX, with the SX supporting only upto
24-bit physical memory, while the DX did the full 32-bits. The OS simply
polled the appropriate memory-size parameters found out how much physical
memory was actually installed on each machine and used whatever amount was
reported back.

Yousuf Khan

 

[Guest]

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

Bruce Mckown wrote:
> As I said, Tony is FOS. I tested this supposed 100% cpu usage when
> moving the mouse and on my system it never went above 7%. Do some
> homework, the truth is out there, and Tony ain't God.

Tony is well-known within these newsgroups. You are not.

That in itself shouldn't make any difference to us, usually we accept
anybody's assertion as within the realm of possibility, unless it's
completely impossible. However, it does make a difference how people conduct
themselves within the newsgroup: people's believability indexes go up or
down depending on whether they get hysterical about their assertions. Tony's
been known over the years to have a cool, reasoned character, IOW he has a
certain level of credibility. Somebody who comes in claiming someone else is
FOS, better have a good scientific reason to claim that. Emotionalism also
detracts from someone's credibility calculations, you might want to know.

Yousuf Khan

 

[keith]

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

On Thu, 21 Oct 2004 20:38:53 +0000, Robert Redelmeier wrote:

> In comp.sys.ibm.pc.hardware.chips Bruce Mckown <no@email.here> wrote:
>> As I said, Tony is FOS. I tested this supposed 100% cpu
>> usage when moving the mouse and on my system it never
>> went above 7%.
>
> How do you know you have the same ATI card or drivers as Tony?
> Or anywhere near the same MS-Windows setup? I accept both
> of your experiences as valid.
>
>> Do some homework, the truth is out there, and Tony ain't God.
>
> No one said he is. But personally, I find him more believeable
> than you. By a long shot.

Sure, given that we have something upwards of a decade of interaction
with Mr. Hill, I'd have to agree. ...even though he is Canuckistani. ;-)

--
Keith

 

[keith]

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

On Thu, 21 Oct 2004 22:10:23 -0400, Yousuf Khan wrote:

> George Macdonald wrote:
>> Well no, I was just asking about specific differences which would,
>> e.g., make common code in OS & driver writing or compiler code
>> generation err, difficult. It had been my impression so far that
>> this would not be the case. E.g. though the 36-bit limitation is a
>> difference, it is not a significant one in terms of addressable
>> physical memory within the next few years, IMO.
>
> No, I don't think there's all that much difference that a few minor
> if...then statements can't take care of. Now that is if we're assuming that
> the Intel parts are acting exactly as their own documentation suggests that
> they will work.
>
> As for the 36-bit limitation, that's not any kind of instruction set problem
> either. That's just a processor external feature. It's no different than in
> the olden days when we had 386SX and 386DX, with the SX supporting only upto
> 24-bit physical memory, while the DX did the full 32-bits. The OS simply
> polled the appropriate memory-size parameters found out how much physical
> memory was actually installed on each machine and used whatever amount was
> reported back.

Again, I have no first-hand information here, but it's my understanding
that Intel only supports a 36b hardware address, (xeon compatability), but
*reports* a full AMD64 (K8) 40b space. This screws the OS.

--
Keith

 

[keith]

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

On Thu, 21 Oct 2004 01:32:10 -0400, Tony Hill wrote:

> On Wed, 20 Oct 2004 19:41:56 GMT, "AJ" <ng@newsgroups.net> wrote:
>>
>>"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message news😱ol8n01joe7ibirjoebnfcajo61o9dufor@4ax.com...
>>> About
>>> the only bet is that you've got one number to call if a part dies
>>> instead of two, but I've never actually had a CPU die on me, and I
>>> know from my work that CPUs only die at a rate of about 1 for every
>>> 100 motherboards that blow (interesting bit of trivia, roughly 95% of
>>> all CPUs that are returned as defective are 100% functional), so this
>>> isn't really a big worry. Otherwise you've got one set of drivers to
>>> load and that's about it.
>>
>>I look at the MB/CPU (and chipset of course) as a unit. I wouldn't care if the
>>CPU was soldered on the
>>board (it would probably cheaper). I've never used a CPU from one system
>>in another (I don't think most stand alone system users have/would/do, though
>>the techies here probably do). Removability/replaceability is a good paradigm
>>for video cards, but for a CPU the cost/benefit is probably not worth it (?).
>>Maybe that should be for those priced-way-out-there "extreme" boards and
>>not for mainstream users who want low prices.
>
> The reason for socketed CPUs has absolutely nothing to do with
> end-users swapping CPUs around to various systems, or even for
> warranty replacement of such parts. The reason is because it would be
> TOTALLY unfeasible for the HPaqs and Dells of the world to have a
> whole separate set of stock for all the various speed grades and
> processor types that they might stick in any one motherboard. Dell
> based pretty much their entire business model around keeping low
> inventories, and soldering processors onto the board completely ruins
> that idea as far as processor/motherboards are concerned. End result,
> socket CPUs are *cheaper*, not more expensive, due to market factors
> beyond simple technical reasons.
>
> All that being said, it has absolutely zero to do with buying a
> motherboard, CPU and chipset all from one company vs. from three
> separate companies. If you don't mind my asking, just WHAT is it that
> you feel is a negative fact about buying a CPU, chipset and
> motherboard made from different companies?

Damn, Tony. You're much to kind. ;-)

--
Keith

 

[Guest]

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

"keith" <krw@att.bizzzz> wrote in message
news😛an.2004.10.22.02.42.45.161604@att.bizzzz...
> On Thu, 21 Oct 2004 22:10:23 -0400, Yousuf Khan wrote:
>
> Again, I have no first-hand information here, but it's my understanding
> that Intel only supports a 36b hardware address, (xeon compatability), but
> *reports* a full AMD64 (K8) 40b space. This screws the OS.
>
> --
> Keith
>
>

This is what I heard, in which case I guess the only fix would be to find
out if the chip is Intel or AMD and switch the address size based on that.
That would be a really ugly hack, but what else can you do if your CPU isn't
going to play nice and tell you how big it's address space really is?

Carlo

 

[Guest]

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

On Thu, 21 Oct 2004 20:38:53 GMT, Robert Redelmeier
<redelm@ev1.net.invalid> wrote:


>No one said he is. But personally, I find him more believeable
>than you. By a long shot.
>
>-- Robert
>

More the fool you then.

 

[Guest]

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

On Thu, 21 Oct 2004 22:35:12 -0400, keith <krw@att.bizzzz> wrote:


>Sure, given that we have something upwards of a decade of interaction
>with Mr. Hill, I'd have to agree. ...even though he is Canuckistani. ;-)

If Mr. Hill is so trusted in here then one would think he would use
the latest drivers, drivers that completely destoy his brand of
hogwash.

 

[Guest]

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

On Thu, 21 Oct 2004 17:32:58 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:


>
>In at least one of the NGs crossposted to, Tony has established credibility
>- you don't... remarks like FOS do not enhance your err, reputation.<shrug>

What credibility? The man was using agent drivers. You consider that
credibility? You lot are a bit dim and it's a good thing I don't waste
too much time with this news group.

 

[Guest]

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

On Thu, 21 Oct 2004 17:32:58 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:


>Your allegiance to ATI is *very* touching my boy! Now, move along please.

And here you show your complete ignorance, I have two PC's, one is
Nvidia equipped and the other is ATI equipped. Now what say you,
dumbass?

 

[AJ]

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

"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message news:0uudn010fpt7imulqbkg7354t7et32if69@4ax.com...
> On Wed, 20 Oct 2004 19:26:05 GMT, "AJ" <ng@newsgroups.net> wrote:
>
>>
>>"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
>>news:fkh8n0p69hjrjvohh8tcjgpt70me4s53nj@4ax.com...
>>> On Mon, 18 Oct 2004 19:05:50 GMT, "AJ" <ng@newsgroups.net> wrote:
>
>>> There is nothing about an AMD system which is frightening - maybe you
>>> should try it. As for Intel mbrds, there's no such thing any longer on the
>>> desktop... sub-contracted for even workstation class. From experience,
>>> your "compelling" solution buys you nothing really: with a recent chipset
>>> from any vendor, including Intel, you're going to have driver .INF files to
>>> load for Windows of any flavor or vintage.
>>>
>>> Hmm, you spout this religious dogma and then accuse people who suggest AMD
>>> of being zealots???õ_õ
>>
>>See, you're an AMD zealot because you (like that keith ranter) are trying to
>>pursuade me to try/buy AMD. All I did was tell you why I'm currently using
>>Intel and you both go off in a huff and try to impose your own personalities
>>on me. I don't give a sh@! what you use. I'm not trying to convince anyone,
>>but you zealots are. Get a grip and see yourselves!
>
> I dunno what it is with you iZombies - you miss what is being said and
> twist what people say to find non existent accusations and quarrels; you
> find anything non-Intel "frightening"; and you don't even have a clue about
> the origin of the parts you are buying... and so conjure up reasons for
> buying them.
>
> No, I know you are beyond persuading and when I said "maybe you should try
> it", what I was suggesting is that you have never in fact tried it and
> therefore have no reason for your irrational prejudices. I, OTOH, have
> tried both and make my *choice* accordingly - I came close to doing a P4
> system with Northwood, just so I'd have a direct, personal comparison, but
> no way will I be tempted to Prescott.
>
> To tell the truth, I don't give a wet fart what CPU, mbrd or whatever that
> *you* use but when you stick your head in the sand and spout your spurious
> dogma, people here will correct you. We'd hate for some poor lurker to get
> the impression that you actually know anything.
>
> Rgds, George Macdonald
>
> "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

Trying to turn the table huh. Sad. Why bother spouting YOUR AMD DOGMA in an
Intel group anyway? I'm just here trying to get info about the products I use and NOT
to get caught in your silly games. Just drop it already, seesh.

AJ

 

[Guest]

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

In comp.sys.ibm.pc.hardware.chips keith <krw@att.bizzzz> wrote:
> Sure, given that we have something upwards of a decade
> of interaction with Mr. Hill, I'd have to agree. ...even
> though he is Canuckistani. ;-)

Better the Devil you know ?

Look carefully -- he may live further South than you!

-- Robert

 

[Guest]

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

keith wrote:
>> As for the 36-bit limitation, that's not any kind of instruction set
>> problem either. That's just a processor external feature. It's no
>> different than in the olden days when we had 386SX and 386DX, with
>> the SX supporting only upto 24-bit physical memory, while the DX did
>> the full 32-bits. The OS simply polled the appropriate memory-size
>> parameters found out how much physical memory was actually installed
>> on each machine and used whatever amount was reported back.
>
> Again, I have no first-hand information here, but it's my
> understanding that Intel only supports a 36b hardware address, (xeon
> compatability), but *reports* a full AMD64 (K8) 40b space. This
> screws the OS.

Yeah, reporting 40-bits when you should only report 36-bits *is* a bug. But
it's a bug that I can only assume is easily correctible with a microcode
update. Besides, even if the processor reports 40-bits are addressable, the
OS works only with what is /actually installed/. Most systems would probably
only come with 36-bits of addressable memory installed.

Yousuf Khan

 

[AJ]

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

"keith" <krw@att.bizzzz> wrote in message news😛an.2004.10.21.02.16.40.204336@att.bizzzz...
> On Wed, 20 Oct 2004 19:41:56 +0000, AJ wrote:
>
>>
>> "Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message news😱ol8n01joe7ibirjoebnfcajo61o9dufor@4ax.com...
>>> On Mon, 18 Oct 2004 19:05:50 GMT, "AJ" <ng@newsgroups.net> wrote:
>>>> So now I know Intel and have no reason
>>>>to look elsewhere. If I was considering building an AMD system, I wouldn't
>>>>look at any other vendor for a motherboard than ASUS though. As far as I'm
>>>>concerned, AMD+ASUS is the platform there and there's no need to
>>>>evaluate the also-rans. Intel solution: CPU, chipset, motherboard by one
>>>>vendor. AMD solution: CPU, chipset, motherboard by two or three vendors.
>>>>The former is compelling. The latter is frightening. (It works for me!).
>>>
>>
>>> I've used both, and honestly the difference is pretty much nil.
>>
>> That statement has no value if you're trying to convince someone/anyone,
>> realize. (I've used both too).
>
> Gee, AJ. Wanna pissss offf any more of the knowledgeable in the group
> with your asinine comments. Hint: Tony's been around the block a few
> times. You *might* try learning, rather than bing a little prick.

Oh I'm so sorry I didn't realize that he was one of your gods (you little prick).
I'll make sure I bow next time (lol, not). You obviously think he needs you
to protect him, funny.

>
>>> About
>>> the only bet is that you've got one number to call if a part dies
>>> instead of two, but I've never actually had a CPU die on me, and I know
>>> from my work that CPUs only die at a rate of about 1 for every 100
>>> motherboards that blow (interesting bit of trivia, roughly 95% of all
>>> CPUs that are returned as defective are 100% functional), so this isn't
>>> really a big worry. Otherwise you've got one set of drivers to load
>>> and that's about it.
>>
>> I look at the MB/CPU (and chipset of course) as a unit. I wouldn't care
>> if the CPU was soldered on the board (it would probably cheaper).
>
> ...which shows that you haven't a *clue* about the PC market. What a
> maroon!

Kids! Can you even write one little sentence without personal attack in it?

>
>> I've never used a CPU from one system in another (I don't think most
>> stand alone system users have/would/do, though the techies here probably
>> do). Removability/replaceability is a good paradigm for video cards, but
>> for a CPU the cost/benefit is probably not worth it (?).
>
> Again, you haven't a clue what you're talking about. The PC market
> *demands* socketed motherboards, and not because of replacements. Think
> about it. If you need a further clue, perhaps one of the nice people here
> will fill you in. Though I have no idea why they would bother.

I'm putting you in your bin (the bozo bin). Bye! (Where do these creeps come
from?!).

AJ