From: Rodrigo Barbosa <rodrigob at suespammers.org>> Btw, don't quote me on this one :) > I'm only 90% sure of the hotswapping capabilities, and less than 50% > sure about the price :)There _are_ systems with hot-swap CPUs, memory and/or, PCI[-X] slots. They are _not_ commodity and pricey, and require OS-level support. In fact, I believe Linux 2.6 has some support for hot-swap -- at least at the PCI[-X] level, if not memory and possibly CPU as well. It requires extensive support though for that type of "dynamic" flexibility. -- Bryan J. Smith mailto:b.j.smith at ieee.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jun 29, 2005 at 12:59:24PM -0500, Bryan J. Smith <b.j.smith at ieee.org> wrote:> From: Rodrigo Barbosa <rodrigob at suespammers.org> > > Btw, don't quote me on this one :) > > I'm only 90% sure of the hotswapping capabilities, and less than 50% > > sure about the price :) > > There _are_ systems with hot-swap CPUs, memory and/or, PCI[-X] slots. > They are _not_ commodity and pricey, and require OS-level support. > > In fact, I believe Linux 2.6 has some support for hot-swap -- at least > at the PCI[-X] level, if not memory and possibly CPU as well. It > requires extensive support though for that type of "dynamic" flexibility.Memory hotswap ? Sounds fishy to me, at least on IA32{,e} platforms. Are you sure about that ? []s - -- Rodrigo Barbosa <rodrigob at suespammers.org> "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCwuS4pdyWzQ5b5ckRAjSTAJ9hXlQ3kT4JAjSkkn/4QmYrKTFfcwCgkcPv hsj3g/oh3Fy68DZmGXCygAI=y7II -----END PGP SIGNATURE-----
Compaq/HP Proliant DL580/DL760 both have this.> -----Original Message----- > From: centos-bounces at centos.org > [mailto:centos-bounces at centos.org] On Behalf Of Rodrigo Barbosa > Sent: Wednesday, June 29, 2005 1:13 PM > To: CentOS mailing list > Subject: Re: [CentOS] Hot swap CPU > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, Jun 29, 2005 at 12:59:24PM -0500, Bryan J. Smith > <b.j.smith at ieee.org> wrote: > > From: Rodrigo Barbosa <rodrigob at suespammers.org> > > > Btw, don't quote me on this one :) > > > I'm only 90% sure of the hotswapping capabilities, and > less than 50% > > > sure about the price :) > > > > There _are_ systems with hot-swap CPUs, memory and/or, > PCI[-X] slots. > > They are _not_ commodity and pricey, and require OS-level support. > > > > In fact, I believe Linux 2.6 has some support for hot-swap > -- at least > > at the PCI[-X] level, if not memory and possibly CPU as well. It > > requires extensive support though for that type of > "dynamic" flexibility. > > Memory hotswap ? > Sounds fishy to me, at least on IA32{,e} platforms. Are you > sure about that ? > > []s > > - -- > Rodrigo Barbosa <rodrigob at suespammers.org> "Quid quid Latine > dictum sit, altum viditur" > "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (GNU/Linux) > > iD8DBQFCwuS4pdyWzQ5b5ckRAjSTAJ9hXlQ3kT4JAjSkkn/4QmYrKTFfcwCgkcPv > hsj3g/oh3Fy68DZmGXCygAI> =y7II > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS mailing list > CentOS at centos.org > lists.centos.org/mailman/listinfo/centos > > -- > This message has been scanned for viruses and dangerous > content by MailScanner, and is believed to be clean. > >-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
From: Rodrigo Barbosa <rodrigob at suespammers.org>> Memory hotswap ? Sounds fishy to me, at least on IA32{,e} > platforms. Are you sure about that ?Yes. They are proprietary NUMA implementations of both IA-32 Xeon and IA-64 Itanium that allow all sorts of swapping, largley via a daughtercard (i.e., the memory comes out with the CPU on a single board). In reality, this is really an area where Blades are more manageable for far less cost though. -- Bryan J. Smith mailto:b.j.smith at ieee.org
Bryan J. Smith <b.j.smith at ieee.org> wrote:> From: Rodrigo Barbosa <rodrigob at suespammers.org> > >>Btw, don't quote me on this one :) >>I'm only 90% sure of the hotswapping capabilities, and less than 50% >>sure about the price :) > > > There _are_ systems with hot-swap CPUs, memory and/or, PCI[-X] slots. > They are _not_ commodity and pricey, and require OS-level support.Sun EXX00 + series running UltraSparc II and above have pretty much hot swapable everything: cpu, memory, disks etc. And they are cheap on ebay these days (8-24 way 400 Mhz US-II (64-bit), with anywhere from 2-14 GB memory and FC-AL IO etc. EX500).
Sorry to disrupt the thread - my mail reader chewed up half my inbox today... alex at milivojevic.org wrote:> E4500 is discontinued for some time now. It is rather old machine, much > older that the above mentioned P4. I doubt that Peter's intention was to > compare speed of Sun's server in general with the speed of > latest-and-greates P4 systems. I hope that he simply forgot to mention > how much older that E4500 is than the P4 box.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 :-) <snip>> People that buy E4500 nowdays are either buying them for spare parts, or > they simply want redundant box exactly the same as the old box they > already have. Or people that simply need some Sparc hardware around, > but don't want to spend money on current line of Sun's servers and don't > care if the system is slow as long as it does the job (my guess is > Peter's company falls into this category, from what he wrote, otherwise > they would be running their Sparc builds on something more recent)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. A build that can be done on a single cpu linux box (3.2Ghz P4) is a fraction of the time of that V440 time... Compiles aren't a great benchmark for a box since its 100% cpu and neglects memory or disk performance but I had the numbers handy for that :-) 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. 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... Peter.
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_ "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 at ieee.org
From: Peter Arremann <loony at loonybin.org>> *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?)...Dude, compared to modern UltraSPARC III/IV, _yes_ they _are_ slow. But there are a lot of UltraSPARC II options that are still quite viable solutions.> 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?Dude, this is _not_ about "winning an argument." It's about reminding you that "build times" are _not_ a good indictator of _server_ benchmark (please note that I said _server_). I mean, if you want to see one benchmark that Intel has _always_ lost to AMD -- and handily -- build times are it. ;->> That's why I made the comment that you so nicely cut out :-) > 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...Dude, stop with the resume. The problem with pulling credentials is that someone else _always_ has more. Now stop while you _think_ you are "ahead." ;->> 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?Once again, I will re-iterate, there are _other_ performance considerations than computational. And even then, "build" times are _not_ very representative of performance in even some computational> 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...Depends on if you are computationally limited, and also what is your I/O -- let alone the number of sessions you are serving. In raw, unthreaded, linear aspects -- hell yes, the E4500 is a _dog_.> 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...It all depends on how distributed your environment works, as well as the application. I'm not saying an old UltraSPARC II platform is always going to be faster. But man, you are like a single track that thinks there are _no_ other considerations. -- Bryan J. Smith mailto:b.j.smith at ieee.org
From: Peter Farrow <peter at farrows.org>> looks like the 4500 came second to me by a fair margin, > between 3x and 5x faster best case,"Best case" would be something that scales linearlly over many processors with minimal (<0.1GBps) inter-CPU interconnect, which is exactly what a cluster (using GbE) is. In other cases, the old UltraSPARC II was able to keep within ~60% or so, and that's not even looking at the fact that it only had 2GB -- which _each_ dual-P4 node had as well.> not what Iwould call limping away. > Anyway that's enough of this thread, kill it now.....Here's my final statement. I have never debated that the P4 isn't more capable than old UltraSPARC II processors when something clearly relies on ALU/FPU. Heck, I _still_ deploy refurb/unused dual-P3 850MHz-1.4GHz systems because of this (especially when interconnect is not the bottleneck). But there _are_ cases where a more capable interconnect is what is needed. In those cases, even some older, cheap UltraSPARC II NUMA/UPA platforms are very useful. E.g., we're currently using a 8-way UltraSPARC II as our near-line/ off-line disk/tape backup server, and it's using multiple out-of-band and storage interconnects. Now yes, a 4-way HP DL585 would have been much nicer, and even far more interconnect. But it's clearly better than a 2-way P4 for what we're using it for. -- Bryan J. Smith mailto:b.j.smith at ieee.org