4.0Ghz P4 now officially cancelled

Page 6 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Status
Not open for further replies.
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

keith wrote:
> I'm no OS type, but it's my understanding that it's far worse than not
> just not beiong able to "fully" populate the memory space. From what
> I've read it totally confuses the OS, even with less than 36b
> physical memory. People also don't believe you need 64b addressing
> until you go above 4GB physical.

Well, at 36-bits, you *will* go over 4GB, in fact you'll be able to go to
64GB with it.

But regardless, my original point was that Microsoft is probably now looking
at this list of errata and deciding which steppings of Nocona and Prescott
it's going to support for x64 mode. It may turn out that even if you have an
EM64T processor, depending on its stepping Windows x64 will refuse to run on
it. There might be a stepping below which Microsoft will say, "we don't have
time to fix all of your bugs -- no support for you." (in the Soup Nazi
style). So for example, they might say Stepping X1 or above of
Nocona/Prescott is the only steppings where we will boot up. And they might
say Stepping X0 is acceptable given certain BIOS revisions identify
themselves as having fixed the microcode on those steppings.

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

On Sat, 23 Oct 2004 13:28:12 +0000, Felger Carbon wrote:

> "keith" <krw@att.bizzzz> wrote in message
> news😛an.2004.10.23.01.34.19.337189@att.bizzzz...
>> On Fri, 22 Oct 2004 02:44:01 +0000, Robert Redelmeier wrote:
>>
>> > Look carefully -- he may live further South than you!
>>
>> Oh, my! That fact was decided here some years ago (pre
> Canuckistan),
>> when I made some comments about visiting "down" there (much to his
>> amazement). Mr. H does indeed live well below my latitude, as do
>> the upwards of 80% of Canuckistanis. ;-)
>
> Ahem. I recall the time I visited Detroit. Climbed into a boat, went
> due _south_ to Windsor, Canuckistan. Yes, south. Check a map. So
> there!

Yes, we also had that discussion at the time, along with the discussion
of the 17 "lower-48" having their northern-most point further North
than the southern-most point of Canuckistan. Where were you Felg?

If an airplane crashes on the border of the US and CA, where do they bury
the survivors?

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

keith wrote:
> Yes, we also had that discussion at the time, along with the
> discussion of the 17 "lower-48" having their northern-most point
> further North
> than the southern-most point of Canuckistan. Where were you Felg?

There are parts of California further north than the southernmost point in
Canada.

> If an airplane crashes on the border of the US and CA, where do they
> bury the survivors?

You don't bury survivors. 🙂

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

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message news:<aICdnVOQ9v-FBufcRVn-jQ@rogers.com>...
> keith wrote:
> > I'm no OS type, but it's my understanding that it's far worse than not
> > just not beiong able to "fully" populate the memory space. From what
> > I've read it totally confuses the OS, even with less than 36b
> > physical memory. People also don't believe you need 64b addressing
> > until you go above 4GB physical.
>
> Well, at 36-bits, you *will* go over 4GB, in fact you'll be able to go to
> 64GB with it.
>
> But regardless, my original point was that Microsoft is probably now looking
> at this list of errata and deciding which steppings of Nocona and Prescott
> it's going to support for x64 mode. It may turn out that even if you have an
> EM64T processor, depending on its stepping Windows x64 will refuse to run on
> it. There might be a stepping below which Microsoft will say, "we don't have
> time to fix all of your bugs -- no support for you." (in the Soup Nazi
> style). So for example, they might say Stepping X1 or above of
> Nocona/Prescott is the only steppings where we will boot up. And they might
> say Stepping X0 is acceptable given certain BIOS revisions identify
> themselves as having fixed the microcode on those steppings.
>
> Yousuf Khan


<Insert Microsoft conspiracy here> Just think they are now thinking
about marketing different versions of Windows.
http://www.techworld.com/opsys/news/index.cfm?NewsID=2355

Is Microsoft trying to push me to use Open Source, it sure looks like
it! Just think the Kernel now has support for dual core AMD CPU's.
http://lwn.net/Articles/106981/

I just wonder what changes need to be done to support dual cores with
Windows XP? It seems funny that just a few short years ago everyone
was complaining that Gnu/Linux had poor support for hardware. Now it
looks like it is leading the cause and is the only viable option.

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

