🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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

Re: Dual Celeron's and SMP Performance Problems

#517
From: Totally Lost
Date: Thu, 27 May 1999 00:00
160 lines
8399 bytes
I'm not sure what this guys real point is, but he clearly
doesn't understand some of the issues. He freely offers the
advice below:

> You should forget you theoretical considerations (which are close
> to FUD) and do some practical works!

this is not a matter of theory, the warnings *ARE* based on real
world experiences with SMP scaling failures *AND* a pretty good
understanding of the issues, which the respondant doesn't seem
to grasp. The educational signature below seems to raise the question
of has his training has progressed to the point of even understanding
the issues and theory.

I qualified the warnings in the original post at the start,
There are a number of applications that will benefit from
dual Celerons. The warning, is that a number of app's will not,
and may even perform worse. For those that are able to learn
from other experiences, this is a valuable heads up.

In article <7ifeih$8i6$1@sparcserver.lrz-muenchen.de>,
  kuhn@lpr.e-technik.tu-muenchen.de.nospam wrote:
> In comp.os.linux.hardware Totally Lost <idletime@my-dejanews.com>
wrote:
> : To expect that they will scale well under Linux with heavy loads is
> : almost certainly folly.
>
> hmm ... i tried a load of ten ... the machine didn't felt slow
> at all. :-)

A load average of 10 "for(;;);" loops hardly stresses either the
cache or memory subsystems. Did you try SpecWeb, NetBench, WebBench
or TCP-C benchmarks which by most industry standards represent a
"heavy load"?

Walking to the front door is a "heavy load" for a chain smoking, over
wieght slob ... doing a 10K and Tri-athlon in the same day is a
"heavy load" in almost everybody elses mind.

> A friend of mine did some benchmarks with dual PII/350 and
> Dual Celeron 333: the Celerons were only 10-20% slower
> at many Applications (compilation, gaming, rendering etc.)
> but they are a third the price ...

Hmm ... two clueless points ... unspecified, unqualified benchmarks
and a meaningless assertion of price/performance of a sytem based
upon a single components relative savings. Saving $150 on a
dual 333MHz system with a $3K price tag (5% savings), to have it
run 20% slower doesn't sound like a bargin to me.

Benchmarking is both an art and slick used computer salesman
lies. In general, a benchmark is only useful when all parties
agree the results are a meaningful indicator of a real world work
load that is important in the intended application.

Most new Dual systems (cpus, memory, motherboard, case, keyboard, disks,
display, network, ... etc) have a total price of something at or above
$2K. A fast quality system has a total price of more than $4K. Saving a
few bucks (< 10% of the total system price) seems poor judgement, since
your whole system will be slower, and each of the high performance
components that a premium price was paid for will also perform slower
since the CPU will be the service bottleneck. This is even more folly
when certain applications risk running slower than uniprocessor, and
you paid a $300-600 premium for the dual Celeron processor system,
and another $150 would have made it twice as fast.

> You should forget you theoretical considerations (which are close
> to FUD) and do some practical works!

I'm not talking theory, just cold hard industry experience. Since you
are offering advice, might I suggest some too?

Do your homework, then temper it with 30 years of field experience.

I started on big iron in the late 60's thru the mid 70's on IBM
mainframe systems as a systems programmer, and have been doing UNIX
kernel systems programming since 1975 - including contracting for
an entire SVR3 UNIX port for a non-symetrical multiprocessor system,
and the ground up design for an M68020 UNIX system with shared address
I/O processors.

> PII and Celeron are realy very close in performance but very
> different in price (that one who buys a PII instead of a Celeron
> is realy silly or forced to).

For an application with a 127K (or less) working set, this is quite
true. For an application with as little as a 130K working set, a PII
could be as much as 200-500% faster depending upon the memory subsystem.
This opens the door to hysteresis induced queue saturation, and
in some applications a system that wildly transitions between
responsive and doggy, if it doesn't just get trapped in the doggy
mode.

An Oracle data base server under modest load has a working set of
between 3-9MB. A Web server under moderate load has a working set
of between 500K-6MB. An NFS/SMB fileserver under moderate load has
a working set of 400K-2MB. In each of these applications, the difference
between 128K and 512K L2 cache is significant, most really benefit from
1M L2 caches. The idiot that tries to save $150 by using Celerons,
just degraded the systems capacity under load by 80% or more for
loads like these.

> In dual-mode the Celerons are only a little bit slower than Dual PII,
but

for small working sets, 200-500% slower on modest working sets.

> 1) the Price is much lower, so the performance/price ratio is much
better

Penny-wise, pound foolish to reduce the performance of a $2-4K system
by 20% or more, to save 5% cost on the system (about $150 for 333MHz).
I don't see how this is much better???????

> 2) if i realy had a mission critcal Server under heavy load, then i
>    would buy a _real_ Computer (i am not talking of Xeons)

I don't know what you might think a real computer is, but a Dual Xeon
or Katmai server with 5 channel software raid, clustered by two or
four, can deliver the performance (and possibly the reliability)
of almost any big iron server less than $250K a few years ago,
at around or less than 10% the cost. I used to think that the
dual 370/165's I worked on at the bank some years back was a real
computer ... My notebook today is faster and has more disk, but
lacks the printer capacity of the 27 1401N2's with AN chains, and
the input capacity of the MICR farm.

>
> Especial for Home-Multimedia on Linux, the (Dual)Celeron are the
> better choice (Oh i have forgotten to mention PIII: it even
> speeds up the internet, according to intel's advertising in germany)

As long as you don't need X11, network or filesystem. The working set
for these features greatly exceeds the 128K L2 cache. I think you
will find that hitting "enter" in an X11 shell window requires a working
set something greater than 300K, depending on the system version and
drivers, greater than 700K.

> Ok, the Celerons would scale lousy on a Quad- or Octa-SMP-System, but
> that is theorie, because Celerons and PII can only do dual-operation

yes theory, simply because I've not meet anybody stupid enough to
try it as a general commercial product. Your reason however, is
totally clueless ... SMP systems were built long before the processor
bus supported N-Way cache-coherent shared memory extensions. Octa-PPro's
are just one example of using cache-coherency between multiple cache
buses, extremes are the 32 PPro systems built by firms like Sequent.

> So, now it's your turn!
>  -------------------------------------------------------------------
> | Bernhard Kuhn                (kuhn[at]lpr.ei.tum.de)  O|||OO||OO| |
> | Laboratory for Process Control and Real-Time Systems  O|||O|O|O|O |

Tag - you're it!!! :)

John


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Technical Details
Message-ID: <7ik5io$4s0$1@nnrp1.deja.com>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <7ieko6$41e$1@nnrp1.deja.com> <7ifeih$8i6$1@sparcserver.lrz-muenchen.de>

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: Totally Lost <idletime@my-deja.com>
Subject: Re: Dual Celeron's and SMP Performance Problems
Date: 1999/05/27
Message-ID: <7ik5io$4s0$1@nnrp1.deja.com>
X-Deja-AN: 482801521
References: <7ieko6$41e$1@nnrp1.deja.com> <7ifeih$8i6$1@sparcserver.lrz-muenchen.de>
X-Http-Proxy: 1.0 x21.deja.com:80 (Squid/1.1.22) for client 205.169.102.129
Organization: Deja.com - Share what you know. Learn what you don't.
X-Article-Creation-Date: Thu May 27 19:14:35 1999 GMT
Newsgroups: comp.os.linux.hardware,alt.comp.hardware.overclocking,csu.unix.linux
X-Http-User-Agent: Mozilla/4.07 [en] (X11; I; Linux 2.0.36 i586)