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