On Sat, 23 Oct 2004 15:45:37 -0400, keith <krw@att.bizzzz> wrote:

>On Sat, 23 Oct 2004 13:28:12 +0000, Felger Carbon wrote:
>
>> "keith" <krw@att.bizzzz> wrote in message
>> news😛an.2004.10.23.01.34.19.337189@att.bizzzz...
>>> On Fri, 22 Oct 2004 02:44:01 +0000, Robert Redelmeier wrote:
>>>
>>> > Look carefully -- he may live further South than you!
>>>
>>> Oh, my! That fact was decided here some years ago (pre
>> Canuckistan),
>>> when I made some comments about visiting "down" there (much to his
>>> amazement). Mr. H does indeed live well below my latitude, as do
>>> the upwards of 80% of Canuckistanis. ;-)
>>
>> Ahem. I recall the time I visited Detroit. Climbed into a boat, went
>> due _south_ to Windsor, Canuckistan. Yes, south. Check a map. So
>> there!
>
>Yes, we also had that discussion at the time, along with the discussion
>of the 17 "lower-48" having their northern-most point further North
>than the southern-most point of Canuckistan. Where were you Felg?
>
>If an airplane crashes on the border of the US and CA, where do they bury
>the survivors?

Survivors? They get "buried" in Gitmo...
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
news:Scydnf7p5Mv0WefcRVn-2w@rogers.com...
> keith wrote:
> > If an airplane crashes on the border of the US and CA, where do
they
> > bury the survivors?
>
> You don't bury survivors. 🙂

Careful there, Yousuf. You and I don't bury survivors, but Keith
would if they top-posted! ;-)
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Sat, 23 Oct 2004 13:42:23 -0400, "Yousuf Khan" <bbbl67@ezrs.com> wrote:

>keith wrote:
>> I'm no OS type, but it's my understanding that it's far worse than not
>> just not beiong able to "fully" populate the memory space. From what
>> I've read it totally confuses the OS, even with less than 36b
>> physical memory. People also don't believe you need 64b addressing
>> until you go above 4GB physical.
>
>Well, at 36-bits, you *will* go over 4GB, in fact you'll be able to go to
>64GB with it.
>
>But regardless, my original point was that Microsoft is probably now looking
>at this list of errata and deciding which steppings of Nocona and Prescott
>it's going to support for x64 mode. It may turn out that even if you have an
>EM64T processor, depending on its stepping Windows x64 will refuse to run on
>it. There might be a stepping below which Microsoft will say, "we don't have
>time to fix all of your bugs -- no support for you." (in the Soup Nazi
>style). So for example, they might say Stepping X1 or above of
>Nocona/Prescott is the only steppings where we will boot up. And they might
>say Stepping X0 is acceptable given certain BIOS revisions identify
>themselves as having fixed the microcode on those steppings.

Hey it's deja-vu all over again... just like the 386 intro: chips marked
"For 16-bit mode only" and then *finally*, the famous "double sigma" chips
which worked right and even did paging properly.

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,comp.sys.intel (More info?)

On Sun, 24 Oct 2004 00:06:43 +0000, Felger Carbon wrote:

> "Yousuf Khan" <bbbl67@ezrs.com> wrote in message
> news:Scydnf7p5Mv0WefcRVn-2w@rogers.com...
>> keith wrote:
>> > If an airplane crashes on the border of the US and CA, where do
> they
>> > bury the survivors?
>>
>> You don't bury survivors. 🙂
>
> Careful there, Yousuf. You and I don't bury survivors, but Keith
> would if they top-posted! ;-)

He don't know me vewy well, do he? ;-)

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

George Macdonald wrote:
> Hey it's deja-vu all over again... just like the 386 intro: chips
> marked "For 16-bit mode only" and then *finally*, the famous "double
> sigma" chips which worked right and even did paging properly.

Oh yes, totally forgot about that situation. What were the problems with the
early 386's?

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

Hi,

