🚀 go-pugleaf

I must be dense.  After reading this a couple of times I still don't
understand: how can two Celerons be worse than one when each has its 
own cache?  I don't see how an interrupt serviced by one would cause 
the other's cache to be flushed.

-- Rod

Totally Lost <idletime@my-dejanews.com> wrote:
>The work done by Tomohiro Kawada and others has been interesting.
>I can think of a number of applications where dual/quad overclocked
>Celeron's can produce very cost effective clusters for number crunching.
>The crypt cracking teams will get a great windfall from this work.

>I do performance studies and optimization for a living. One of the
>biggest problems people have porting applications from big iron
>SMP servers to X86 SMP servers is memory foot print and working
>set locality problems which make X86 SMP scaling difficult at best.

>Big Iron SMP servers typically have larger L1/L2 caches with
>a much faster memory subsystem under them. The size of the
>working set directly predicts the performance of most
>applications. To help clients understand this I often use the following
>visual aid in my presentations, which is the output of a tool
>I use to measure the performance of their system as the working
>set size is increased:

>Counts are thousands of MemOps/second.
>SunOS svr20 5.5.1 Generic sun4m sparc SUNW,SPARCstation-20

>Set  Sequential Random
>Size  Cnt   Pct Cnt   Pct
>----- --------- --------- 0%        25%        50%        75%       100
>   2K 29685 100 21271 100 |          |          |         *|          @
>   3K 29657 100 21244 100 |                              *            @
>   4K 29652 100 21231 100 |          |          |        * |          @
>   6K 29644 100 21264 100 |                               *           @
>   8K 29652 100 21203 100 |          |          |        * |          @
>  12K 29644 100 21245 100 |                              *            @
>  16K 29625 100 21221 100 |          |          |        * |          @
>  24K 10996  37 18120  85 |               @          *
>  32K  7943  27 16190  76 |          |@         | *        |          |
>  48K  7941  27 13716  64 |           @       *
>  64K  7939  27 12067  57 |          |@     *   |          |          |
>  96K  7943  27 10802  51 |           @   *
> 128K  7947  27  9877  46 |          |@  *      |          |          |
> 192K  7946  27  9837  46 |           @  *
> 256K  7909  27  9828  46 |          |@  *      |          |          |
> 384K  7773  26  9806  46 |           @  *
> 512K  7652  26  9766  46 |          @  *       |          |          |
> 768K  7619  26  9765  46 |          @  *
>1024K  7580  26  9755  46 |          @  *       |          |          |
>1536K  2164   7  9642  45 |  @          *
>   2M  2045   7  9634  45 |  @       |  *       |          |          |
>   3M  2044   7  9602  45 |  @          *
>   4M  2041   7  9595  45 |  @       |  *       |          |          |
>   6M  2038   7  9592  45 |  @          *
>   8M  2042   7  8823  41 |  @       | *        |          |          |
>  12M  2035   7  8720  41 |  @         *
>  16M  1863   6  8723  41 |  @       | *        |          |          |
>  24M  2023   7  8596  40 |  @         *
>  32M  1657   6  9590  45 | @        |  *       |          |          |
>  48M    10   0  8040  38 @           *
>  64M    40   0  6552  31 @         *|          |          |          |

>The graph is plotted with all values relative to the first sequential
>value. The test reflects the performance losses due to the working
>set size impact on the VM/Cache/Memory subsystems. This includes
>TLB misses, cache misses and memory latency. Cache design and memory
>allocation coloring present very different responses to this test.
>Poorly colored memory with direct mapped caches shows up with early
>degradation slopes, while good coloring produces sharp fall-offs at
>each cache boundry.

>This particular machine didn't have a lot of
>memory and started paging above 32M, with 32K L1 and 1024K L2 cache
>sizes. Increasing the working set by a single cache line
>often reduces the performance to the next larger (and slower)
>memory object.

>In a real system, there are many sources that scale into the working
>set size(s). The size of the active interrupt service routines and
>OS scheduler are often near the size of L1/L2 caches on many X86
>systems, thus each interrupt flushes the cache and effectively runs
>at memory or L2 cache speeds. In an SMP system, both CPU's have to
>share the memory performance. If the L1/L2 caches are too small, then
>two processors are worse than one, because they will flush each other
>with distributed interrupts. The cost of flushing the cache by context
>switches and interrupts is two 2X ... memory cycles required to bring
>in the new context/interrupt plus the memory cycles required to replace
>the active process memory on exit. One reason that X86 SMP servers
>may scale, is that network interrupt loads that flush a uniprocessor,
>only impact one processor in a multiprocessor system ... especially
>if the interrupts are bound to a single processor. Ditto for the disk
>subsystems. SCSI controllers that have high interrupt loading can
>kill an SMP server if the interrupts are distributed. NCR825's are
>a very good example when used with very poor SCSI scripts and drivers.

