Article View: comp.os.linux.hardware
Article #517Re: Dual Celeron's and SMP Performance Problems
From: Totally Lost
Date: Thu, 27 May 1999 00:00
Date: Thu, 27 May 1999 00:00
160 lines
8399 bytes
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-mailReferences:
<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)