"Yousuf Khan" <bbbl67@ezrs.com> wrote:
> But regardless, my original point was that Microsoft is probably now
looking
> at this list of errata and deciding which steppings of Nocona and Prescott
> it's going to support for x64 mode. It may turn out that even if you have
an
> EM64T processor, depending on its stepping Windows x64 will refuse to run
on
> it. There might be a stepping below which Microsoft will say, "we don't
have
> time to fix all of your bugs -- no support for you." (in the Soup Nazi
> style). So for example, they might say Stepping X1 or above of
> Nocona/Prescott is the only steppings where we will boot up. And they
might
> say Stepping X0 is acceptable given certain BIOS revisions identify
> themselves as having fixed the microcode on those steppings.

In general the information returned by CPUID from all CPUs shouldn't
be used directly. The (IMHO) correct method is to gather data from
CPUID, check for errors and then use the corrected information from
then on. This is the method my little OS uses - I had a fix for the
36/40 bit physical address bug (and the CMPXCHG16B bug) within
30 minutes of downloading Intel's errata.

Of the rest of the errata, a large amount won't ever effect anything
and the rest can be fixed by a micro-code update.

Besides, is there really any practical difference between a
computer with a perfect CPU where Windows crashes 300 times
a year and a computer with a slightly faulty CPU where Windows
crashes 301 times a year?


Cheers,

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

On Sun, 24 Oct 2004 17:32:05 +0000, Brendan Trotter wrote:

> Hi,
>
> "Yousuf Khan" <bbbl67@ezrs.com> wrote:
>> But regardless, my original point was that Microsoft is probably now
> looking
>> at this list of errata and deciding which steppings of Nocona and Prescott
>> it's going to support for x64 mode. It may turn out that even if you have
> an
>> EM64T processor, depending on its stepping Windows x64 will refuse to run
> on
>> it. There might be a stepping below which Microsoft will say, "we don't
> have
>> time to fix all of your bugs -- no support for you." (in the Soup Nazi
>> style). So for example, they might say Stepping X1 or above of
>> Nocona/Prescott is the only steppings where we will boot up. And they
> might
>> say Stepping X0 is acceptable given certain BIOS revisions identify
>> themselves as having fixed the microcode on those steppings.
>
> In general the information returned by CPUID from all CPUs shouldn't
> be used directly. The (IMHO) correct method is to gather data from
> CPUID, check for errors and then use the corrected information from
> then on. This is the method my little OS uses - I had a fix for the
> 36/40 bit physical address bug (and the CMPXCHG16B bug) within
> 30 minutes of downloading Intel's errata.

I'd disagree that that's the "proper" way, though it may be the
*necessary* way. Your "exceptios" list might get rather long, given
hundreds of different steppings of different processors.

Just because you patched "your" OS (patches are all ugly), doesn't mean
they're all going to be, or that all will. This sort of thing leads to
may disasters.

> Of the rest of the errata, a large amount won't ever effect anything and
> the rest can be fixed by a micro-code update.

It makes a mess. Erata is a given, but this stuff is ridiculous. It's not
like these things weren't hashed out before. Intel simply dropped the ball.

> Besides, is there really any practicaldifference between a computer
> with a perfect CPU where Windows crashes 300 times a year and a computer
> with a slightly faulty CPU where Windows crashes 301 times a year?

....or simply doesn't boot.

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

On Fri, 22 Oct 2004 01:04:34 -0700, Bruce Mckown <no@email.here>
wrote:
>
>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.

You'll be happy to know that on my new motherboard the problem I was
having with those new drivers does not happen. So, the issue would
seem to have been some sort of incompatibility between the motherboard
(or perhaps the SiS AGP GART) and the new ATI drivers.

That other motherboard has now been moved to a different system with a
different video card and running Linux, so I won't be able to look
into it any further.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Sun, 24 Oct 2004 15:52:25 -0400, "Yousuf Khan" <bbbl67@ezrs.com> wrote:

>George Macdonald wrote:
>> Hey it's deja-vu all over again... just like the 386 intro: chips
>> marked "For 16-bit mode only" and then *finally*, the famous "double
>> sigma" chips which worked right and even did paging properly.
>
>Oh yes, totally forgot about that situation. What were the problems with the
>early 386's?

Well good info wasn't quite so easy to come by back in those days but I
still have some notes I made to go with our software. According to info at
the time, the very first chips did not run 32-bit software at all and had
no marking on them to that effect. Later, in 1987 there was a run of chips
where there was a marking, which was in fact: "FOR 16-BIT S/W ONLY"; this
was related to what was known as "the 32-bit multiply bug". I tried our
software on such a system and it ran fine so I'd guess it was an
intermittent problem or some instruction combo which failed.