>Understanding the locality and working set sizes, some X86 vendors
>have post processed their kernel builds to improve locality and
>placement. The work done by the SCO Unixware team on the object code
>segments has produced remarkable results. These vendors often have
>large kernels and feature sets, with same/better overall performance.

>Celron's with their 128K L2 cache can easily produce worse performance
>under modest to heavy load than a single processor in an SMP system.
>In many server systems, even dual PII's with 512K L2 caches fail to
>scale or produce negative results under modest to heavy work loads.
>In some applications, even Xenon's large caches fail to scale or
>produce negative results in comparision to uniprocessors of the same
>architecture. Simply put, it's not uncommon to find applications where
>two processors trashing the caches with SMP interrupts or shared memory
>produce much worse performance than the same system with only a single
>processor enabled.

>Linux is not well multi-threaded, and has a pretty large foot print
>with very little locality in either the OS or it's primary applications.
>I would expect that for many users, dual Celeron's may have a negative
>performance impact much of the time.

>To observe that Dual Celron's produce an observed improvement under
>certain lightly loading applications may be true. To assert that
>they scale under modest to heavy work loads is probably a huge mistake.
>To expect that they will scale well under Linux with heavy loads is
>almost certainly folly.

>John Bass
>UNIX Systems Consultant


-- Rod
----------------------------------------------------------------------
Sunset Systems                           Preconfigured Linux Computers
http://www.sunsetsystems.com/                      and Custom Software
----------------------------------------------------------------------

In comp.os.linux.hardware Totally Lost <idletime@my-dejanews.com> wrote:

: Celron's with their 128K L2 cache can easily produce worse performance
: under modest to heavy load than a single processor in an SMP system.

Don't forget: PPros had only 256K L2 and everbody was just satisfied :-)



: In many server systems, even dual PII's with 512K L2 caches fail to
: scale or produce negative results under modest to heavy work loads.
: In some applications, even Xenon's large caches fail to scale or
: produce negative results in comparision to uniprocessors of the same
: architecture. Simply put, it's not uncommon to find applications where
: two processors trashing the caches with SMP interrupts or shared memory
: produce much worse performance than the same system with only a single
: processor enabled.

Of course, you can _always_ find an appication that doesn't fit
into an L2-Cache (and that will ever be).



: I would expect that for many users, dual Celeron's may have a negative
: performance impact much of the time.

You _expect_? I have _experiences_: up to 90% speedup at code-compilation
(yes, with Dual-Celeron)



: To observe that Dual Celron's produce an observed improvement under
: certain lightly loading applications may be true. To assert that
: they scale under modest to heavy work loads is probably a huge mistake.

It's always a question of code locality: a Dual Celeron may be
faster than a Dual PII at the same clockrate since the Celeron's
L2 is twice as fast.



: 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 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 ...


You should forget you theoretical considerations (which are close
to FUD) and do some practical works!
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).

In dual-mode the Celerons are only a little bit slower than Dual PII, but
1) the Price is much lower, so the performance/price ratio 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)

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)

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


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 |
| Technische Universit�t M�nchen  Tel.+49-89-289-23732  O|||OO||OO| |
| 80290 M�nchen, Germany          Room 3944 Fax -23555  OOO|O|||O|O |
 --------------------------------------------------------------------

In comp.os.linux.hardware kuhn wrote:
> In comp.os.linux.hardware Totally Lost <idletime@my-dejanews.com> wrote:

> : Celron's with their 128K L2 cache can easily produce worse performance
> : under modest to heavy load than a single processor in an SMP system.

> Don't forget: PPros had only 256K L2 and everbody was just satisfied :-)

And also don't forget that the 128k cache is running at full core
speed rather than 1/2 speed that you'd find on the PII.  I think
for most applications the faster 2 x 128k would be more beneficial
than 2 x 512k running at half the speed of the processor.  I'd love
to see some benchmarks for typical system tasks.

> : In many server systems, even dual PII's with 512K L2 caches fail to
> : scale or produce negative results under modest to heavy work loads.
> : In some applications, even Xenon's large caches fail to scale or
> : produce negative results in comparision to uniprocessors of the same
> : architecture. Simply put, it's not uncommon to find applications where
> : two processors trashing the caches with SMP interrupts or shared memory
> : produce much worse performance than the same system with only a single
> : processor enabled.

I think this is probably a rare occurance and you'd almost have to
specifically design the task to behave this badly.

> Of course, you can _always_ find an appication that doesn't fit
> into an L2-Cache (and that will ever be).

Yup.

> : I would expect that for many users, dual Celeron's may have a negative
> : performance impact much of the time.

No way.

