> From: Peter Arremann <loony at 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.