In early '88 the corrected chips, had two sigma characters on them but they
suffered from what was known as "the 386/387 lock-up problem" or "the
paging bug"... officially, "Erratum 21" (got that bit wrong above). It was
due to the bus interface, was present on 16 & 20MHz chips shipped up to
Summer '88 but did not happen on systems with the 82385 cache controller;
you could also work around it by running with paging turned off. I heard
of it happening on IBM PS/2 80s and Compaq 386/16s.

The Intel problems were resolved with Step D0 of the 80386 but remember
that back then, the memory sub-systems were proprietary so there could be
other problems: some of the early designs just stuck memory on the ISA bus
and ran like a dog. We also had a case where a user told everyone that our
shiny new 32-bit software ran slower than the 16-bit stuff - turned out it
was a problem with early IBM PS/2 80s and something to do with the MCA
running at half bus-width to the memory, IIRC. IBM eventually 'fessed up
and fixed things but it hurt us.

Then, of course, there was the 80486 and a whole new slew of problems,
which was compounded by the fact that the FPU was on the die and some of
the mbrd mfrs couldn't get the FP exception interrupt circuitry right. It
had to be external to the chip of course and I recall telling a mbrd mfr
tech which page to look at in the Intel 486 manual to see the recommended
diagram.🙂

Ironically, in todays terms with 64-bit mode on the table, I recall Intel's
stance wrt the 80486 was that hardly anybody needed it - it was for a very
few "power users" and that most would still be happy with a 386. IOW they
expected that they were going to continue selling 80386s for a while and
even had two new evolutions of the 386 cache controller in development,
which AFAIK never made it to market... plus ça change........🙂

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,comp.sys.intel (More info?)

Hi,

"keith" <krw@att.bizzzz> wrote:
> On Sun, 24 Oct 2004 17:32:05 +0000, Brendan Trotter wrote:
> > In general the information returned by CPUID from all CPUs shouldn't
> > be used directly. The (IMHO) correct method is to gather data from
> > CPUID, check for errors and then use the corrected information from
> > then on. This is the method my little OS uses - I had a fix for the
> > 36/40 bit physical address bug (and the CMPXCHG16B bug) within
> > 30 minutes of downloading Intel's errata.
>
> I'd disagree that that's the "proper" way, though it may be the
> *necessary* way. Your "exceptios" list might get rather long, given
> hundreds of different steppings of different processors.

Indeed - it's both unfortunate and necessary if you want your
software to work reliably.

> Just because you patched "your" OS (patches are all ugly), doesn't mean
> they're all going to be, or that all will. This sort of thing leads to
> may disasters.

If a lone programmer like me can have it patched in 30 minutes, then
a company like MS with 1000's of programmers should be able to
have it fixed 1000's of times faster - or in less than 1.8 seconds 🙂

> > Of the rest of the errata, a large amount won't ever effect anything and
> > the rest can be fixed by a micro-code update.
>
> It makes a mess. Erata is a given, but this stuff is ridiculous. It's not
> like these things weren't hashed out before. Intel simply dropped the
ball.

Intel have always published errata, and it's rare that any of it will
actually effect software. If you compare the list of errata for the
original Pentium (where not too much changed from 80486) to the
new ET64 errata (where an entire operating mode was added)
you may be surprised at how few problems there are this time
(especially considering the new stuff was probably added in a
hurry because AMD beat them to it).

The other CPU manufacturers also have errata, but often they
lack full disclosure and bugs have to be discovered (e.g. the
'tead' bug in some Cyrix chips).

Sure all the patching, etc does create a big mess, but for
80x86 based PC's it's nothing compared to the huge mess that
backwards compatibility has created. If you add both messes
together it's surprising that anything works.

> > Besides, is there really any practical difference between a computer
> > with a perfect CPU where Windows crashes 300 times a year and a computer
> > with a slightly faulty CPU where Windows crashes 301 times a year?
>
> ...or simply doesn't boot.

Considering that all CPUs have had errata and Microsoft has
never (intentionally) refused to boot on any of them, I think it
would be a safe assumption that if Microsoft did refuse to
boot it would be for political reasons rather than technical
ones.