> You _expect_? I have _experiences_: up to 90% speedup at code-compilation
> (yes, with Dual-Celeron)

That's been my experience as well.  

> : To observe that Dual Celron's produce an observed improvement under
> : certain lightly loading applications may be true. To assert that
> : they scale under modest to heavy work loads is probably a huge mistake.

No it isn't.

> It's always a question of code locality: a Dual Celeron may be
> faster than a Dual PII at the same clockrate since the Celeron's
> L2 is twice as fast.

Yup.

> : To expect that they will scale well under Linux with heavy loads is
> : almost certainly folly.

No it isn't.

> hmm ... i tried a load of ten ... the machine didn't felt slow
> at all. :-)

> 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 ...

That's the key.  

> You should forget you theoretical considerations (which are close
> to FUD) and do some practical works!
> 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 homebuilt systems, I'd agree that it's rather silly not to do
dual celerons unless you have an application that would benefit
enough from the additional (but slower) cache to justify the
substantial increase in cost.

C
-- 
Christopher Mauritz
ritz@mordor.net

In article <7iette$6ge$1@nnrp03.primenet.com>, Rod Roark wrote:
>I must be dense.  After reading this a couple of times I still don't
>understand: how can two Celerons be worse than one when each has its 
>own cache?  I don't see how an interrupt serviced by one would cause 

Well i've certainly had this experience on dual/SMP machines,
although not on X86/linux.

-- 
=======================================================
Dr Rowan Hughes                  hughesr@dnr.qld.gov.au
Qld Dept Natural Resources          Forestry Bldg, 4.06    
CIS group, Indooroopilly. W:07-38969705   H:07-38768083

On Tue, 25 May 1999 16:56:40 GMT, Totally Lost
<idletime@my-dejanews.com> wrote:

>The work done by Tomohiro Kawada and others has been interesting.
>I can think of a number of applications where dual/quad overclocked
>Celeron's can produce very cost effective clusters for number crunching.
>The crypt cracking teams will get a great windfall from this work.

Celerons and P2's aren't designed for quad operation...
PPro/Xeon are

Totally Lost <idletime@my-dejanews.com> writes:

> Linux is not well multi-threaded, and has a pretty large foot print
> with very little locality in either the OS or it's primary applications.
> I would expect that for many users, dual Celeron's may have a negative
> performance impact much of the time.
> 
> To observe that Dual Celron's produce an observed improvement under
> certain lightly loading applications may be true. To assert that
> they scale under modest to heavy work loads is probably a huge mistake.
> To expect that they will scale well under Linux with heavy loads is
> almost certainly folly.

this depends on the type of loads.  i do number crunching and have a
quad ppro-200 (512k cache) machine.  the jobs are trivially
parallelizable (i need to run many to build up stats, i can run
multiple copies of the same job with differing random number seeds)
and involve little or no disk activity.  the quad box really does give
four times the performance of my older single ppro-200 (256k cache).
with four jobs active i have 399% user cpu loading.  since i am never
in the kernel for much, i didn't seem much improvement going from
2.0.x to 2.2.x (once the shopping deadlock problem in 2.0.34 and lower
got fixed - 2.0.34 and below could only handle two cpus).

-- 
johan kullstam

Rowan Hughes wrote:
> 
> In article <7iette$6ge$1@nnrp03.primenet.com>, Rod Roark wrote:
> >I must be dense.  After reading this a couple of times I still don't
> >understand: how can two Celerons be worse than one when each has its
> >own cache?  I don't see how an interrupt serviced by one would cause
> 
> Well i've certainly had this experience on dual/SMP machines,
> although not on X86/linux.

There are many thing that can go worse than an single-systems if not
written with SMP's in mind.

