Live data from Hacker News

HP's new ARM-based Servers

h17007.www1.hp.com

61–70 of 76 posts

Re: HP's new ARM-based Servers

#62
post #27

From http://www.theregister.co.uk/2011/11/01/hp_redstone_calxeda_... : The sales pitch for the Redstone systems, 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…

Even if you triple the number of Redstone machines, you'll still use just ~30% of the energy and 7.5% of the cabling.

And each 4 ARM cores have their own memory channels and I/O ports, vs every 6-12 on the Xeon [corrected] (point being that CPU speed is not the only variable here).

Re: HP's new ARM-based Servers

#63
post #27

From http://www.theregister.co.uk/2011/11/01/hp_redstone_calxeda_... : The sales pitch for the Redstone systems, 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…

Even if you triple the number of Redstone machines, you'll still use just ~30% of the energy and 7.5% of the cabling. And each 4 ARM cores have their own memory channels and I/O ports, vs every 6-12 on the Xeon [corrected] (point being that CPU speed is not the only variable here).

The Calxeda chip is quad-core, so there's still sharing.

Re: HP's new ARM-based Servers

#64
post #63

Earlier quoted context omitted.

Even if you triple the number of Redstone machines, you'll still use just ~30% of the energy and 7.5% of the cabling. And each 4 ARM cores have their own memory channels and I/O ports, vs every 6-12 on the Xeon [corrected] (point being that CPU speed is not the only variable here).

The Calxeda chip is quad-core, so there's still sharing.

My bad. The tray picture shows 36 boards, I didn't pay much attention and thought those were 72 single-core nodes.

Re: HP's new ARM-based Servers

#65
post #42
post #41

Earlier quoted context omitted.

It depends entirely on where your bottlenecks are. If the bottleneck is entirely within your node, then this isn't going to be compelling. If you're doing something that's very light on the resources within your node (serving static content, etc) and your bottleneck is some other system somewhere else, then these sorts of machines could be compelling purely from a space/power POV.

If your nodes are not bound on some local resource, you can as well just run them in virtualization containers on Xeon. The setup will be even more flexible than with (less powerful) ARMs.

But not nearly as space/power-efficient.

Re: HP's new ARM-based Servers

#66
post #29
post #28

Earlier quoted context omitted.

You assume the application is compute limited and that the extra performance on the Xeon translates into extra performance on a given application. That's probably not a good assumption for this kind of workload.

Why, for embarrassingly parallel workloads (like the ones they mention) it's a totally reasonable assumption. And for something not so parallel the gazillion of ARM nodes is all but useless.

The article mentions Hadoop, big data crunching, web serving and web caching. They may or may not be embarrassingly parallel, but that doesn't mean any of them are typically compute bound.

Look, today's multichip, multicore servers tend to be unbalanced for a lot of workloads. Their massive compute performance often burns power waiting for main memory, disk or network.

Re: HP's new ARM-based Servers

#67
post #28

Earlier quoted context omitted.

You assume the application is compute limited and that the extra performance on the Xeon translates into extra performance on a given application. That's probably not a good assumption for this kind of workload.

You're going to be I/O bound (network or disk), memory bound, or compute bound. It's hard to imagine the Redstone systems besting Xeon based servers in any of the three.

If your workload runs on one or two Xeon servers, it probably isn't worth considering something like this. If your workload runs on racks of Xeon servers, it might be.

Then the question is, which hardware delivers the right balance of CPU, memory and IO bandwidth for the lowest capital and operating costs.

Also for what it is worth, each card has 60Gbps of general IO bandwidth, and another 48Gbps of SATA disk bandwidth.

Re: HP's new ARM-based Servers

#69
post #46
post #12

Earlier quoted context omitted.

...win over customers with 100% marketing and no technical details... Hasn't the enterprise market worked that way for years?

The fundamental flaw here I think is centralized purchasing.

No clue why that got voted down. I think you're right.

Re: HP's new ARM-based Servers

#70
post #68

HPs urls are terrible: http://h17007.www1.hp.com/us/en/iss/110111.aspx

Off-topic, but seriously no one except self-important webdevs gives a toss about URLs. They're addresses, not literature. That URL looks fine to me.

Yeah, bullshit semantic/SEO cargo cult.
Post reply on HN