I expect Microsoft's OS will detect if the CPU supports
64 bit, enable it and try to boot. If the computer has a
dodgy Intel chip and crashes, it would be up to Microsoft's
helpline to tell the customers to upgrade the CPU's
micro-code. Whether they add code to detect and patch
for the known faults or not I couldn't say.


Cheers,

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

On Mon, 25 Oct 2004 07:07:04 +0000, Brendan Trotter wrote:

> Hi,
>
> "keith" <krw@att.bizzzz> wrote:
>> On Sun, 24 Oct 2004 17:32:05 +0000, Brendan Trotter wrote:
>> > In general the information returned by CPUID from all CPUs shouldn't
>> > be used directly. The (IMHO) correct method is to gather data from
>> > CPUID, check for errors and then use the corrected information from
>> > then on. This is the method my little OS uses - I had a fix for the
>> > 36/40 bit physical address bug (and the CMPXCHG16B bug) within
>> > 30 minutes of downloading Intel's errata.
>>
>> I'd disagree that that's the "proper" way, though it may be the
>> *necessary* way. Your "exceptios" list might get rather long, given
>> hundreds of different steppings of different processors.
>
> Indeed - it's both unfortunate and necessary if you want your
> software to work reliably.

If it's *your*, or *my* software it's not a big deal. However, if it's a
*production* system, the testing and verification can become a nightmare.
These stupid things aren't taken lightly as in a scratch that only needs a
band-aid.

>> Just because you patched "your" OS (patches are all ugly), doesn't mean
>> they're all going to be, or that all will. This sort of thing leads to
>> may disasters.
>
> If a lone programmer like me can have it patched in 30 minutes, then a
> company like MS with 1000's of programmers should be able to have it
> fixed 1000's of times faster - or in less than 1.8 seconds 🙂

Sure, a hacker might be able to fix such problems in ten minutes, but
verifying hundreds or thousands of such issues gets to be a real problem.
Writing software is *easy*. Designing software is *hard*. Verifying
anything the above do is exhausting. Hackers only see the individual fix.

>> > Of the rest of the errata, a large amount won't ever effect anything
>> > and the rest can be fixed by a micro-code update.
>>
>> It makes a mess. Erata is a given, but this stuff is ridiculous. It's
>> not like these things weren't hashed out before. Intel simply dropped
>> the
> ball.
>
> Intel have always published errata, and it's rare that any of it will
> actually effect software.

<shrug>, sure. I've even had my hand in writing "eratta" a few times. In
this case it's not a "little thing". It's a *stupid* thing that creates
an unnecessary complication to the OS types. Most eratta doesn't depend
on processor stepping, and vendors will make sure future fixes don't break
the work-arounds. ...but whan you disregard the specs and report silly
answers, things get unnecessarily complicated.

> If you compare the list of errata for the
> original Pentium (where not too much changed from 80486) to the new ET64
> errata (where an entire operating mode was added) you may be surprised
> at how few problems there are this time (especially considering the new
> stuff was probably added in a hurry because AMD beat them to it).

"Added in a hurry" doesn't excuse extreme incompetence. Reporting the
right memory size is trivial. It's a constant, for bit's sake! ...no
different than a CPUID. DOn't tell me that Intel has such slopppy
verification techniques that this slipped by. If that's what you're
telliing me, tell me more!

> The other CPU manufacturers also have errata, but often they lack full
> disclosure and bugs have to be discovered (e.g. the 'tead' bug in some
> Cyrix chips).

tead? Perhaps I know it differently. SUre eratta is an issue, and not
normally a biggie, but (see above). An architectural flub like this
*should* be embarrasing. ...and will haunt the architecture forever (hmm,
accident?)

> Sure all the patching, etc does create a big mess, but for 80x86 based
> PC's it's nothing compared to the huge mess that backwards compatibility
> has created. If you add both messes together it's surprising that
> anything works.

So it's acceptable to unnecessarily add to the mess, "for old time's
sake"? This one was *DUMB*. Rushing *something* to market because you've
been caught with your knickers down, isn't an excuse. It leads people
to doubt your credibility - what else was missed?