First Cache-Trashing: (big impact)
	If some processors happen to work on the same data and this data is 
	smaller than a cache-line (512Byte? don't know for intel, only guess.)
	if one processor updates only one byte the other has to trash this line
	and (scince he is working on it) get it from the first one blocking
	the interface to the memory and IO (bus-architecture) wich is a real
	performance-blocker in SMPs (that's why big SMP's often have really big
	cross-bared and interleaved memory interfaces with huge third-level
caches.).

Second Cache-Flushing: (even bigger)
	happens at Mutex-Locks(syncronization of multiple threads should as
long as possible
	be handled without these) and propably interrupts (never gone this far
into the mashine
	to know about this for shure).

Third Memory-Access: 
	Multiple processors have to syncronize and share a single (on i386
REALLY NARROW)
	memory-interface and all this IO-devices. If more than one processors
want sth. to
	chew on they have to wait for each other and are probably sitting
pretty idle
	(especially on large data-sets even an older alpha with say, 70% the
fp-power
	of the compared intel can rush away because of this, and this is what
his graph
	showed and it has a REALLY HUGE IMPACT scince both processors may end
up cooling
	down and waiting for each other but that's more a problem of i386
against others
	that is only experienced much clearer on SMP's.).


	...someone who is running a dual PII, optimizing and writing parallel
and distributed
	   software scince some time and will definately UPGRADE to a newer
dual celeron.

---
Suran@gmx.net

A while ago, <kuhn@lpr.e-technik.tu-muenchen.de.nospam> begot:
>In comp.os.linux.hardware Totally Lost <idletime@my-dejanews.com> wrote:
>
>: Celron's with their 128K L2 cache can easily produce worse performance
>: under modest to heavy load than a single processor in an SMP system.
>
>Don't forget: PPros had only 256K L2 and everbody was just satisfied :-)

On a semi-related note, PPro's meant for normal consumption had only
256K L2 cache.  PPro's meant to go in servers could have 512K or 1MB.
These PPro's were *much* more expensive.  I think the 1MB'ers were
going for a couple of thousand dollars at one point... *just* the CPU.

I know for a fact that a particular company I worked for (who shall
remain nameless) wanted those larger-cache PPros very much.  They
were not satisfied with 256K.

-- 
Glenn Lamb - mumford@netcom.com.  Finger for my PGP Key.
Email to me must have my address in either the To: or Cc: field.  All other
mail will be bounced automatically as spam.
PGPprint = E3 0F DE CC 94 72 D1 1A  2D 2E A9 08 6B A0 CD 82

In comp.os.linux.hardware mumford <mumford@netcom.com> wrote:

: On a semi-related note, PPro's meant for normal consumption had only
: 256K L2 cache.  PPro's meant to go in servers could have 512K or 1MB.
: These PPro's were *much* more expensive.  I think the 1MB'ers were
: going for a couple of thousand dollars at one point... *just* the CPU.

: I know for a fact that a particular company I worked for (who shall
: remain nameless) wanted those larger-cache PPros very much.  They
: were not satisfied with 256K.

Then they had an application were 256K are not enough.
You may have an application were 4MB are not enough.
But you may also have an application were 32K are enough.

It's only a question of code and data locality - at least
it only depends on _your_ application.

Of course, i'd like to own a Dual Xeon 500 with 2MB each,
but for the same price, i get a cluster of ten or more Dual Celeron 400.
Depending on the application, the Cluster may be 7 times faster
then the Xeons, but they may be only 1/7 the speed as well.

-- 
 -------------------------------------------------------------------  
| Bernhard Kuhn                (kuhn[at]lpr.ei.tum.de)  O|||OO||OO| |
| Laboratory for Process Control and Real-Time Systems  O|||O|O|O|O |
| Technische Universit�t M�nchen  Tel.+49-89-289-23732  O|||OO||OO| |
| 80290 M�nchen, Germany          Room 3944 Fax -23555  OOO|O|||O|O |
 --------------------------------------------------------------------

So what's the point? There are plenty of 8 processor SMP PPro designs,
and some that are 32-64 CC-NUMA (like Sequent's big iron servers).
SMP and NUMA designs were around long before the processor bus and
chipsets supported SMP directly. Big server companies just continue
to do the same thing but with dual/quad clusters of processors over
layered L3 caches and interleaved memory.

In article <374b8777.7216321@24.93.94.39>,
  poit@carolina.rr.calm wrote:
> On Tue, 25 May 1999 16:56:40 GMT, Totally Lost
> <idletime@my-dejanews.com> wrote:
>
> >The work done by Tomohiro Kawada and others has been interesting.
> >I can think of a number of applications where dual/quad overclocked
> >Celeron's can produce very cost effective clusters for number
crunching.
> >The crypt cracking teams will get a great windfall from this work.
>
> Celerons and P2's aren't designed for quad operation...
> PPro/Xeon are
>


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

So what's the point? I started this thread with an initial post that
had a very important disclaimer right up front:

	"The work done by Tomohiro Kawada and others has been
	interesting. I can think of a number of applications
	where dual/quad overclocked Celeron's can produce very
	cost effective clusters for number crunching. The crypt
	cracking teams will get a great windfall from this work."

There are many small working set applications that will have a big
win on SMP Celerons, possibly including yours. There are also some
medium working set applications with well localized accesses and
sequential memory accesses that will perform well too ... like gcc.

There are also many medium working set applications that would run
much faster on your quad PPro simply because of the 128K to 256K L2
cache size increase, and some significant common cases where dual
Celerons will fall on their face due to excessive memory contention
and L2 cache thrashing.

I started this thread simply to raise the issue that people need to
think about properly fiting their application to the hardware
architecture ... Dual Celerons are not a one size fits all SMP design,
dispite the testimonials of how well they work in some cases. SMP and
NUMA multi-processing has many suprises, one of which is that sometimes
applications run much faster, on the same hardware, when the second
processor is disabled. Any SMP or CC-NUMA performance guy with
significant experience has seen this at least once, and sometimes
more often than the industry would like to talk about.

In article <ulnebvpff.fsf@res.raytheon.com>,
  Johan Kullstam <kullstam@ne.mediaone.net> wrote:
> Totally Lost <idletime@my-dejanews.com> writes:
>
> > Linux is not well multi-threaded, and has a pretty large foot print
> > with very little locality in either the OS or it's primary
applications.
> > I would expect that for many users, dual Celeron's may have a
negative
> > performance impact much of the time.
> >
> > To observe that Dual Celron's produce an observed improvement under
> > certain lightly loading applications may be true. To assert that
> > they scale under modest to heavy work loads is probably a huge
mistake.
> > To expect that they will scale well under Linux with heavy loads is
> > almost certainly folly.
>
> this depends on the type of loads.  i do number crunching and have a
> quad ppro-200 (512k cache) machine.  the jobs are trivially
> parallelizable (i need to run many to build up stats, i can run
> multiple copies of the same job with differing random number seeds)
> and involve little or no disk activity.  the quad box really does give
> four times the performance of my older single ppro-200 (256k cache).
> with four jobs active i have 399% user cpu loading.  since i am never
> in the kernel for much, i didn't seem much improvement going from
> 2.0.x to 2.2.x (once the shopping deadlock problem in 2.0.34 and lower
> got fixed - 2.0.34 and below could only handle two cpus).
>
> --
> johan kullstam
>


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Good Post Suran. But I think your final assertion needs to be
qualified:

> ...someone who is running a dual PII, optimizing and writing parallel
> and distributed software scince some time and will definately UPGRADE
> to a newer dual celeron.

IF, AND ONLY IF, the working set is less than 128K, which could be a
difficult problem if they worked hard tuning the application just
to get it's working set below the 512K point on their PII system.

In article <374C1564.BF40EF52@gmx.net>,
  suran@gmx.net wrote:
>
>
> Rowan Hughes wrote:
> >
> > In article <7iette$6ge$1@nnrp03.primenet.com>, Rod Roark wrote:
> > >I must be dense.  After reading this a couple of times I still
don't
> > >understand: how can two Celerons be worse than one when each has
its
> > >own cache?  I don't see how an interrupt serviced by one would
cause
> >
> > Well i've certainly had this experience on dual/SMP machines,
> > although not on X86/linux.
>
> There are many thing that can go worse than an single-systems if not
> written with SMP's in mind.
>
> First Cache-Trashing: (big impact)
> 	If some processors happen to work on the same data and this data is
> 	smaller than a cache-line (512Byte? don't know for intel, only
guess.)
> 	if one processor updates only one byte the other has to trash this
line
> 	and (scince he is working on it) get it from the first one blocking
> 	the interface to the memory and IO (bus-architecture) wich is a real
> 	performance-blocker in SMPs (that's why big SMP's often have really
big
> 	cross-bared and interleaved memory interfaces with huge third-level
> caches.).
>
> Second Cache-Flushing: (even bigger)
> 	happens at Mutex-Locks(syncronization of multiple threads should as
> long as possible
> 	be handled without these) and propably interrupts (never gone this
far
> into the mashine
> 	to know about this for shure).
>
> Third Memory-Access:
> 	Multiple processors have to syncronize and share a single (on i386
> REALLY NARROW)
> 	memory-interface and all this IO-devices. If more than one processors
> want sth. to
> 	chew on they have to wait for each other and are probably sitting
> pretty idle
> 	(especially on large data-sets even an older alpha with say, 70% the
> fp-power
> 	of the compared intel can rush away because of this, and this is what
> his graph
> 	showed and it has a REALLY HUGE IMPACT scince both processors may end
> up cooling
> 	down and waiting for each other but that's more a problem of i386
> against others
> 	that is only experienced much clearer on SMP's.).
>
> 	...someone who is running a dual PII, optimizing and writing parallel
> and distributed
> 	   software scince some time and will definately UPGRADE to a newer
> dual celeron.
>
> ---
> Suran@gmx.net
>


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

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.

In article <BKd33.1352$PN5.4684@newsfeeds.bigpond.com>,
  "Tony Platt" <AntonyPlatt@bigpond.com> wrote:
> I would love you to show me a quad Pentium II anything
> let alone a Quad Celeron
>
> hahahah
>
> Duel maybe but quad, I think not.

I'm only aware of one NUMA Octa-Xenon design, and it's not
clear the prototype will be finished and taken to market.
I suspect there is at least one more in the same shape.

Most of the Octa and greater PPro people are betting on
IA64, which has left them without a good X86 transition
MP product since the PPro's are pretty doggy by todays standard.
Big Iron X86 companies like Sequent must be really hurting
with dual PII/PIII systems closing the gap.

If IA64 is delayed much longer, I think we might see some
fast Quad/Octa PIII's developed and released.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

poit@carolina.rr.calm writes:
>
> Celerons and P2's aren't designed for quad operation...
> PPro/Xeon are

The built-in SMP circuitry doesn't support quad operation.  This doesn't
mean a motherboard manufacturer can't add external SMP circuitry
(including new cache controllers) to provide 4-way (or more) SMP.

Case in point: ALR used to sell a 6-way PPro system.  Needless to say,
this was an expensive system.

Heck, with the right kind of external circuitry, you can cretate a
1000-way 8088 system.  (But nobody would want to use it! :-)

-- David

In article <7ik6eb$5dn$1@nnrp1.deja.com>,
  Totally Lost <idletime@my-deja.com> wrote:
> If IA64 is delayed much longer, I think we might see some
> fast Quad/Octa PIII's developed and released.

Should put my head up more often, Proliant 6000, 6500, and 7000
systems are on the street. 8-Way SMP 500MHz boxes. A little
pricey, but the system should be fast and come with great
system boxes.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

In article <7ij3co$14s$2@sparcserver.lrz-muenchen.de>,
  kuhn@lpr.e-technik.tu-muenchen.de.nospam wrote:
> In comp.os.linux.hardware mumford <mumford@netcom.com> wrote:
>
> : On a semi-related note, PPro's meant for normal consumption had only
> : 256K L2 cache.  PPro's meant to go in servers could have 512K or
1MB.
> : These PPro's were *much* more expensive.  I think the 1MB'ers were
> : going for a couple of thousand dollars at one point... *just* the
CPU.
>
> : I know for a fact that a particular company I worked for (who shall
> : remain nameless) wanted those larger-cache PPros very much.  They
> : were not satisfied with 256K.
>
> Then they had an application were 256K are not enough.
> You may have an application were 4MB are not enough.
> But you may also have an application were 32K are enough.

and you might have an application where under 1K is enough and use a
bunch of 100MHz Scenix SX-28AC100's at a $5.00 a piece. There
are a lot of small number crunching problems where $500 of
these would smoke a bunch of dual Celerons.

But that is not what this thread is about. I started it with
the statement that there are:

	A) A lot of small applications where dual Celerons would rock.

and

	B) A lot of slightly larger applications where dual Celerons
	   would suck, and PII's would win.

So far you have tried to prove B wrong by asserting A, which was
already a given and has absolutely nothing to do with the truth or
falseness of B.

>
> It's only a question of code and data locality - at least
> it only depends on _your_ application.

And the foot print and locality of reference of the host OS, that
is of course if multitasking, filesystems, networking, GUI's and
other typical services are required on the system at the same time.

The working set for these services are considerable larger than
32K, and in fact larger than 128K.

>
> Of course, i'd like to own a Dual Xeon 500 with 2MB each,
> but for the same price, i get a cluster of ten or more Dual Celeron
400.
> Depending on the application, the Cluster may be 7 times faster
> then the Xeons, but they may be only 1/7 the speed as well.

A Supermicro S2DG2 with Dual Xeon 500/2MB's is about (4159*2)+585,
or roughly $9,200 in a box with memory and a disk, and about $10K
with fast software raid. The system will handle just about any
application you could toss at it, save certain research, military and
Fortune 500 MIS applications. In most cases, another couple grand of
upgrades would solve the fit problem. CPU power roughly 2K MIPS.

10 $1,000 dual Celeron 400's are pretty skimpy systems by comparison,
the set of applications they will handle is much smaller - in fact
pretty much limited to a bunch of small foot print jobs. CPU power
roughly 8K MIPS.

At roughly the same cost, an array of 1800 $3.50 Scenix SX-28AC100's
with a dual PII 333 I/O processor handles even a smaller set of
applications limited by the dual PII/333 and the very small
working set restrictions of the Scenix array processor. Total CPU
power is roughly 181K MIPS.

Each system has significantly restricted applications then the previous.

What's the point ... apples and oranges comparisons are a waste of
time.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

In comp.os.linux.hardware Totally Lost <idletime@my-deja.com> wrote:

: 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.

A normal single-CPU home-system is about $1000. for an additional $150 you
get a potential speedup of 100% (in real life somewhere beetween
60-80% when the application takes effekt of the second CPU)
To have the same PII power that would about $700, and the speedup
maybe 70-90% - of course, always depending on the application.
10-20% more speed for 50% more money? Only if i need it!



: Did you try SpecWeb, NetBench, WebBench
: or TCP-C benchmarks which by most industry standards represent a
: "heavy load"?

Not yet. Please give me the URLs for those, and i will do them.



: 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.

Of course, it doesn't make sense to save 5% money and to loose 20%
speed, but i am not talking of Indistrie Computers that are
>$3K, but of home-machines that should be near $1K.
And in this price-range, i experienced a speedup of 80% at
20% more in price - for my favorite application (compiling), of course.



:> 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 was talking about the Brain-Dead intel-Architecture inside
and outside the CPU! (Even with a MC68000/8 you can
stand harder real-time requirements than with an PIII/500
- application depended)

PCs have an awfull and non-deterministic architecture.
It is realy the worst technology you can buy for money - but they
are realy cheap! That is the reason, why i didnt't bought
a _real_ computer, but a Dual Celeron :-)



: 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.

Have a look at AXP, Sparc, MIPS and maybe PowerPC-based machines.
those i would say are real computers :-)

