[CentOS] Hot swap CPU

[Peter Arremann]

> 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.