>> > Besides, is there really any practical difference between a computer
>> > with a perfect CPU where Windows crashes 300 times a year and a
>> > computer with a slightly faulty CPU where Windows crashes 301 times a
>> > year?
>>
>> ...or simply doesn't boot.
>
> Considering that all CPUs have had errata and Microsoft has never
> (intentionally) refused to boot on any of them, I think it would be a
> safe assumption that if Microsoft did refuse to boot it would be for
> political reasons rather than technical ones.

We haven't seen Win-AMD64 yet, now have we?

> I expect Microsoft's OS will detect if the CPU supports 64 bit, enable
> it and try to boot. If the computer has a dodgy Intel chip and crashes,
> it would be up to Microsoft's helpline to tell the customers to upgrade
> the CPU's micro-code. Whether they add code to detect and patch for the
> known faults or not I couldn't say.

Microcode? SOme patches are possible, some not pretty, some impossible.
My bet is that the CPUID issue is so simple (ROM) that it's not
patchable. Of course the 32b DMA cannot be. The Intel architects should
be shot, and the verification types hung right behind them. What the hell
is Intel *doing*? ...other than intentionally trying to subvert AMD64.

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

On Sat, 23 Oct 2004 10:12:20 -0400, George Macdonald
<fammacd=!SPAM^nothanks@tellurian.com> wrote:


>Ach, but I wanted *him* to look up the word himself. You've spoiled the
>humiliation now and he'll claim it was his keyboard's fault... just like JC
>did.;-)... Hey ya don't think... it might be......
>
>Rgds, George Macdonald

Bah! I know it is supposed to be "ancient". You must be from the
planet Gorg where no one ever makes a mistake out of tiredness.
Screw you.
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Fri, 22 Oct 2004 15:26:16 -0400, "Yousuf Khan" <bbbl67@ezrs.com>
wrote:


>You know, you could've done so much to enhance your reputation in these
>newsgroups, just by being open-minded and asking questions about why people
>are having problems, instead of acting like a childish boob.
>
>I don't think that you have all that much credibility in video card
>newsgroups than you are demonstrating here. Must be why you're here, got
>tired of fending off the flames over there.
>
> Yousuf Khan
>

You could leave the safe cocoon of this news group and go check in the
ATI newsgroup for yourself. You lazy bastard.
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Fri, 22 Oct 2004 08:11:50 GMT, "Lee Waun" <leewaun@telus.net>
wrote:


>I have a ATI 9800 pro and I tried opening windows and resizing them
>maximizing them and the highest cpu usage was 14%. The average was 8% to
>12%. I am using the newest 4.10 drivers just released this week.
>
>toony must be an nvidiot to have that much trouble with his ati card.
>

He now admits it was his mb. Of course he had to bad mouth ATI first
though before having a brain fart and realizing he was full of it.
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Bruce Mckown wrote:
> You could leave the safe cocoon of this news group and go check in the
> ATI newsgroup for yourself. You lazy bastard.

You'll see me from time to time in the comp.sys.ibm.pc.hardware.video group.
Don't have an ATI video card anymore, so there's no reason for me to go to
that newsgroup. I was glad to stop using ATI video cards about four years
ago, which I'd been using for nearly ten years prior to that..

If you're such a video card god, why didn't you step up and suggest that it
could've been the AGP GART driver, or one of several other things, instead
of acting like such a pompous prick. The rest of us come here to help people
figure out their problems, you're here to tell everybody that they're stupid
for even having a problem.

I'll be glad to use ATI video cards again, eventually, after I've seen
enough reports that people are having no problems with them. But needless to
say, your own report won't be one of those I'd consider in the equation. And
I gather most other people feel the same way about you. Go hide in your ATI
newsgroup, I'm sure there's enough people on that newsgroup with you in
their killfile that it won't bother them so much.

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

On Tue, 26 Oct 2004 05:21:53 -0700, Bruce Mckown <no@email.here> wrote:

>On Fri, 22 Oct 2004 08:11:50 GMT, "Lee Waun" <leewaun@telus.net>
>wrote:
>
>
>>I have a ATI 9800 pro and I tried opening windows and resizing them
>>maximizing them and the highest cpu usage was 14%. The average was 8% to
>>12%. I am using the newest 4.10 drivers just released this week.
>>
>>toony must be an nvidiot to have that much trouble with his ati card.
>>
>
>He now admits it was his mb. Of course he had to bad mouth ATI first
>though before having a brain fart and realizing he was full of it.