I am sure, my home-dual-celeron can't stand the load of our
old Alpha-Server 266 (1/6 the speed) when 30 people are working on it!

But for what i (and many others) am doing at home, the celerons
are the better choice!




-- 
 -------------------------------------------------------------------  
| Bernhard Kuhn                (kuhn[at]lpr.ei.tum.de)  O|||OO||OO| |
| Laboratory for Process Control and Real-Time Systems  O|||O|O|O|O |
| Technische Universit�t M�nchen  Tel.+49-89-289-23732  O|||OO||OO| |
| 80290 M�nchen, Germany          Room 3944 Fax -23555  OOO|O|||O|O |
 --------------------------------------------------------------------

In article <7ikd09$cfi$1@sparcserver.lrz-muenchen.de>,
  kuhn@lpr.e-technik.tu-muenchen.de.nospam wrote:
> In comp.os.linux.hardware Totally Lost <idletime@my-deja.com> wrote:
>
> : 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.
>
> A normal single-CPU home-system is about $1000. for an additional $150
you
> get a potential speedup of 100% (in real life somewhere beetween
> 60-80% when the application takes effekt of the second CPU)
> To have the same PII power that would about $700, and the speedup
> maybe 70-90% - of course, always depending on the application.
> 10-20% more speed for 50% more money? Only if i need it!

