[CentOS] maximum cpus/cores in CentOS 4.1

[Lamar Owen]

On Friday 09 September 2005 18:06, William Warren wrote:
> Actually,  the other person that Bryan is talking to is saying things
> that are wholly wrong.

You know, my name is not hard to spell.

> Wrong to the point that even a non-engineer type 
> like me knows how off-base the other party is.  Bryan is understandably
> agitated but the other party needs to do a bit of research(easily done
> on google) about cpu and i/o interconnects in a high i/o environment.

Stop.  Go back and reread the original post.  I said:
"Certainly the 8x Opteron 
will be faster on many things; but under heavy multiuser load the 14-way 
SPARC does a surprisingly good job, with around three quarters the 
performance of a dual 3GHz Xeon (that outclasses the SPARC box in every way 
possible except interconnect) at a load average of 30 or so. "

I mentioned nothing there that is patently wrong.  I did a simple benchmark 
that showed the E6500 held up nicely under load.  Made a simple statement 
about it performing AROUND (that is, approximately) 75% of a different box's 
speed.

This was not an engineering-type post; while my degree IS in engineering, I 
made a very simple general observation of the capabilities of a crossbar 
interconnected system versus a bus-type system.

Exactly where is that completely wrong?  Where is that off-base?  I said the 
E6500 was outclassed in every way EXCEPT interconnect BY a Xeon box: I said 
NOTHING about an Opteron box except the very broadest generalization (since I 
don't have an Opteron on hand to try it out on).

Further, this very E6500 is the one that I'm offering as a build box for 
CentOS SPARC; this makes that portion on topic for, if not this list, the 
-devel list.

You can benchmark the dual Xeon against an 8x Opteron yourself.

As to research on I/O interconnects in a high I/O environment, been there, 
done that.  There is more to a server's load than I/O.  I have an 
application, IRAF, that is very compute intensive.  Raw FPU gigaflops matters 
to this application, which runs in a client-server mode.  Raw FPU gigaflops 
rises in standard stored program architectures roughly linearly with clock 
speed (this is of course not true in massively parallel and DEL-type 
architectures (such as SRC's MAP processor (getting a MAPstation here for 
real-time cross-correlation interferometry))); and, given a particular 
processor (say, SPARC) getting more clock speed will usually (but of course 
not always) get you more FPU power.  

But that's not relevant.

The original post was simply that the Linux kernel does well with a large 
number of processors, at least on SPARC.  Good grief.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu