From: Peter Arremann loony@loonybin.org
Actually that was exactly the point. The email I responded to was mentioning ancient US-I/II frames as a solution for the hotswap issue. My point was that for the same cost I can get a 8way E4500/400/4MB or a nice P4 PC... From the speed perspective you'll be hard pressed to find an app that is faster on the sun and the age of the E4500 negates any advantage it used to have in reliability. The E4500 doesn't even have redundant power :-)
Be careful with your continued assertions. I/O on the P4 (and the PC platform) _sucks_ compared to many of these solutions. PCIe is _not_ the "holy grail" for a platform that has some severe bottleneck issues in its design, let alone when we're talking a single processor versus a partial mesh system with a _real_ "system interconnect." ;->
Reality: Even a 200MHz, non-superscalar microcontroller prototype boards can handle 500MBps+ of storage I/O, but many PC mainboard I/O designs can_not_. ;->
I was giving the E4500 as a comparison because it costs the same. Unfortunately we got apps here that outgrow F15K frames - performance can't ever be good enough. But even if you get a V440 (from integer processing the currently fastest cpu Sun has to offer) you're still so much slower when doing compiles.
Once again, I will re-iterate, build times are _not_ a good "server benchmark" at all. If they were, then I don't know why _anyone_ would buy Intel -- AMD _roasts_ P4 _over_ 2:1 MHz for MHz.
Anyway, point I was trying to make is that if anyone points a US-II based frame today they are mistaken about its performance and reliability.
I don't think people were asserting "build" time at all, let alone performance in general. But there are some advantages to deploying even older SPARC platforms in some areas.
It's obvious your experience has largely been in "build" or "dynamic web app" benchmarks. Please be considerate that it's not the _only_ "performance" consideration out there. ;->
Just the disks in D1000 trays are so much of a headache that you wouldn't believe it. And Sun doesn't support booting of EMC on the smaller frames - so you need some local attached storage...
There are options around that in various hardware selections. But yes, Sun does have some stock SAN limitations.
-- Bryan J. Smith mailto:b.j.smith@ieee.org
From: Peter Arremann loony@loonybin.org
Actually that was exactly the point. The email I responded to was mentioning ancient US-I/II frames as a solution for the hotswap issue. My point was that for the same cost I can get a 8way E4500/400/4MB or a nice P4 PC... From the speed perspective you'll be hard pressed to find an app that is faster on the sun and the age of the E4500 negates any advantage it used to have in reliability. The E4500 doesn't even have redundant power :-)
Be careful with your continued assertions. I/O on the P4 (and the PC platform) _sucks_ compared to many of these solutions. PCIe is _not_ the "holy grail" for a platform that has some severe bottleneck issues in its design, let alone when we're talking a single processor versus a partial mesh system with a _real_ "sysem interconnect." ;->
*rofl* either you forgot how damned slow a E4500 is or you never worked with them... There is _nothing_ fast about them (see, I learned how to use the underscore from you, aren't you happy?)...
Reality: Even a 200MHz, non-superscalar microcontroller prototype boards can handle 500MBps+ of storage I/O, but many PC mainboard I/O designs can_not_. ;->
I was giving the E4500 as a comparison because it costs the same. Unfortunately we got apps here that outgrow F15K frames - performance can't ever be good enough. But even if you get a V440 (from integer processing the currently fastest cpu Sun has to offer) you're still so much slower when doing compiles.
Once again, I will re-iterate, build times are _not_ a good "server benchmark" at all. If they were, then I don't know why _anyone_ would buy Intel -- AMD _roasts_ P4 _over_ 2:1 MHz for MHz.
Oh - misquote to omit my acknowledgment of the inadequacy of my comparison. What was the reason for you leaving off where I said "compilers aren't a good benchmark"? :-) Are you that desperate to win an agrument that you have to misquote me to infer that I'm saying something else?
Anyway, point I was trying to make is that if anyone points a US-II based frame today they are mistaken about its performance and reliability.
I don't think people were asserting "build" time at all, let alone performance in general. But there are some advantages to deploying even older SPARC platforms in some areas.
That's why I made the comment that you so nicely cut out :-)
It's obvious your experience has largely been in "build" or "dynamic web app" benchmarks. Please be considerate that it's not the _only_ "performance" consideration out there. ;->
Performance tuning of provisioning apps is another thing I do :-) Working for a fortune 5 and dealing with the biggest systems that company has can be fun... 4TB databases, used by Java and C++ programs, 48way 96GB ram... that a better example or still too small for you to accept that I might not just do little things?
An Athlon64 3200+/4GB running on a 3ware controller with mirrored disks beats an 8way E4500/4GB running a 400GB oracle database... give the sun box 8GB and the performance is roughly equal...
Just the disks in D1000 trays are so much of a headache that you wouldn't believe it. And Sun doesn't support booting of EMC on the smaller frames - so you need some local attached storage...
There are options around that in various hardware selections. But yes, Sun does have some stock SAN limitations.
Yes, and one of the limitations on the E4500 is throughput... A 3510 on a v490 does 61MB/sec - same lun, just connected into the SUNW,socal of a E4500 IO board does about 20MB/sec...
Peter.
-
Bryan J. Smith <b.j.smith＠ieee.org> -
Peter Arremann