Ok, we'll use your numbers... $1000 system, with an additional $150
that is 15% more, not 50% more, for that you get a 10-20% speed up,
a very small part of the time (doesn't speed up editing, backups,
installs, web browsing, or most other single command activities that
we occupy our time with in front of the computer). It does however
speed up a few tasks that some people do frequently.

I suspect that if the human wait time was more carefully analyzed
across the spectrum of users, that reductions on Disk I/O or network
connectivity would have have a bigger payback. For most people,
an additional $150 spent on a faster disk subsystem would save them
a lot more time than the meger saving of a dual processor. Or in many
cases, simply selecting the next faster uniprocessor model which would
shave a little off every activity, not just multi-process ones.

> : Did you try SpecWeb, NetBench, WebBench
> : or TCP-C benchmarks which by most industry standards represent a
> : "heavy load"?
>
> Not yet. Please give me the URLs for those, and i will do them.

If you have to ask that question, I suspect you can neither afford
them or have the skills to install and run them to get meaningful
results.

> I was talking about the Brain-Dead intel-Architecture inside
> and outside the CPU! (Even with a MC68000/8 you can
> stand harder real-time requirements than with an PIII/500
> - application depended)

I'm not that fond of IA32, it's kinda haphazard. But it's far
from Brain-Dead.

