Slashdot Mirror


HP Announces ARM-Based Server Line

sammcj writes with news that HP is developing servers based on 32-bit ARM processors from Calxeda. Their current model is only a test setup, but they plan to roll out a finalized design by the middle of next year. "HP's server design packs 288 Calxeda chips into a 4U rack-mount server, or 2,800 in a full rack, with a shared power, cooling, and management infrastructure. By eliminating much of the cabling and switching devices used in traditional servers and using the low-power ARM processors, HP says it can reduce both power and space requirements dramatically. The Redstone platform uses a 4U (7-inch) rack-mount server chassis. Inside, HP has put 72 small server boards, each with four Calxeda processors, 4GB of RAM and 4MB of L2 cache. Each processor, based on the ARM Cortex-A9 design, runs at 1.4GHz and has its own 80 gigabit cross-bar switch built into the chip"

125 comments

  1. Re:Obligatory by gmhowell · · Score: 0

    Make your own Beowulf cluster joke here.

    Where do the jokes about buying them on eBay go?

    --
    Jesus was all right but his disciples were thick and ordinary. -John Lennon
  2. it's begining of the end for x86 (hopefully) by Anonymous Coward · · Score: 0

    well, x86 arch. is becoming more and more of a drag on computing industry's advances,
    _any_ CISC CPU design eats up way more transistors and power than RISC based arch.,
    and while it's obvious to most, yet the whole windows/x86-compatibility baggage still keeps this
    power-hungry x86 mammoth alive..

    those good old days of hand-crafted human-friendly x86 assembly coding are long over,
    wake up Intel and Microsoft, put a nice tombstone on x86 and move on

    1. Re:it's begining of the end for x86 (hopefully) by staalmannen · · Score: 1

      What I wonder is what the differences are between the PA-RISC design from HP and the various ARM chips. They are both RISC types and I am sort of surprised that HP does not go with its own CPU architecture. What is the "magic sause" in ARM?

    2. Re:it's begining of the end for x86 (hopefully) by jones_supa · · Score: 1

      It's still amazing how well x86 + Windows works, taking in account all the hacks and legacy cruft involved. However, it's delightful to finally see ARM being more and more utilized outside the smartphone category, in PCs.

    3. Re:it's begining of the end for x86 (hopefully) by Chrisq · · Score: 1

      What I wonder is what the differences are between the PA-RISC design from HP and the various ARM chips. They are both RISC types and I am sort of surprised that HP does not go with its own CPU architecture. What is the "magic sause" in ARM?

      They are probably scared of oracle "doing an Itanium" on them.

    4. Re:it's begining of the end for x86 (hopefully) by serviscope_minor · · Score: 4, Informative

      It's still amazing how well x86 + Windows works, taking in account all the hacks and legacy cruft involved.

      The legacy cruft is often microcoded out and runs rather slowly. The modern x64 isn't too bad.

      However, it's delightful to finally see ARM being more and more utilized outside the smartphone category, in PCs.

      Not just ARM. Both SPARC and MIPS (compatible but independent) have now made showings in the top 10 supercomputers.

      --
      SJW n. One who posts facts.
    5. Re:it's begining of the end for x86 (hopefully) by Anonymous Coward · · Score: 0

      Are there any compatible reimplementations of ARM processors that don't pay royalties to ARM? At least Intel is kept honest by having to compete with AMD, even if AMD is currently losing. On the other hand, a future where ARM and Intel compete with each other could still result in healthy competition for the benefit of their customers.

    6. Re:it's begining of the end for x86 (hopefully) by DarkOx · · Score: 2

      As others have said PA-RISC has been discontinued for some time, so that is one reason. The other is I am pretty certain this thing is targeted at the Linux and [A-z]*.?BSD ecosystem, which has pretty strong support for ARM these days. The software stack for PA-RISC is just not there unless you want to run HPUX and the market for new HPUX deployments is probably quite small.

      80GBps switch or not you not probably running your database on these things, but they sound like a perfect web farm in box solution. The software stack on the Linux and [A-z]*.?BSD is entirely there for that and is largely familiar to existing admins. Apache on Linux is still Apache on Linux even when ARCH=arm5tel

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    7. Re:it's begining of the end for x86 (hopefully) by zach_the_lizard · · Score: 1

      all the hacks and legacy cruft involved.

      ARM has quite a bit of its own hacks to get platforms running. Linus Torvalds had his own rant against this, as he is wont to do.

      --
      SSC
    8. Re:it's begining of the end for x86 (hopefully) by Kagetsuki · · Score: 1

      Industry support and familiarity, availability of compilers, direct support by large projects (Debian, Ubuntu), and simply brand familiarity. I mean if you are going to make an argument about PA-RISC you may as well make the same argument about MIPS and whatever Motorola and IBM are calling their chips these days while you're at it.

    9. Re:it's begining of the end for x86 (hopefully) by swalve · · Score: 1

      It probably works quite well for virtualization.

    10. Re:it's begining of the end for x86 (hopefully) by ckaminski · · Score: 1

      IBM POWER has a HUGE Linux following - and it's officially supported on all of IBMs machines, from the lowest eServer to the largest of their mainframes.

    11. Re:it's begining of the end for x86 (hopefully) by hairyfeet · · Score: 0

      Can we PLEASE stop with the frankly batshit "Hey lets kill X86 herp derp" bullshit please? AMD is cranking out sub 9w dual cores WITH GPUs built in, Intel is cranking out CULV that get similar numbers so power draw on X86? Ain't shit folks unless you are talking about cell phones which thanks to Apple and the iSliver batteries means you have to run INSANELY low power to get any battery life.

      Each chip has its place, ARM for mobile and a few specialized niches (like in TFA where I'm sure it'll be for webservers that aren't getting many hits and thus the lower load makes it more advantageous to worry about power) and X86 for the big loads and and number crunching. Because like it or not cycle for cycle ARM gets royally stomped by even the lowest AMD and Intel X86 chips, go for the higher end chips and it isn't even funny.

      NSTAAFL folks and ARM is for power sipping and power sipping ALONE. Ramp it up so it can even crunch the kind of numbers a Core2Duo could from 2 generations ago? watch those power savings dry up and blow away like a fart in the breeze. saying ARM can replace X86-64 is like saying "Now that we have these mopeds we don't need trucks anymore!" Different tools for different jobs and I'd love to see you move a couch on that moped. The ONLY way ARM competes is by having tons of specialized chips like for decoding using DSPs which again raises the power usage and bye bye savings.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    12. Re:it's begining of the end for x86 (hopefully) by mzs · · Score: 1

      sparc and mips are not compatible at all. They are big endian (mips can be little endian sometimes) load/store RISC processors with 32 GPRs (though sparc has register windows) and that's about it in terms of similarity.

    13. Re:it's begining of the end for x86 (hopefully) by GameboyRMH · · Score: 1

      iPhone batteries are actually massive compared to those in most other phones. Look at the iPhone4's battery, it's freaking huge:

      http://cdn.slashgear.com/wp-content/uploads/2010/06/iphone_4_teardown1-540x399.jpg

      --
      "When information is power, privacy is freedom" - Jah-Wren Ryel
    14. Re:it's begining of the end for x86 (hopefully) by hairyfeet · · Score: 1

      Dude I grew up in the 80s, remember the "bag" phones? it was like carrying a car battery. that doesn't change the fact it was the iPhone that mades phone a fashion item and brought about the whole "thin is in" bit. hell look at what laptops were like before the Air came along, they were like bricks!

      It also doesn't change the fact that these bozos harping on about 'the death of X86" are still just wasting space. I mean what is the point? hell I get 6 hours of HD movie watching on my Brazos netbook thanks to it having a dual core PLUS a 40 stream processor GPU that all runs in a less than 9 watt envelope! And that isn't even as low as x86 can go, some of the high end Intel CULV can frankly just sip power and still give performance that is miles above anything ARM can provide.

      The troll that got butthurt because i burst his little bubble about ARM coming along and killing X86 (and I'm sure in his mind taking "they who shall not be named" along with it) can waste his mod points but it don't change reality. NSTAAFL, if you get ARM up to X86-64 levels of performance all its battery saving will be gone right out the window. in fact i bet if one were to make an ARM CPU that kept up with the latest AMD and Intel chips it would probably suck MORE power than X86 simply because AMD and Intel have had a hell of a lot more experience in lowering power than they have had in cranking up that kind of performance.

      I mean when you see the amount of data a new multicore X86 can crunch its truly amazing. If you'd have told me when i started out on the VIC or even when I got my first X86, which was a whole 60MHz, that we would have this much power on our desktops and even on the go I would have said you were insane. We have jumped to insane levels of performance in just this last decade, going from barely 1Ghz to 4Ghz multicores with GPU performance built in.

      ARM is great for mobile where power is everything, although frankly after getting to play with an ARM based netbook I'll stick with my Brazos E-350 thanks, and its great for embedded and industrial where hardening and lack of fans is a boon, and for certain niches I'm sure it'll be great for some server jobs, but to act like ARM is suddenly gonna come along and cause folks to throw out decades worth of X86 code and fall to their knees weeping in wonder is just delusional.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    15. Re:it's begining of the end for x86 (hopefully) by oursland · · Score: 1

      Not quite. ARM sells cores (for the most part) and OEMs integrate them into their custom chip. It is this customization that makes each chip so different. Had there been a single chip supplier, there wouldn't be this proliferation of "hacks" needed to boot, configure and use the chips.

  3. SATA?! by Anonymous Coward · · Score: 1, Insightful

    Come on, guys, it's 2011. We're talking servers here. Forget SATA; throw in native iSCSI support (or fibre channel, but iSCSI would probably be significantly easier - if only because it uses standard Ethernet ports, rather than needing extra protocol support), and you'll have something that's a serious contendor in that space.

    Think about it: with SATA, you have a bunch of hard disks, probably mostly disused, almost all of them performing atrociously (SATA is notorious for only being good with large sequential I/O). With iSCSI, you can hook up any disk array you damn well want, whatever its performance characteristics. Throw 10 Gb ethernet into the mix, and you have a winner (an expensive winner when you factor in the switch ports, but at least it gives the architect the option.)

    1. Re:SATA?! by Anonymous Coward · · Score: 0

      I know it's Slashdot... but this is covered in the linked articles, but since that's maybe a bit too much reading, there are four 10GbE ports on each of the four enclosures within the 4U chassis, connected to the server cards via an internal switch fabric within each of the four enclosures.

      The articles explicitly state external storage arrays - if you want internal HDD/SSD you give up some server cards to provide the space for it.

    2. Re:SATA?! by JoeMerchant · · Score: 1

      Has anybody seen the Googleplex "server" spec? from what little I've read, I'd assume they're on SATA.

    3. Re:SATA?! by UnknowingFool · · Score: 1

      It looks like a SATA cable is used but Google doesn't mention it specifically in the article.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    4. Re:SATA?! by datavirtue · · Score: 1

      Isn't it well known that they use cheap disks?

      --
      I object to power without constructive purpose. --Spock
    5. Re:SATA?! by swalve · · Score: 1

      I forget the exact specifics, but I think SAS can use the same cable. And those look like SCSI drives.

    6. Re:SATA?! by fuzzyfuzzyfungus · · Score: 1

      The fact that they've special-magic-backplane-fabric-ed away all the other busses, while leaving each card bristling with SATA connectors, seems rather weird, just because that's a lot of headers to bring out if nobody is going to use them and it'll be a hell of a rat's nest if you actually try(could they really not have stretched their backplane fabric a little bit more, to include allocating direct attached storage to nodes across it?).

      The use of SATA, though, seems reasonable enough, given the low-performance, low-cost, low-energy focus of the design. It just seems really weird that the connectors are on the cards, rather than their being a few high-density SAS connectors on the back, allowing you to either use an iSCSI device over the 10gigE ports or a big SATA/SAS cage directly cabled, with disks being farmed out over the backplane, rather than via internal SATA cabling...

    7. Re:SATA?! by Archangel+Michael · · Score: 1

      the functional difference between SATA and SAS is intelligence on the Drive. SATA is dumb compared to SAS. The pinouts and cables and all that were designed to be interoperable. I think SAS drives can be dumbed down to SATA if you need in a pinch, and SAS controllers can handle SATA drives natively (at least some can).

      --
      Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
    8. Re:SATA?! by mikael · · Score: 1

      Some classes of supercomputers have direct links from each node to individual hard disk drives in RAID configurations. It's part of the specification of a supercomputer:

      T2K Open Supercomputer Challenge

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
  4. Intel is annoyed by Anonymous Coward · · Score: 0

    I don't think Intel is going to be happy with that announcement. Anyway, we will have to wait since ARM-15 (late 2012) that has hardware virtualization and 64 bits to really see if ARM can compete with Intel.

    1. Re:Intel is annoyed by Anonymous Coward · · Score: 0

      There's no 64 bit support in Cortex A15.
      The 64 bits are for the chips made by the next gen spec - armv8.
      We'll have to wait for another 3-5 years before we see the on the shelf.

      Anyway - this is great news, finally a big player at the ARM/Sever market. And
      Calxeda seems to have a moment with its products.
      I wonder if this has something to do with the recent Ubuntu/ARM/Server 11.10 release,
      and the upcoming 12.04 LTS release.

    2. Re:Intel is annoyed by mevets · · Score: 1

      They could have named it Iceberg to really piss em off.

  5. How many platforms do they need? by unixisc · · Score: 1

    Let's count - they have Xeon/Opteron, Itanium, and among their dead platforms, they have PA-RISC, Alpha (DEC/Compaq) and MIPS (Tandem/Compaq). What made them pick this for servers?

    Would one be right in guessing that their Itanium based Integrity servers have been a disaster?

    1. Re:How many platforms do they need? by DarwinSurvivor · · Score: 1

      Sounds like a good choice for file servers.

    2. Re:How many platforms do they need? by Anonymous Coward · · Score: 0

      "Green power" and "ARM" are the buzzwords nowadays. I bet it doesnt take much to convince the business people to buy into this.

    3. Re:How many platforms do they need? by Anonymous Coward · · Score: 0

      Maybe, they are a huge company that wants to serve as many customers as possible.

      But it's the classic back and forth between bending over backwards to give customers what they ask for and then realizing it's support hell 5 years later and then going over to a more converged approach with a single system that is just good, then after the old lessons are forgotten start bending over again.

    4. Re:How many platforms do they need? by jimicus · · Score: 2

      HP's balance sheet is up and down like a whore's drawers - one quarter they make a stonking loss, the next they're making solid profits. They haven't been consistent in years.

      Their core businesses are being eaten away by ever-tougher competition; the days when you could confidently recommend an HP inkjet are long gone (have you seen their software suite lately? Multi-function devices are even worse because with them you often can't install just the bare driver and have it work); I wouldn't be surprised if something similar happens to their laser printer division sooner rather than later.

      Were I to hazard a guess - and I'm not a fortune 500 CEO (if I was I wouldn't be on /.!) - I'd say they're thrashing around looking for something - anything - to carve themselves a new niche. Something they can do better than the competition, something that differentiates themselves from every other manufacturer out there. Nokia have spent some time doing the same thing.

    5. Re:How many platforms do they need? by Anonymous Coward · · Score: 0

      Yeah, I mean, competition between CPU manufacturers is a bad thing. Customers need less variety in the marketplace, because that's more efficient. HP should just use Intel only.

    6. Re:How many platforms do they need? by Anonymous Coward · · Score: 0

      (...) What made them pick this for servers? (...)

      You wouldn't expect them to pick ARM for current MS Windows PCs and workstations, now would you?

    7. Re:How many platforms do they need? by Christian+Smith · · Score: 1

      Let's count - they have Xeon/Opteron, Itanium, and among their dead platforms, they have PA-RISC, Alpha (DEC/Compaq) and MIPS (Tandem/Compaq). What made them pick this for servers?

      You can already add ARM to the mix. Their current crop of low power thin clients are ARM based:
      http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/12454-12454-321959-338927-3640405-4063703.html (Wow, nice memorable URL!)

    8. Re:How many platforms do they need? by Pieroxy · · Score: 1

      (...) What made them pick this for servers? (...)

      You wouldn't expect them to pick ARM for current MS Windows PCs and workstations, now would you?

      No, but for Android/ChromeOS/iOS/WebOS ? And Apple has been known for their ability to change platforms, so an ARM version of OSX is far from being impossible.

    9. Re:How many platforms do they need? by fuzzyfuzzyfungus · · Score: 1

      Let's count - they have Xeon/Opteron, Itanium, and among their dead platforms, they have PA-RISC, Alpha (DEC/Compaq) and MIPS (Tandem/Compaq). What made them pick this for servers?

      Would one be right in guessing that their Itanium based Integrity servers have been a disaster?

      It is entirely possible that their Itanium units haven't been doing so hot(though, from what I've read, it's more of a 'small number of cost-insensitive customers' which is why neither HP nor intel can just shoot the program in the head; but why they can't seem to get it to expand and gain any economies of scale).

      However, the fate of Itanium and the fate of this curious box should be almost 100% unconnected with one another: The two are about as different in design and intended workload as two servers could be.

    10. Re:How many platforms do they need? by fuzzyfuzzyfungus · · Score: 1

      Why would you need a URL, just call you rep for a quote! We understand the internet!

    11. Re:How many platforms do they need? by flosofl · · Score: 1

      I'd even be willing to entertain the notion that they have a concurrent build of Lion that's able to run on ARM. That's what they did for the Intel version OS X version long before they released the hardware. It may never see the light, but I can't believe they aren't exploring it as an option.

      --
      "This calls for a very special blend of psychology and extreme violence" - Vyvyan "The Young Ones"
  6. Seriously though by Chrisq · · Score: 1

    What I wonder is what the differences are between the PA-RISC design from HP and the various ARM chips. They are both RISC types and I am sort of surprised that HP does not go with its own CPU architecture. What is the "magic sause" in ARM?

    HP stopped selling PA-RISC in 2008 and will end support at the end of 2013.

    1. Re:Seriously though by mikael · · Score: 1

      Low power consumption through instruction sets and hardware architecture. If you can get multi-core systems to fit into a tablet PC, then it's easy enough to rack mount them into a server chassis.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
  7. Re:Obligatory by dbIII · · Score: 0

    Then make a Minecraft one about Redstone.

  8. 32 bit servers in 2011? by Viol8 · · Score: 4, Insightful

    With the world moving to 64 bits to accomodate huge databases in memory and on disk they must be aiming for low hanging fruit here. Still, I'd like to get hold of one IF they ever convert it into a desktop version - would be nice to have a linux installation at home that doesn't pay homage to wintel in any way.

    1. Re:32 bit servers in 2011? by unixisc · · Score: 1

      Not just that, what does ARM have that the other processors of HP don't? Even if one doesn't count PA RISC and Alpha, which are dead, HP could still use MIPS processors in their platforms. And how would Xeons be any worse?

    2. Re:32 bit servers in 2011? by janoc · · Score: 1

      Easy - ARM doesn't yet have 64bit cores available, they were only recently announced. It will take a while until the manufacturers license them, integrate them into their products and only then can HP buy them and build a server around them.

      From the looks of it, this prototype machine is unlikely to be built for databases (4GB of RAM per chip is not a lot for something like Oracle), so the 32bit limit is not really an issue. On the other hand, this screams HPC cluster/supercomputing or some other well parallelizable load, such as web servers. 32bit CPU is plenty enough for that. 64bit on a server buys you only more RAM, not much else.

      It would be *very* interesting to see performance comparison between this solution and the traditional Intel one. If it is only 50% as fast, it should give Intel a lot to worry about - the higher installation density, the power savings will easily outweigh the raw power advantage Intel may have.

    3. Re:32 bit servers in 2011? by Imbrondir · · Score: 3, Insightful

      In 2010 ARM announced 40 bit virtual memory extension for 32bit ARMv7. That's 1 Terabyte of RAM. Which should be enough for everybody :)

      On the other hand ARM a couple of days ago announced 64 bit ARMv8. But you can probably can't buy one of those for 6-12 months or so. Perhaps HP is simply using ARM chips available now more as a pilot for when the knight in full shining 64 bit address space comes along

    4. Re:32 bit servers in 2011? by Imbrondir · · Score: 1

      By guess is popularity (compared to MIPS), and power consumption (compared to Xeons)

    5. Re:32 bit servers in 2011? by unixisc · · Score: 1

      All very good - but what about the software? What software are they going to offer on ARM that's not already on Xeon (which itself is both 32-bit & 64-bit flavors)? And what performance advantage will ARM bring? If it's power consumption, how compelling is the argument to switch to a completely new platform w/ little supported software (no, Android apps don't count) and no performance advantages just to lower the electric bills? HP might as well have worked w/ either Intel or AMD to get lower powered Xeons or Opterons to market.

    6. Re:32 bit servers in 2011? by drinkypoo · · Score: 1

      It has yet to be demonstrated that MIPS will scale as well as ARM.

      PA-RISC and Alpha should not even be mentioned, since they are dead, though everything relevant about the Alpha lives on at AMD.

      Xeons are horribly power-inefficient and always have been.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    7. Re:32 bit servers in 2011? by raddan · · Score: 1

      There are plenty of applications that don't need to be able to address 64 bits worth of memory. Think webapps. Lots of cores with fast I/O are what you want. Core speed itself is less important since you're usually I/O bound.

    8. Re:32 bit servers in 2011? by Anonymous Coward · · Score: 1

      TheRegister had the best analysis of what the Sales pitch for one of these is:

      "The sales pitch for the Redstone systems [the HP hyperscale offering with the EnergyCore ARM boards], says Santeler, is that a half rack of Redstone machines and their external switches implementing 1,600 server nodes has 41 cables, burns 9.9 kilowatts, and costs $1.2m.

      A more traditional x86-based cluster doing the same amount of work would only require 400 two-socket Xeon servers, but it would take up 10 racks of space, have 1,600 cables, burn 91 kilowatts, and cost $3.3m. The big, big caveat is, of course, that you need a workload that can scale well on a modestly clocked (1.1GHz or 1.4GHz), four-core server chip that only thinks in 32-bits and only has 4GB of memory."

      That makes economic sense.

      As to Software - what is the problem? I run Ubuntu on an allways-on ARM box at home. Pretty much anything written for Linux can be compiled for ARM instead of x86.

    9. Re:32 bit servers in 2011? by chuckymonkey · · Score: 1

      Do you remember SGI? Their lineup was all MIPS prior to the ORIGIN 4000 and Altix lines. Those were capable of scaling up to thousands of processors.

      --
      "Some books contain the machinery required to create and sustain universes."-Tycho
    10. Re:32 bit servers in 2011? by Pieroxy · · Score: 1

      Linux provides good software for servers. Ubuntu even has released Ubuntu-server for ARM.

      As far as performance per Watt, that's the key point and it is missing from the article. A pity.

      That said, what makes an architecture successful? I think it's the amount of R&D that everyone puts in it. x86 has seen obscene amounts of R&D (as compared with other platforms). ARM is getting a fair share with all the smartphones and tablets nowadays. So in my view, it is much much much better to bet on ARM for the future rather than unearth a dead platform.

    11. Re:32 bit servers in 2011? by drinkypoo · · Score: 1

      I'm not talking about fetishistically throwing more cores at the problem, I'm talking about minimizing the number of cores in a multi core system. I'm talking not about the number of processors, but about the speed of individual processors. What's the fastest MIPS core you've ever seen? Was it a particularly good core? Yeah, OK, that's what I thought.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    12. Re:32 bit servers in 2011? by necro81 · · Score: 2

      Multi-source supply - ARM processors are produced by lots of companies. And although Calxeda is the only source of these new server-intended ARM processors, they are only the first.

    13. Re:32 bit servers in 2011? by Anonymous Coward · · Score: 0

      BCM1480 -- a quad core 1.2GHz MIPS64 CPU with HyperTransport and a shitload of I/O. You were saying?

    14. Re:32 bit servers in 2011? by unixisc · · Score: 1

      Not even SGI, remember Tandem's Himalaya NonStop servers - the S series used up to the R14000 processor? Those were MIPS based as well, and scaled pretty well, and that is a platform HP still owns. The fastest MIPS was the R10000 and above, and they were pretty competitive - when the R10000 surfaced, it was about the same as the PA 8000, but slower than Alphas. HP already has several server models that it could use, even w/o considering PA RISC and Alpha.

    15. Re:32 bit servers in 2011? by Afell001 · · Score: 1

      If....if...if...you have access to the source code, have software vendors working (or willing to work) on a recompile, or an in-house development team who is familiar with ARM architecture, to include best practices to get the highest performance. This is the Achilles' heel, really. You toss a stone and you will hit a halfway-competent developer who understands X86...not so easy with any of the RISC architectures, and to find efficient coders working with ARM processors, you are going to have to go shopping in the mobile development market. Most businesses are conservative anyway, and won't take the extra effort or spend the extra money to switch operating platforms, especially if the ARM architecture only offers lukewarm benefits compared to staying with tried-and-true X86.

    16. Re:32 bit servers in 2011? by Alioth · · Score: 2

      Not all servers acommodate huge databases. There are plenty of servers that have to service high numbers of users for tasks which are not computationally or memory intensive. 32 bit is likely to be better for these kinds of tasks.

    17. Re:32 bit servers in 2011? by Bengie · · Score: 2

      40bit addressing on a 32bit CPU takes a hefty performance penalty when switching 4GB "views" as the CPU can still only see 4GB at a time. Since the CPU can't see the memory as one flat memory range, it has to waste time copying certain things between these "views". It also increases the complexity of the code since any single app trying to use more than 4GB will have to manually manage these "views". So a pointer to a memory location may be valid in one view, but not another. Fun times.

    18. Re:32 bit servers in 2011? by Imbrondir · · Score: 1

      Thanks. I actually hoped some somebody would elaborate on the downside of the 'hacky' 40 bit solution. I knew there'd be some.

      Though outside of big databases, the hacky solution still sounds useful. For example on application servers, or cheap LAMP hosting, a massive amount of cool low power cores might perform better

    19. Re:32 bit servers in 2011? by Archangel+Michael · · Score: 1

      That's 1 Terabyte of RAM. Which should be enough for everybody

      I think I've heard that before. It wasn't true then, it isn't true now. I ALREADY have systems with 265 GB Ram in them, and looking to get even more.

      --
      Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
    20. Re:32 bit servers in 2011? by Surt · · Score: 1

      Cheapness in bulk.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    21. Re:32 bit servers in 2011? by Imbrondir · · Score: 1

      It was meant as a joke. Though I hope you'll share what you use more than 256 GB of RAM for.

    22. Re:32 bit servers in 2011? by bill_mcgonigle · · Score: 1

      I think I've heard that before. It wasn't true then, it isn't true now.

      You left off the emoticon in his quote before you deadpan refuted his sarcasm.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    23. Re:32 bit servers in 2011? by janoc · · Score: 1

      FYI - ARM is well supported by Linux since ages ago, not only by Android. These CPUs have been around for a very long time, probably longer than Intel's Xeon. So while you probably won't run your Exchange or IIS on such machine in the near future, it will do just fine for everything else. There are plenty of uses for non-Windows servers ...

    24. Re:32 bit servers in 2011? by janoc · · Score: 1
      That's a red herring. For majority of Linux applications you *do have* source code, thanks to the OSS licensing. And you won't even have to recompile, there are distros targeting ARM already. The only exception are proprietary applications like Oracle, SAP or Exchange, but this machine isn't designed for such workloads (Oracle needs more memory, SAP and Exchange are Windows-only).

      Regarding development - development for Linux on ARM is exactly the same as development for Linux on x86 and very similar to any other Unix. Most people do not write in assembler anymore and the platform differences from the point of view of a business application writer are negligible at best.

    25. Re:32 bit servers in 2011? by falzer · · Score: 1

      265? That's an odd number.

    26. Re:32 bit servers in 2011? by Bengie · · Score: 1

      That was based on my general understanding. I would not "quote" what I said.. :p

      And yes, it definitively "works", especially with apps that don't need more than your 32bit range. The OS can transparently handle a sum of more than 4GB of app allocated memory. So any single app may not use more than your standard 4GB, but all of the apps together could. It wouldn't be as fast as a native 64bit CPU, but it would be close enough.

      If a single app needed more than 4GB, it would have to make use of special calls to properly let the OS know what it's trying to do.

      A 64bit flat memory model is still best for large memory.

    27. Re:32 bit servers in 2011? by Dadoo · · Score: 1

      It was meant as a joke. Though I hope you'll share what you use more than 256 GB of RAM for.

      I don't know what he uses it for, but we have a (HP) server with 384GB, and we use it to run a terminal-based application for about 250 users. The application does a lot of disk access, and having that much cache has really made a difference. Jobs that used to take 12 to 16 hours can now be done in about 1.

      --
      Sit, Ubuntu, sit. Good dog.
    28. Re:32 bit servers in 2011? by mzs · · Score: 1

      Though you can then have more than 4GB of RAM in a system and each process has a 32bit VA space. This works for process that do not need to mmap gigantic things, only the OS moves the 'views' around for the processes and you can run more io bound processes without paging.

    29. Re:32 bit servers in 2011? by White+Flame · · Score: 1

      Each thread/process deals with a 32-bit slice of a larger processing domain. Even when working with huge databases, there's no reason that each processing node of it can't work well within 1GB of RAM. (It seems there are 4 cores per 4GB of RAM).

      In the "many low-power CPU" strategy, saddling each CPU to work with 64-bit by default could be a real waste of memory bandwidth compared to the actual slice of the workload that it will get. But I expect this line to get full 64-bit just for ease & transparency in not too long. The full 64-bit ARM stuff has been announced already, but is still a few years out.

    30. Re:32 bit servers in 2011? by hjf · · Score: 1

      265 is odd, but 265GB is not: 284,541,583,360 bytes

    31. Re:32 bit servers in 2011? by RocketRabbit · · Score: 1

      The low hanging fruit is probably 95% of the server market. Most servers sit around all day doling out a few files and maybe handling email. This could all have been done on a PDP-11 with plenty of juice left over.

      Whatever fantasy land you are living in sounds very hot and noisy. Take a look at how many machines in a typical corporate datacenter are running under any significant load sometime - it's usually only a few, if any.

    32. Re:32 bit servers in 2011? by RocketRabbit · · Score: 1

      Of course, calling multi-core computing a fetish is ridiculous and ignores the fact that, barring some amazing new physics, processors can only get so fast. Scalability is not about having one 10 GHz CPU that costs $100,000,000 but having 12 3 GHz CPUs for a thousand bucks.

      And outside the datacenter, the idea of screaming CPUs just seems retarded in this day and age when even a 10 year old processor can handle a typical workload from today's typical user without even straining.

    33. Re:32 bit servers in 2011? by RocketRabbit · · Score: 1

      Remember the early days of Linux? Silly people trying to run a wanna-be Unix on their little piddly home computers using the ridiculous Intel architecture. What a bunch of tards. Those little pissant boxes didn't even have SCSI*, and certainly didn't sport the massive RAM expansion that a real computer like a VAX could boast.

      Of course, the naysayers from back then are all retired now, and those piddly X86 machines run practically all the servers on the planet, and that OS has turned into a multi-billion dollar operation.

      The other point I'd make is that in this day, developers emphatically do NOT sit there hand optimizing all their code. This is the job of the compiler suite and it has been since probably the late 80s.

      If you have an in-house developer team making an in-house product which they control the source of, they can probably have it running on your new ARM box in a few hours.

      With the amount of data processing that truly huge operations do, and figuring that an Intel solution costs you at least 10x as much just for the electricity bill, trust me - vendors and in-house developers both will be either learning all they can about ARM or looking for a job in a different field. Intel is in serious trouble and this is the first real crack in the wall that shows through to the other side.

      * - recalling a debate I had in 1995 with a senior IT guy at an unnamed corporation, explaining why Linux and X86 would never win. He always gravitated back to the SCSI in his arguments.

    34. Re:32 bit servers in 2011? by sudonim2 · · Score: 1

      My dad bought a 386 with 8MB of RAM in 1986. People told him he'd never need that much memory. (Fun fact, the RAM was actually soldered to the board!)

  9. So hang on... by CrazyBusError · · Score: 1

    Are we going back to transputers again, then?

    --
    -Never argue with an idiot. They drag you down to their level, then beat you with experience-
    1. Re:So hang on... by JasterBobaMereel · · Score: 1

      Yes, but back is not the right word, since the idea (cheap, not very powerful, but many processors) never went away...

      Multicore is the same idea but on one chip

      Many of the worlds fastest computers are based on this ... e.g. BlueGene/L 106,496 x PowerPC 440 700 MHz ...

      The issues are getting the processors/cores to take the load evenly, and writing the software with parallel running in mind, Many systems up until recently were bad at this ...

      --
      Puteulanus fenestra mortis
    2. Re:So hang on... by drinkypoo · · Score: 1

      We would have to have used them to go back to them, but hardly anyone ever did, since the cost of the hardware AND the cost of the development were both staggering.

      Transputers lost out to software solutions.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  10. Alike most DSLAMs by La+Gris · · Score: 4, Informative

    This type of setup is already used in Most DSLAMs. Full rack, 2PSU, cooliing, 24 or 48 port (x)DSL cards with ARM CPU as independent servers, Internal management card and network switch. Think of blade server racks.

    --
    Léa Gris
  11. Just some back-of-the-envelope numbers... by bertok · · Score: 5, Insightful

    Those processors run at only about 1.1 GHz, and ARM isn't quite as snappy on a "per GHz" basis as a typical Intel core because of the power-vs-speed tradeoff, so I figure that a 1.1 GHz ARM quad-core chip has about the same computer power as a single ~3GHz latest generation Intel Xeon core.

    They say the can pack 288 quad core ARM processors into 4 rack units (with no disks). For comparison, HP sells blade systems that let you pack in 16 dual-socket blades into 10 rack units. Populate each socket with a 10 core Intel Xeon, and we're talking 320 cores. So for comparison, that's the equivalent of 72 cores per rack unit with ARM, vs 32 with Intel. The memory density is the other way around, with 288 GB per rack unit for ARM, and 614 GB with Intel.

    So, if you have a an embarrassingly parallel problem to solve that can fit into 4GB of memory per node, doesn't use much I/O, and can run on Linux, this might be a pretty good idea.

    1. Re:Just some back-of-the-envelope numbers... by JasterBobaMereel · · Score: 1

      BlueGene/L Each node is a Dual Core processor with 4MiB of memory (M not G) and they seem to do OK... it's a case of writing the software correctly to distribute it correctly ... That's a single system running one application

      But this is about servers not cores ... this gives you 288 servers per rack, Your blade solution gives you many less independent servers, with each server having many more cores, and more memory, which is not the market they are aiming at ...

      --
      Puteulanus fenestra mortis
    2. Re:Just some back-of-the-envelope numbers... by gl4ss · · Score: 1

      quad core arm has still nothing on 3ghz intel, not even in things that highly parallelize, with floating point things go even worse(per the semi-recent tegra benches, ).
      it's kinda sad, really. there's a lot of nifty stuff that could be done realtime if per cpu-core(per thread) power went up. anyhow
      http://www.xbitlabs.com/news/mobile/display/20110921142759_Nvidia_Unwraps_Performance_Benchmarks_of_Tegra_3_Kal_El.html

      smack a lot of shitty cpu's in a small case and call it a day has been done before "supercomputer under your desk" style, there's some applications for them.

      a better comparision for this case would be if someone stuck 72 cheapo dc-atoms in a box, for more meaningful x86 vs. arm.
      and on the power use front I'd rather see some figures about how much power rendering some test raytrace takes on each system.

      --
      world was created 5 seconds before this post as it is.
    3. Re:Just some back-of-the-envelope numbers... by bertok · · Score: 1

      I was thinking renderfarm myself, but a) that's 90% about the floating point performance, not integer, and ARM isn't stellar on floating point throughput, and b) a lot of scenes these days are greater than 4GB. While it may be possible to "tile" some scenes, the most compute expensive bit (that you'd want to accelerate the most) is global illumination, which basically needs the whole scene in RAM.

      Being forced to stay under some arbitrary scene complexity limit would suck, especially with tools like ZBrush that can generate billion-polygon models.

    4. Re:Just some back-of-the-envelope numbers... by Anonymous Coward · · Score: 1

      TFA says they run at 1.4Ghz

    5. Re:Just some back-of-the-envelope numbers... by gbjbaanb · · Score: 1

      but it's not for a single server that runs a renderfarm, that's not the target market. (for that you'd want dedicated graphics type chips anyway)

      These are to support cloud and web type servers. Note that the intent here is not to provide a single massively virtualized server that you cram hundreds of paying customers onto, but to create a single server that runs 4000 individual OSs. At 1.25W per OS that makes a huge cost saving for most datacentres that are filled with web servers that pretty much don't need CPU power anyway.

      Compare to the intel version - at 100W for that 3ghz chip (plus all the other chips that are already integrated into the ARM SoC), you'd have to run 100 VMs to get the same power consumption levels, at potentially drastically reduced performance per user.

      I guess you could stick a clustered OS on them all and then run it as a single OS that does parallel tasks well but single-core tasks poorly, but again - that's not the target market for these things.

    6. Re:Just some back-of-the-envelope numbers... by Archangel+Michael · · Score: 1

      The limitation on "servers" per rack is not processors, and hasn't been in a while, it is RAM, at least where I work. We need higher density RAM capability.

      --
      Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
    7. Re:Just some back-of-the-envelope numbers... by Anonymous Coward · · Score: 0

      No, it is G NOT M:
      http://upload.wikimedia.org/wikipedia/en/2/27/BlueGeneP_schema.png

      Only having 4MB of memory would have been extremely silly. Even the original architecture had 512MB per compute card (4 nodes):
      http://upload.wikimedia.org/wikipedia/en/d/da/BlueGeneL_schema.png

    8. Re:Just some back-of-the-envelope numbers... by bill_mcgonigle · · Score: 1

      So, if you have a an embarrassingly parallel problem to solve that can fit into 4GB of memory per node, doesn't use much I/O, and can run on Linux, this might be a pretty good idea.

      I'd imagine people who do 'cloudy' things like remote voice recognition for cell phones are jumping up and down and not renewing all their rackspace commitments.

      Now, let's see if HP can actually deliver or if the 6th CEO from now fails to understand how this sells ink.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    9. Re:Just some back-of-the-envelope numbers... by DerekLyons · · Score: 1

      While comparing the performance specs is sexy and nerdish and l33t and all that - you leave off important bits, like power consumption and heat production. These matter in the real world of engineering data centers.

    10. Re:Just some back-of-the-envelope numbers... by mzs · · Score: 1

      And cabling.

    11. Re:Just some back-of-the-envelope numbers... by Anonymous Coward · · Score: 0

      I haven't worked on servers at all, but it wouldn't surprise me if many typical applications were IO-bound not CPU-bound.

    12. Re:Just some back-of-the-envelope numbers... by RocketRabbit · · Score: 1

      Another use case is that you have some massive web site like Facebook which creates and destroys a lot of little server processes which handle a few KB to a MB of data or so in each instance, then die. Today those processes are running on Intel machines and they are almost totally IO bound (network drives and all that) so it would be easy peasy to slip in a bunch of ARM processors into the same role, and save massively on the power bill.

  12. Aggregate I/O performance by Junta · · Score: 3, Informative

    FC/FCoE/iSCSI all deliver much much lower aggregate I/O performance than coordinated use of direct attached storage. Google, Hadoop, GPFS, Lustre all facilitate that sort of usage. You will in any of those remote disk architecture have an I/O bottleneck along the line.

    That said, I would presume netboot at least would be there, and from there you can do iSCSI in software certainly. FCoE tends to be a bit pickier, so they may not be able to do that in the network fabric provided.

    On the whole, I'm skeptical still yet. So far ARM has proved itself when low power is critical and performance. I'm not sure if performance per watt is going to be impressive (e.g. if it hypothetically takes 10% of the power of a competitor and gave 9% of the performance, that can work well for places like cell phones but perhaps not so much for a datacenter). ARMv8 may make things very interesting though...

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:Aggregate I/O performance by postbigbang · · Score: 3, Interesting

      You can argue, successfully, that via virtualization and multi-core relationships that the ARM power argument is goofy, as number of threads per process and virtualization favors the CISC architectures. The ARM infrastructure, however, the foundation for a couple of decent server product lines. The architecture cited is very much like getting a bunch of ARM CPUs together to do what more power hungry quad/multi-core Intel and AMD chips are doing to day. Remember: the ARM is 32-bit, and the number of threads are limited both by inherent architecture as well as the memory ceiling.

      What's scary to me is that someone wrote that it has a crossbar switch on it without understanding what that implies in terms of inter-CPU communications, cache, cache sync/coherence, etc. A well-designed system will perform almost as well with iSCSI (on a non-blocking, switched backplane) as it will with SAS so IO isn't quite the issue; the power claim vs thread density per watt expended claim has yet to be proven.

      --
      ---- Teach Peace. It's Cheaper Than War.
    2. Re:Aggregate I/O performance by Lumpy · · Score: 1

      BAH, why? build a metric buttload of ram on it and have it simply make snapshots of the ramdisks to rotating media when changes are made using a coprocessor letting the main process scream along. you get insane speeds and ram is dirt. if each processor had 64 gig of ram, each can run 4 website VM's with plenty of memory and storage and still outperform the quad bonded OC48 connections into the Server Farm.

      This is how Comcasts Video on demand system runs. Main spinning storage servers spool out to ramdisk only servers at local headends.

      --
      Do not look at laser with remaining good eye.
    3. Re:Aggregate I/O performance by AvitarX · · Score: 1

      How well does arm break the 4gb ram wall?

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    4. Re:Aggregate I/O performance by dgatwood · · Score: 1

      What an amazing coincidence. A 64-bit arm ISA was just announced last week.

      I hope they continue in the tradition and call it the "leg" instruction set.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    5. Re:Aggregate I/O performance by AvitarX · · Score: 1

      So the solution of

      BAH, why? build a metric buttload of ram on it and have it simply make snapshots of the ramdisks to rotating media when changes are made using a coprocessor letting the main process scream along.

      is not particularly effective until prototypes that will be released in 2014?

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    6. Re:Aggregate I/O performance by OneMadMuppet · · Score: 1

      Not where I work, they don't. I/O on VM's (ESX, etc) is generally woeful, and it's significantly faster to pass through a FC card and access LUN's on a DMX or VMax than to use local storage. Hadoop uses local storage for a completely different reason.

    7. Re:Aggregate I/O performance by Junta · · Score: 1

      Ignoring virtualization overhead (which is a factor), if the storage is underutilized, yes a massive amount of cache/number of spindles a FC hop away in certain scenarios can blow away one or two local spindles. The problem is when you up utilization, the equation slips the other way. If you have low utilization or insane number of disks behind an FC compared to number of hosts in the SAN, the SAN can do better. Most places I see are heavily utilized on a relatively small amount of storage relative to number of systems due to pricing, and IO to dedicated disks reigns supreme.

      I would say the 'hadoop-like' use case is the likely set of customers ready to entertain something as exotic as an ARM server anyway, so local disk very appropriate.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    8. Re:Aggregate I/O performance by Junta · · Score: 1

      Keep in mind that many systems have many *terabytes* of data per compute node on local spindles. Boot volumes/partitions and many little apps may barely be a blip on the big drives of today, but a whole lot of stuff has a lot more data than you realize, *particularly* if they have a meaningful application of a distributed filesystem..

      --
      XML is like violence. If it doesn't solve the problem, use more.
    9. Re:Aggregate I/O performance by Lumpy · · Score: 1

      Like everything else that does large ram drives.. use a ram drive assembly. They have been around for decades for high end. I had a 16 gig ram drive on a Pentium 4 in 2001, it acted like a Ultra320 SCSI drive.

      --
      Do not look at laser with remaining good eye.
  13. Has some similarity to Bluegene supercomputers by markus_baertschi · · Score: 1

    This looks to me to be similar to Bluegene supercomputers. A Bluegene essentially consists of packaged PowerPC processors with a scalable high-performance switch interface on board. The two first current generation Bluegenes were using 32bit CPUs as well.

    Markus

  14. Redstone? by drfishy · · Score: 1

    Make a Minecraft themed one and I will find a reason to need it.

  15. Well by maroberts · · Score: 1

    ARM presumably has patents on its core technologies, which are good for 15-20 years, and also its chip designs would be covered for at least 10 years, so anything compatible would have to be based on some fairly antiquated stuff.

    AFAIK, royalties to ARM are not very high in the first place - even though the company effectively gets royalties from several billion ARM chips, its profits over 3 months are only about £30 million, so it is unlikely that the per chip royalty cost is that high.

    --

    Donte Alistair Anderson Roberts - hi son!
    Karma: Chameleon

  16. Really? by Sez+Zero · · Score: 1

    So, HP, are you really going to do this or should I just wait a few weeks and wait for the cancellation announcement?

    'Cause recently you guys have been a little wishy-washy...

    1. Re:Really? by dccase · · Score: 1

      I will certainly try to get one for $99 at next year's fire sale.

  17. Hope they won't take this any further... by Anonymous Coward · · Score: 0

    ...because 288 cores ought to be enough for anyone.

  18. Honestly curious by bberens · · Score: 1

    Where would this fit in the market? My first thought is things with high number of threads but low compute complexity like web servers or something but Oracle essentially flopped in that arena with their ultrasparc or whatever it was with a bunch of threads. It's possible ARM is very fast but I'm only accustomed to seeing it in set top boxes, phones, and such. My understanding is they're great on power consumption but not so great on compute speed...

    --
    Check out my lame java blog at www.javachopshop.com
    1. Re:Honestly curious by Amouth · · Score: 1

      Oracle essentially flopped in that arena with their ultrasparc or whatever it was with a bunch of threads

      It was Sun who did it before Oracle bought them - it was the Niagara CPU line. It didn't flop, for the people who needed that and where Sun customers it was wonderful, but out side of that ecosystem it had nearly zero application. then Oracle bought Sun and well everything seems to have flopped from that.

      --
      '...if only "Jumping to a Conclusion" was an event in the Olympics.'
  19. H-who? by Anonymous Coward · · Score: 0

    what? didn't they stop selling pcs?

  20. not at 32bit that maxes out at 4gb ram by Joe_Dragon · · Score: 1

    not at 32bit that maxes out at 4gb ram where is ARM 64?

    1. Re:not at 32bit that maxes out at 4gb ram by headbulb · · Score: 1

      The ram maxes out at 4GB per process. Not per system. LPAE allows memory to be addressed up to 40bits

  21. But... by strangel · · Score: 1

    ...does it run Android?

  22. They tried this with Crusoe too by Gothmolly · · Score: 1

    We got an enclosure full of Transmeta blades, and the performance just sucked. I could see this MAYBE for a VDI solution for a lot of low-power users, but that's it.

    --
    I want to delete my account but Slashdot doesn't allow it.
  23. Applications? by FunkyELF · · Score: 1

    What kind of applications would this be used for. The only thing I can think of would be web hosting. Does KVM / Xen even work on ARM?

    There wouldn't be any serious enterprise applications that would run on ARM (right now) are there? Java?

    1. Re:Applications? by Anonymous Coward · · Score: 0

      Does KVM / Xen even work on ARM?

      These Calxeda systems are meant to do the opposite of virtualization, i.e "physicalization". Which means that if there are 20 CPUs, every CPU will run a separate instance of the OS. Contrast this with a single powerful quad core CPU running 20 virtual OSes.

  24. OT: How many platforms do they need? by ckaminski · · Score: 1

    This is an example of how badly corporate sites fuck it up (my current employer is a perfectly good example).

    The browser tells you which language is preferred - there's no need to hardcode it in a URL. And if they want to switch/override, put it in a fucking cookie.

    www.hp.com/products/PRODUCTNUM. WTF is so hard about that?

    1. Re:OT: How many platforms do they need? by hjf · · Score: 1

      my old (old!) hp cd-writer (1998) said: www.hp.com/go/storage
      why they fuck up wit the wwwXX server stuff like it's 1995 and there's no load balancing, I don't know.

  25. incorrect, sir by Anonymous Coward · · Score: 0

    sas and sata connectors are keyed. sata may be plugged into
    sas, but not the other way around.

    by the way, it's simply wrong to characterize sata as "dummed down"
    sas. they're simply different, and they have different strengths. scsi
    is not really a strength. it's 2k pages of standard! (i suppose that's
    so anything can go; it's kind of like having no standard at all. :-))