No, he said it only errored with one of his mbrds - not necessarily a mbrd
fault. Evidently ATI limits its testing to a subset of available mbrds
and/or chipsets... not uncommon but we'll probably never know whose fault
it was.

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,comp.sys.intel (More info?)

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
news:-uGdnXbAc8fwWuXcRVn-1A@rogers.com...
[...]
> After a few bad incidences, you quickly learn that upgrading is something
> you should do only with the utmost care. So when everybody else goes
> around getting excited that the latest version of something is coming out,
> I get into the "ohmygod, is another upgrade coming soon?" mode. I upgraded
> to Windows 2000 in 2002, a full two years after it was first introduced.
> And I just upgraded to Windows XP this year, a full three years after that
> one was introduced. And I waited a month and half before installing SP2 on
> XP. For me, I have to wait and listen for problems before I will bother to
> upgrade.
>

What? no spell with Windows ME and The Blue Screen?
 
Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Hyperoglyphe wrote:
> What? no spell with Windows ME and The Blue Screen?

No, remember Windows 2000 came out before ME, so I was fortunate enough to
bypass that flytrap. 🙂

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

"Robert Redelmeier" <redelm@ev1.net.invalid> wrote in message news:woled.9054$q%7.4731@newssvr11.news.prodigy.com...

> Personally, I dislike the obvious partisanship of csi and the
> various AMD groups. I prefer the open discussion in csiphc.

I think they are there for different reasons (?, yeah, I know, read
the FAQ). I assume csi is an Intel user group more than a forum for
industry-wide discussions or the "chevy vs. ford" -type debates.

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

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message news:iaidnYixZpszmOfcRVn-rg@rogers.com...

> First of all, look at the newsgroups listings, it includes
> comp.sys.ibm.pc.hardware.chips, not just comp.sys.intel. Second of all, AMD
> is /on-topic/ in csi.

The casual observer would not assume such but rather the opposite.

> The newsgroup was never simply about Intel processors
> alone.

Which seems weird to me gven the group name.

> It was about Intel and compatible processors, and peripherals.

Seems like csipc and csi are redundant then. That's probably why the
crossposting occurred to begin with. I wonder if that's a common problem
between the 2 groups.

>I've
> been participating in csi for around a decade if not longer, and it's never
> been off-topic. Sure we'll try and keep csi a little more Intel-centric than
> csiphc, but if the topic diverges into AMD, VIA, Transmeta, then so beit.

I see.

>
>>> Trust me, you need to research all-Intel systems just as thoroughly.
>>
>> I wasn't saying I didn't want to research Intel systems. I was saying
>> I don't feel the need to research AMD systems at this time.
>
> You're making "research" sound like some sort of major undertaking. In
> reality, it's no more than a couple of Google and newsgroup searches away,
> just like what you're doing right now by reading these postings.

Well beyond the research is the product evals, tooling etc. Easier to pick one
and go with it.

>
> I'm surprised you don't do at least some research before putting together
> even Intel systems.

I do a lot actually.

> At the very least you will need to decide which
> motherboard make you're going with, and then which model. Then you'll need
> to decide which video card, powersupply, etc. The only time you won't need
> to worry about any of that is when you're buying ready-made systems, where
> you only need to research that particular make/model of system. If you're
> going to buy ready-made systems, then there is no difference whether you buy
> Intel or AMD.

Why you assume I don't do that, perplexes me.

>>> Various recently introduced chipsets have been recalled. Features
>>> promised for them have been cancelled. And these are just the recent
>>> problems, since the last few months. You'd have known these if you
>>> did some "research". Really, the only truly classically reliable Intel
>>> CPU/chipset combo
>>> I can recall is that of the Pentium 2/3 with 440BX combo. Nothing
>>> else has lived upto that standard since.
>>
>> You're Intel-bashing again.
>
> So anytime somebody points out the problems in Intel systems, they are
> bashing? I thought you /really/ wanted to know, but seems all you want to
> know is what you already believe.

I don't think it's something that most will encounter so I thought you over-
emphasized it.

>
> The only way I am bashing is if you can refute whatever I just told you,
> because I just gave you well-known _recent_ examples. I could go even
> further back and bring up examples from one, two, or three years ago, or
> even further back; but there's no point in doing that, the recent ones
> should be sufficient.

