For actual server names, we use 3 character prefixes to denote use (prd, dev, ttf for tech test facility, vrf for verfication, etc), then 2 chars for os type (lx for linux, ai for aix, ux for hp-ux and sx for solaris), then a 3 digit sequence that is unique across each use... prdux001, prdai007, etc.
rather uninteresting to be sure... but not something we had a choice in due to constraints by management
so... when we started to get partitionable 'frames', such as Power4/5/6 frames by IBM, or our Sun 12Ks, we started naming them after 'imaginary locations', such as Minis Tirith, Romulus, Vulcan, etc... usually centered on Star Trek, Star Wards, LoTR, etc...
Of course, one person named a frame Alpha Centauri, and had to be clued in that that wasn't an imaginary place....
so now the flood gates have opened and we have Gorgo and Arlen and Quahog, etc
Excellent point! Depends on what the meaning of the word "core" is, to paraphrase a former president.
IBM's Power4 came out years ago as "dual core" on the same chip. Little fan fare. The cores share L3 cache (now they're all doing that too), but little else, and you really got 2X+ performance from their multi-core implementation.
I believe Sun implemented (questionable word here) dual core in enough of a different way so that you really get less than 2X performance over a comparable speed single core chip. I do know that BEA charges us about 1.7X price on a socket-to-socket comparison, so that says a little about what they think the relative performance is. But I digress.
Our Sun rep was kind enough to point out a recent TPC-H metric that had Sun beating IBM in raw performance by 5%, but I don't think he caught the details in the footnotes, which I tend to gravitate to.
To summarize my observation:
After raw performance, if you take cost into account (and who doesn't?), IBM is the less expensive option. And that 5% raw performance increase comes at the expense of 12.5% more CPUs (72 vs. 64). And if we're counting "cores", then IBM's is still 64-way, but Sun's jumps to 144... so if you have other s/w that's licensed by core that you want to run on that same box, well, do the math.
I'm not disagreeing that Sun's approach has some value. It does and as I've said, our company has taken advantage of disimilar CPU speed boards.
IBM's approach would require the replacement of all CPUs IF you wished to upgrade to any faster CPUs within an existing chassis.
My original point was that Sun's backplane, as a technology, runs at a fixed speed regardless. IBM's does not. So with IBM's I can have one server with certain CPUs having a certain backplane speed, I can have a newer server with faster CPUs, and it benefits from a faster backplane.
With Sun's approach, my older system with 750MHz CPUs, as well as my newer system with 1.05GHz CPUs have the same backplane speed.
To *me*, that's a silly restriction. I place more value on being able to increase overall system performance, rather than combining multiple CPU speeds.
So, getting back to the thread topic, while Sun can certainly keep increasing speeds and cores and threading and all that gee-whiz stuff dealing with CPUs, their earlier decisions regarding system architecture, to me, will limit overall system performance in the long run.
More flexible to add boards of different speeds, which is a plus. But less flexible in that you must delineate OS image boundries on a board by board basis, with means at a 2 or 4 CPU granularity, and with whatever memory is on that board. With IBM's Power4 systems, we can create 1, 2, 3, 4, etc. CPU LPARs with much finer control over memory resources. And I never even mentioned IO; IBM's PCI slot assignment is at the slot by slot level, so for example, slot 1 can be in one LPAR, and slot 2 in another LPAR. MUCH finer granularity and therefore flexibility in creating OS images.
Sun does allow mixed CPU speeds, and to facilitate that, they nailed the backplane speed. That is one of their "value propositions", and one which my company has taken advantage of.
IBM's Power4-based systems do not allow mixed CPU speeds, because they scale the backplane at 1/3 CPU. One of their value props is higher overall system performance as CPU speeds scale. So for larger SMP-based LPARs, potentially higher overall system performance would result.
I am not as current on HP h/w architecture so I'd leave that to others who are.
Yes, I understand it's a gee-whiz piece of engineering... sheesh... And if you multiply one number times another times another, you get 172.8. Big whoop... The point was that IT'S FIXED SPEED... how will Sun ever increase the scalability now that they've got customers (a few anyways) running 2 or more different CPU speeds? Other companies snoop for cache coherency, etc., AND scale clock speed.
As for containers or zones or whatever their latest scheme is, we'll see if that's what customers really want, or something Sun figured out it could do to try to play catch up and compensate for poor hardware design. Only time will tell.
If you don't HAVE to talk thru a backplane, that would be great. But when required, faster backplanes are better, no?
I guess my point about Sun's board/domain approach is that it's less flexible. If these "zones" work out, good for them but it remains to be proven it works.
The backplane is what facilitates communication between CPU boards. Yes, they *rate* throughput at 9.6GBps, and that may be the rate. Of course they have more throughput than (typical) Intel machines; those are generally lower-cost machines and they don't have the margins to support high-end features such as high-bandwidth backplanes. My point is that Sun's CAN'T really improve, as they've nailed the clock speed to support multi-speed CPU boards. IBM's backplanes scale 1:3 with CPU speed; you have to have all CPUs at the same rate (e.g. 1.1GHz, 1.45GHz, 1.9GHz), but the backplane is scaled at 1/3, or 367MHz, 483MHz, 633MHz, etc. IBM's backplane CAN increase sustained throughput as faster CPUs are installed, for better overall system scalability.
As for domains with greater h/w isolation vs. LPARs/VPARs with more flexibility; all I'm saying is that IBM and HP have designed in the ability to offer single and sub-CPU system images because as CPU speeds increase, how many systems will really require 4 / 8 / 16 + CPUs in a single system image? Our company is stinking with 1 and 2 CPUs DB servers and we could see having sub-CPU LPARs for tech test / dev servers...
1. That must be why Sunfires are flying out the door...
2. They HAD to come up with something to counter LPARs, etc... the market shifted and they got caught with their domain's down at their ankles... of course, no doubt IBM and HP could (and frankly, maybe have) come up with something akin to zones / containers as well, ON TOP OF h/w LPARs... the fact remains, better h/w flexibility
Any advances Sun may have in CPU performance will be greatly outweighed by two major engineering design flaws they've gotten themselves in to:
1. overall system performance of their partitionable systems (i.e. the ones people will pay a premium for over low-end systems where Linux on Intel/AMD is killing them) is severely hampered by their 150MHz (Mhz!) backplane. Sun views this as a plus because it allows customers to run boards with differenc CPU speeds (e.g. a 750MHz board (5x backplane speed) and a 900MHz board (6x backplane speed)). So, board to board thruput suffers and overall scalability is reduced.
2. Their desire for greater hardware isolation between domains, down to only a 2 or 4 CPU board with whatever memory happens to be installed on those boards, severely limits the flexibility in providing workload management between logical servers (domains), as well as less flexibility to create / deploy fewer, smaller servers. IBM's LPAR architecture, and HP's VPARs, are kicking Sun's ASS!
Well, in light of the fact that the Sun, and Solaris in general, are crap, and your lack of understanding of what QM analysis entails, I'll explain.
The Sun was leased to replace an older 4500 that wasn't doing the job. The trouble was, the 6800, at 24 CPUs and 72GB of memory, can't either. You see, QM is short of Quantitative Methods. That's number crunching to you. It's a CPU-intensive application, and there is next to nothing for IO or memory utilization. The 6800 was a poor choice to begin with but the QM department was partial to Suns and that's history.
So, yes, we have spent a bit of additional cash, but going forward it would cost considerably more to increase computational capacity, what with the price of Sun systems and all. We'll buy out the lease and after purchase of the blades and RHAS licenses, we'll still have less than a 6 month ROI.
Spending a relatively little bit on very fast Xeons for a CPU-intensive task does make sense. Our clients will have 2x the processing power to start with, and a very small cost to increase that even more when they wish to.
Maybe not brilliant, but it is smart. I guess, if you want to save money...
We just placed an order for 24 copies of RHAS and are about to plunk down some serious coin on IBM Blade frames... we're ripping out a Sun 6800 used for QM analysis, so the net will be to save tons o' cash...;)
I wouldn't say our company isn't concerned about the lawsuit, but our lawyers, er, Corporate Counsel, basically ripped up SCOs claims for our management's benefit.
If this project is a success, we're looking to leverage Linux at every opportunity we get.
and a utility like AIX' mksysb, or ideally IBM's Sysback product, to be able to make a bootable tape / cd / dvd that contains a recovery image to recreate a system, on different hardware and with the ability to change a lot of the system configs before restoring
Someone stepping up and trying to use technology, not squash it! Personally, there are lots of shows I go to that I'd like a recording of and have started downloading shortens and burning them myself. I don't know if my price point is $15 or not, tho.
Of course, the shows where they're going to record they probably wouldn't allow tapers...
Awhile back we received a shipment from HP that contained a rack, K-class server and external disk array, etc. all pre-racked for us. Well, the box didn't look good at all, so we noted the condition of the box on the packing list, and called in one of their CEs to unband it for inspection. The damn thing was mangled quite well inside! We promptly wrote down the serial numbers of the rack, the server, each and every disk drive, and told HP to take it away, ship us a brand new one of everything, and we never want to see any of these serial numbers again.
Slashdot Mirror
I forgot to add... we have nearly 700 Unix/Linux servers...
For actual server names, we use 3 character prefixes to denote use (prd, dev, ttf for tech test facility, vrf for verfication, etc), then 2 chars for os type (lx for linux, ai for aix, ux for hp-ux and sx for solaris), then a 3 digit sequence that is unique across each use... prdux001, prdai007, etc.
rather uninteresting to be sure... but not something we had a choice in due to constraints by management
so... when we started to get partitionable 'frames', such as Power4/5/6 frames by IBM, or our Sun 12Ks, we started naming them after 'imaginary locations', such as Minis Tirith, Romulus, Vulcan, etc... usually centered on Star Trek, Star Wards, LoTR, etc...
Of course, one person named a frame Alpha Centauri, and had to be clued in that that wasn't an imaginary place....
so now the flood gates have opened and we have Gorgo and Arlen and Quahog, etc
Excellent point! Depends on what the meaning of the word "core" is, to paraphrase a former president.
IBM's Power4 came out years ago as "dual core" on the same chip. Little fan fare. The cores share L3 cache (now they're all doing that too), but little else, and you really got 2X+ performance from their multi-core implementation.
I believe Sun implemented (questionable word here) dual core in enough of a different way so that you really get less than 2X performance over a comparable speed single core chip. I do know that BEA charges us about 1.7X price on a socket-to-socket comparison, so that says a little about what they think the relative performance is. But I digress.
Our Sun rep was kind enough to point out a recent TPC-H metric that had Sun beating IBM in raw performance by 5%, but I don't think he caught the details in the footnotes, which I tend to gravitate to.
To summarize my observation:
After raw performance, if you take cost into account (and who doesn't?), IBM is the less expensive option. And that 5% raw performance increase comes at the expense of 12.5% more CPUs (72 vs. 64). And if we're counting "cores", then IBM's is still 64-way, but Sun's jumps to 144... so if you have other s/w that's licensed by core that you want to run on that same box, well, do the math.
I'm not disagreeing that Sun's approach has some value. It does and as I've said, our company has taken advantage of disimilar CPU speed boards.
IBM's approach would require the replacement of all CPUs IF you wished to upgrade to any faster CPUs within an existing chassis.
My original point was that Sun's backplane, as a technology, runs at a fixed speed regardless. IBM's does not. So with IBM's I can have one server with certain CPUs having a certain backplane speed, I can have a newer server with faster CPUs, and it benefits from a faster backplane.
With Sun's approach, my older system with 750MHz CPUs, as well as my newer system with 1.05GHz CPUs have the same backplane speed.
To *me*, that's a silly restriction. I place more value on being able to increase overall system performance, rather than combining multiple CPU speeds.
So, getting back to the thread topic, while Sun can certainly keep increasing speeds and cores and threading and all that gee-whiz stuff dealing with CPUs, their earlier decisions regarding system architecture, to me, will limit overall system performance in the long run.
The problem is that you don't understand my original point.
More flexible to add boards of different speeds, which is a plus. But less flexible in that you must delineate OS image boundries on a board by board basis, with means at a 2 or 4 CPU granularity, and with whatever memory is on that board. With IBM's Power4 systems, we can create 1, 2, 3, 4, etc. CPU LPARs with much finer control over memory resources. And I never even mentioned IO; IBM's PCI slot assignment is at the slot by slot level, so for example, slot 1 can be in one LPAR, and slot 2 in another LPAR. MUCH finer granularity and therefore flexibility in creating OS images.
Sun does allow mixed CPU speeds, and to facilitate that, they nailed the backplane speed. That is one of their "value propositions", and one which my company has taken advantage of.
IBM's Power4-based systems do not allow mixed CPU speeds, because they scale the backplane at 1/3 CPU. One of their value props is higher overall system performance as CPU speeds scale. So for larger SMP-based LPARs, potentially higher overall system performance would result.
I am not as current on HP h/w architecture so I'd leave that to others who are.
Yes, I understand it's a gee-whiz piece of engineering... sheesh... And if you multiply one number times another times another, you get 172.8. Big whoop... The point was that IT'S FIXED SPEED... how will Sun ever increase the scalability now that they've got customers (a few anyways) running 2 or more different CPU speeds? Other companies snoop for cache coherency, etc., AND scale clock speed.
As for containers or zones or whatever their latest scheme is, we'll see if that's what customers really want, or something Sun figured out it could do to try to play catch up and compensate for poor hardware design. Only time will tell.
If you don't HAVE to talk thru a backplane, that would be great. But when required, faster backplanes are better, no?
I guess my point about Sun's board/domain approach is that it's less flexible. If these "zones" work out, good for them but it remains to be proven it works.
The backplane is what facilitates communication between CPU boards. Yes, they *rate* throughput at 9.6GBps, and that may be the rate. Of course they have more throughput than (typical) Intel machines; those are generally lower-cost machines and they don't have the margins to support high-end features such as high-bandwidth backplanes. My point is that Sun's CAN'T really improve, as they've nailed the clock speed to support multi-speed CPU boards. IBM's backplanes scale 1:3 with CPU speed; you have to have all CPUs at the same rate (e.g. 1.1GHz, 1.45GHz, 1.9GHz), but the backplane is scaled at 1/3, or 367MHz, 483MHz, 633MHz, etc. IBM's backplane CAN increase sustained throughput as faster CPUs are installed, for better overall system scalability.
As for domains with greater h/w isolation vs. LPARs/VPARs with more flexibility; all I'm saying is that IBM and HP have designed in the ability to offer single and sub-CPU system images because as CPU speeds increase, how many systems will really require 4 / 8 / 16 + CPUs in a single system image? Our company is stinking with 1 and 2 CPUs DB servers and we could see having sub-CPU LPARs for tech test / dev servers...
1. That must be why Sunfires are flying out the door...
2. They HAD to come up with something to counter LPARs, etc... the market shifted and they got caught with their domain's down at their ankles... of course, no doubt IBM and HP could (and frankly, maybe have) come up with something akin to zones / containers as well, ON TOP OF h/w LPARs... the fact remains, better h/w flexibility
Any advances Sun may have in CPU performance will be greatly outweighed by two major engineering design flaws they've gotten themselves in to:
1. overall system performance of their partitionable systems (i.e. the ones people will pay a premium for over low-end systems where Linux on Intel/AMD is killing them) is severely hampered by their 150MHz (Mhz!) backplane. Sun views this as a plus because it allows customers to run boards with differenc CPU speeds (e.g. a 750MHz board (5x backplane speed) and a 900MHz board (6x backplane speed)). So, board to board thruput suffers and overall scalability is reduced.
2. Their desire for greater hardware isolation between domains, down to only a 2 or 4 CPU board with whatever memory happens to be installed on those boards, severely limits the flexibility in providing workload management between logical servers (domains), as well as less flexibility to create / deploy fewer, smaller servers. IBM's LPAR architecture, and HP's VPARs, are kicking Sun's ASS!
Well, in light of the fact that the Sun, and Solaris in general, are crap, and your lack of understanding of what QM analysis entails, I'll explain.
The Sun was leased to replace an older 4500 that wasn't doing the job. The trouble was, the 6800, at 24 CPUs and 72GB of memory, can't either. You see, QM is short of Quantitative Methods. That's number crunching to you. It's a CPU-intensive application, and there is next to nothing for IO or memory utilization. The 6800 was a poor choice to begin with but the QM department was partial to Suns and that's history.
So, yes, we have spent a bit of additional cash, but going forward it would cost considerably more to increase computational capacity, what with the price of Sun systems and all. We'll buy out the lease and after purchase of the blades and RHAS licenses, we'll still have less than a 6 month ROI.
Spending a relatively little bit on very fast Xeons for a CPU-intensive task does make sense. Our clients will have 2x the processing power to start with, and a very small cost to increase that even more when they wish to.
Maybe not brilliant, but it is smart. I guess, if you want to save money...
Dip Shit!
We just placed an order for 24 copies of RHAS and are about to plunk down some serious coin on IBM Blade frames... we're ripping out a Sun 6800 used for QM analysis, so the net will be to save tons o' cash... ;)
I wouldn't say our company isn't concerned about the lawsuit, but our lawyers, er, Corporate Counsel, basically ripped up SCOs claims for our management's benefit.
If this project is a success, we're looking to leverage Linux at every opportunity we get.
and a utility like AIX' mksysb, or ideally IBM's Sysback product, to be able to make a bootable tape / cd / dvd that contains a recovery image to recreate a system, on different hardware and with the ability to change a lot of the system configs before restoring
Now kids, what's needed in Linux to really play with the big boyz (HP-UX, AIX and possibly others, but NOT that toy Solaris) is:
tighter integration with the hardware to be able to report hardware issues / errors, a la' AIX error log
ability to 'clone' root disks and run an upgrade in parallel to full operation, then simply reboot to realize the upgrade
multi-path i/o to disks, like HP-UX pvlinks, for redundancy, load balancing would be better yet
lvm support in the kernel so you can boot from a lv (does Linux have that yet?)
real support for things like fiber channel and gigabit ethernet, to make it work in real datacenters
Someone stepping up and trying to use technology, not squash it! Personally, there are lots of shows I go to that I'd like a recording of and have started downloading shortens and burning them myself. I don't know if my price point is $15 or not, tho.
Of course, the shows where they're going to record they probably wouldn't allow tapers...
But, it's a step in the right direction.
watch commercials during shows I've recorded for my own user?!?!?!
Yeah, right. That's the day I rip out my cable and record off the ol' rabbit ears...
No wonder the Cable Guy wants PVR functionality to be at the head end; so they can monitor usage...
Just Say No.
C. Ash, and the salesperson 'got it' and stopped asking questions...
I tried that once and they asked for my address, so I pointed out how slow they were and that's when they stopped asking questions...
That was funny! Was I the only one to get the joke?
(jeez, maybe that should scare me... )
Awhile back we received a shipment from HP that contained a rack, K-class server and external disk array, etc. all pre-racked for us. Well, the box didn't look good at all, so we noted the condition of the box on the packing list, and called in one of their CEs to unband it for inspection. The damn thing was mangled quite well inside! We promptly wrote down the serial numbers of the rack, the server, each and every disk drive, and told HP to take it away, ship us a brand new one of everything, and we never want to see any of these serial numbers again.