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