I've done several Motorola hardware designs with MC68008 and MC68020
chips myself, and worked on quite a few more. There are parts of IA32
that are not pretty, but there is nothing to back up your absolute
claim here. Polling both have similar latencies, the PIII/500
is a lot faster. Interrupt latencies are a little more predicable
with the Motorola products, but in terms of absolute margins, the
faster external bus clock cycles of the PIII/500 wins hands down.

Since you made the claim, please explain yourself.

> Have a look at AXP, Sparc, MIPS and maybe PowerPC-based machines.
> those i would say are real computers :-)

I own SGI's plus both M68K and PPC Mac's, and have done system level
work on Sparc's as well. The Risc architectures on the Sparc, MIPs and
PPC is just as twisted as IA32, and a lot less open. The M68K arch
never evolved far enough to deliver any real performance by today's
standards. In the end it's not the instruction set, bus architecture,
or glue logic that really matters, it's what the end users can see and
do with a system.

From that perspective, Intel is at least as good, if not the hands
down winner, at providing a usable computer into a wide range of
computing and non-computing professionals.

> But for what i (and many others) am doing at home, the celerons
> are the better choice!

That's every buyers choice to make for themselves ... and hopefully
an informed choice at that. Blanket recomendation of one particular
techology with a total disregard to the application is folly. Hence,
my warning that dual celerons might provide a good bang for the buck
for certain users, but *DO* not blindly accept that they are fast
for everyone, or even a reasonable cost/performance tradeoff for most
people. In general, I strongly assert they are a poor choice for most
server applications, given that for a few percent more there are better
PII/PIII/Xeon uni/multi-processor options that can handle modest/large
loads *MUCH* better for the buck.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

> >The work done by Tomohiro Kawada and others has been interesting.
> >I can think of a number of applications where dual/quad overclocked
> >Celeron's can produce very cost effective clusters for number
>crunching.
> >The crypt cracking teams will get a great windfall from this work.


I would love you to show me a quad Pentium II anything

let alone a Quad Celeron

hahahah

Duel maybe but quad, I think not.

Tony

Guys,
as much as I've learned from this duel, I think it's time to get it off
the NG. Why don't You get Yourselves a decent-sized Origin 2k, or, say,
16-frame SP2 (silver) and then continue in private e-mail? I can help
You set-up either one. For a case of beer a day + travel costs (just put
me up at Your place for a few nights each). Really! Now stop it. Please.

In comp.os.linux.hardware Totally Lost <idletime@my-deja.com> wrote:

: What's the point ... apples and oranges comparisons are a waste of
: time.

Hey, you have started the discussion about
Dual Celeron vs. Dual Pentium :-)

But the discussion was interessting and i learn a lot. Thank you!

best regards

Bernhard


-- 
 -------------------------------------------------------------------  
| Bernhard Kuhn                (kuhn[at]lpr.ei.tum.de)  O|||OO||OO| |
| Laboratory for Process Control and Real-Time Systems  O|||O|O|O|O |
| Technische Universit�t M�nchen  Tel.+49-89-289-23732  O|||OO||OO| |
| 80290 M�nchen, Germany          Room 3944 Fax -23555  OOO|O|||O|O |
 --------------------------------------------------------------------

In comp.os.linux.hardware Totally Lost <idletime@my-deja.com> wrote:
> In article <3751F4D8.8C0C9B65@dakotacom.net>,
>   CB <NocbaisanSpam@dakotacom.net> wrote:

> [bulk of extensive interrogation deleted]

>> I am perfectly willing to entertain the possibility that some of your
> assertions
>> may be on the money - but you really didn't offer more than some
> general
>> theoretical arguments and cautions.  Well, I don't have a Linux server
> to run
>> through the paces, so I'm not much help either...
>>
>> CB

> It seems pointless to respond. I offered some seasoned caution, the
> concerns should be explored by anyone that is considering using a
> Celeron as a production server, or with other than small footprint
> applications. This guy appears both hostile, and doesn't even have
> a stake in the outcome.

> We are continually offered advise, some must personally experience the
> pain before they are convinced of negative outcomes. The Darwin awards
> exist for a reason :)

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.

C
-- 
Christopher Mauritz
ritz@mordor.net

And a post-note:

Dual celeron systems can be a cost-effective way to harness quite a bit
of CPU horsepower - these chips, while inexpensive, are of good quality
and design.  There are always limitations to any hardware setup. 
Understanding the strengths and limitations of a particular arrangement
can lead to more efficient use of the available resources - and to a
more effective system.


Totally Lost wrote:
> 
> In article <3751F4D8.8C0C9B65@dakotacom.net>,
>   CB <NocbaisanSpam@dakotacom.net> wrote:
> 
> [bulk of extensive interrogation deleted]

A wise choice as you had no specific information to provide.

> 
> > I am perfectly willing to entertain the possibility that some of your
> assertions
> > may be on the money - but you really didn't offer more than some
> general
> > theoretical arguments and cautions.  Well, I don't have a Linux server
> to run
> > through the paces, so I'm not much help either...
> >
> > CB
> 
> It seems pointless to respond.

But you did anyway ;-)

> I offered some seasoned caution, the
> concerns should be explored by anyone that is considering using a
> Celeron as a production server, or with other than small footprint
> applications. This guy appears both hostile, and doesn't even have
> a stake in the outcome.
> 
> We are continually offered advise, some must personally experience the
> pain before they are convinced of negative outcomes. The Darwin awards
> exist for a reason :)

As the cost of the equipment is low, the financial risk of
experimentation is also low.  Gigantism has been generally repudiated by
evolution.  Innovation and experimentation do not have to be confined to
those with unlimited hardware budgets.


> 
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.


  -----------== 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 ==-----

Totally Lost wrote:
> 
> It seems pointless to respond. I offered some seasoned caution, the
> concerns should be explored by anyone that is considering using a
> Celeron as a production server, or with other than small footprint
> applications.

Fair enough

CB


  -----------== 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 ==-----

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 ==-----