Whaddaya wanna bet my new PC will still be running (or runnable) 10 years
from now (the CPU/chipset/MB)?

>> Msg me in 5 years and I'll tell you what
>> if any problems I've personally experienced with the systems I've
>> recently built.
>
> Get out of here, you aren't even going to be personally running most of
> those systems yourself.

But I'll be babysitting them as needed.

> You're giving them away to friends and relatives.
> There's no way to tell what problems other people are having continuously.
> Some people just live with problems without even knowing that they have a
> problem. While others start calling you at the slightest hiccup. That's all
> based around the operator's personality.

Nah, I'll know about it. I'm the support person for them.


> And the ones you're going to run personally, you're going to upgrade
> something in it long before five years is up.

Maybe the surronding stuff: hard drives, PCI cards and stuff. But the
CPU/chipset/MB are married for life. The only thing I foresee potentially
doing to my personal system is TV/PVR type stuff. I don't like to accumulate
a lot of parts but rather keep whole systems together in some kind of
runnable configuration. Even if I just need to setup a network for testing
or something.

> My current system started out
> life as an Intel 386DX-25 about 15 years ago, and it's had every one of its
> parts systematically upgraded over the years to its current configuration.

I still have a 386-20 system that if I plug in today would still work if I could
find something for it to do. A PII system also that I have used as recently
as earlier this year.

> Along the way, it became an AMD 486DX2-66, then a Cyrix 6x86-133, an AMD
> K6/3-450, a Duron 700, an Athlon 1.0Ghz, and now an Athlon XP-1900+.

It sounds like you mean that the same PC case has had a number of parts
in it over time. Case != PC.

> Each of
> those processor stages lasted on average about 3 years, and then they got
> upgraded.
>
>> My gut feel says that other than BIOS updates and
>> such, there won't be much of a problem at all. With hard drives, perhaps
>> there's reason for
>> concern about reliability. But in CPUs, motherboards I don't think so
>> (perhaps with the many AMD parts though? 😉, hehe. )
>
> That's a strange comment to make considering you can't be bothered to research AMD. What do you really need to research,
> it's no harder to research than Intel.

You mean the "AMD sarcasm"? I was just being humorous. I was poking
fun at the people who engage in the flame wars over products rather than
at AMD.

>
>>> Actually these days, if someone were to say you could build a
>>> comparable Intel system for half the price of an AMD system, that
>>> would be something compelling.
>>
>> To an AMDer. To get one to MOVE from one to the other is the issue in
>> my case and not just starting from scratch and being at the AMD/Intel
>> decision crossroads.
>
> What exactly is your problem? Moving from Intel to AMD is dead simple.

My point is that I have no reason to move. And I don't have to learn how to
setup the fan control curves again, or how to update the BIOS again, or
where to get the updates etc (from 3 vendors in AMD's case no doubt).

> It's
> not like as if you're moving to a different processor architecture. For all intents and purposes, it's the same processors.
> Have you
> ever had to move your software from one Unix architecture to another, let's
> say from Solaris to HP-UX or vice-versa? Now that's complicated. With Intel
> and AMD, you just take out the hard drive from your previous system and put
> it into the new one. At its most complicated, you copy from one hard drive
> to another.

I'm considering the surrounding issues as more important: support, training,
vendor liason, etc. I have an "investment" in Intel at this time and no one is
asking me or paying me to build them an AMD system. So I really have no
reason to look at AMD at this time as I am "a happy camper" for now.

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

On Tue, 26 Oct 2004 23:42:41 +0000, AJ wrote:

>
> "Robert Redelmeier" <redelm@ev1.net.invalid> wrote in message news:woled.9054$q%7.4731@newssvr11.news.prodigy.com...
>
>> Personally, I dislike the obvious partisanship of csi and the
>> various AMD groups. I prefer the open discussion in csiphc.
>
> I think they are there for different reasons (?, yeah, I know, read
> the FAQ). I assume csi is an Intel user group more than a forum for
> industry-wide discussions or the "chevy vs. ford" -type debates.

That's why it's called: ass-u-me. ...forgetting where the discussion is
cross-posted to. (and where you continue)

--
Keith
 
Status
Not open for further replies.