🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.linux.hardware
Article #503

Re: Dual Celeron's and SMP Performance Problems

#503
From: CB
Date: Thu, 03 Jun 1999 00:00
60 lines
3671 bytes

Chris Mauritz wrote:
> 
><food fight removed>
> 
> The bottom line from my limited experience with dual celerons and
> substantial experience with dual PPro's and PII/III's is that:
> 
> * The likely outcome is an increase in performance.
> * The degree of performance increase is application dependent.
> * Given "ideal" conditions, it's possible to get a degradation
>   in performance if the application needs the additional L2 cache.
> * Given those same "ideal" conditions, it may also be a problem
>   to use bona fide PII/PIII's.
> 
> I'm not sure why some folks are getting all worked up over this.


Well..

Intel has actively promoted the notion that Celerons are a cheap,
inferior product, not worthy of consideration for those doing "real"
computing.  Smp capability was hidden, and then when discovered, was
denounced, and practicers threatened with loss of warranty - even when
the capability is enabled by a jumper on an adapter (no
drilling/soldering - just throw a switch).  Now that the word is out
that one can purchase off-the shelf products, plug them in, and enable
this capability, and online reviews have appeared of dual Celeron
systems, there have been articles posted suggesting that the small cache
so cripples these processors that even though you can enable this
feature, why would any serious person want to - just go out and buy a
few Xeons with a couple MBs of cache if you want to do "real" computing.

I feel this is misleading.  While lack of the large cache may be
(probably/surely is) a hindrance in some situations, I suspect that
these situations are less common than Intel would have the general
public believe.  And then again, I could be all wet and have mud in my
eye.

I see a multi-tasking advantage.  I see Celerons as an economical
alternative to some higher cost solutions.  I think it is more useful to
post specific information about the observed practical limitations of a
particular setup, or practical methods to improve performance with given
hardware than to post a long theoretical diatribe about the terrible
hazards of Celeron smp.  Determining the practical limits would add
knowledge.

CB

> 
> C
> --
> Christopher Mauritz
> ritz@mordor.net


  -----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
   http://www.newsfeeds.com       The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including  Dedicated  Binaries Servers ==-----
Technical Details
Message-ID: <3757318B.F1B38FC0@dakotacom.net>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <7ieko6$41e$1@nnrp1.deja.com> <3751F4D8.8C0C9B65@dakotacom.net> <7j3j2t$m7o$1@nnrp1.deja.com> <FCrExL.KoI@spcuna.spc.edu>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 102b32,acbefbd0f12f9cdd
X-Google-Attributes: gid102b32,public
X-Google-Thread: 1159f7,acbefbd0f12f9cdd
X-Google-Attributes: gid1159f7,public
X-Google-Thread: 100562,acbefbd0f12f9cdd
X-Google-Attributes: gid100562,public
From: CB <NocbaisanSpam@dakotacom.net>
Subject: Re: Dual Celeron's and SMP Performance Problems
Date: 1999/06/03
Message-ID: <3757318B.F1B38FC0@dakotacom.net>
X-Deja-AN: 485830969
X-Abuse-Info2: Otherwise we will be unable to process your complaint properly
X-Report: Report abuse to abuse@newsfeeds.com
Content-Transfer-Encoding: 7bit
References: <7ieko6$41e$1@nnrp1.deja.com> <3751F4D8.8C0C9B65@dakotacom.net> <7j3j2t$m7o$1@nnrp1.deja.com> <FCrExL.KoI@spcuna.spc.edu>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Abuse-Info: Please be sure to forward a copy of ALL headers, INCLUDING the body
X-Trace: 3 Jun 1999 20:52:55 -0500, 150.135.118.164
Organization: Newsfeeds.com http://www.newsfeeds.com 72,000+ UNCENSORED Newsgroups. Instant access!!
MIME-Version: 1.0
Newsgroups: comp.os.linux.hardware,alt.comp.hardware.overclocking,csu.unix.linux