Richard Cownie (tich.delete@this.pobox.com) on January 30, 2013 2:39 pm wrote:
> rwessel (robertwessel.delete@this.yahoo.com) on January 29, 2013 10:15 pm wrote:
> > Right, but unless you think that the microserver vendors are likely to be going head to
> > head with Intel 2S and larger systems, the relevant datum is the $252 ASP for Xeon UPs.
>
> It's not exactly "head-to-head" in the sense that 1 ARM-based server node would
> exactly match the capability of 1 2S-Xeon node. The interesting use case is where
> you have hundreds or thousands of servers. With Intel's current products, you have
> a bunch of "system cost" like chipset, power supply, board, and it might well
> turn out that the cheapest way to pack compute power into X square feet of datacenter
> is to have 2 cpu sockets in each system (even if those cpu's are relatively expensive,
> you get better amortization of the board/PSU/network costs). Isn't that what Google's
> systems look like ?
>
> It's quite possible that the competing ARM-based solution would look very different,
> with different numbers of cores, different numbers of sockets, different numbers of
> nodes, possibly much less per-board cost.
>
> Obviously this only works if you have a cheap scalable way of running many systems
> with few sysadmins. But that's just what cloud software does. So the constraints
> are very different than they were 5 years ago, or even 3 years ago.


I meant head-to-head only in the sense that if you had a flock of ARM chickens a big Xeon UP ox sliced into virtual chickens is an obvious alternative. A Xeon MP largely is *not*. Technically, sure it would work, but it costs more, and you're ignoring the one thing (the big coherent memory) that makes the Xeon MP more attractive (for some workloads) than a cluster of Xeon UPs. So the ASP comparison shouldn't include the multi-socket Xeons.

There are several levels of things needing to be managed in these scenarios. The hardware, the base OSs, the virtualization, the OS in each virtual slice, any sharing within that image, and of course the application(s) running there.

Obviously a couple of those layers drop out if you're running on real hardware (without virtualization), but I don't think that's really the use case for most of these. If nothing else, virtualization significantly eases hardware management – you lose a lot of hardware dependencies, so images can migrate easily between different boxes with slightly different hardware, and images can be trivially migrated box-to-box, as load and maintenance issue dictate. In some cases it can even be done live.

But there's considerable automation now for all of those layers, but bigger physical boxes, especially if they don't cost more than the flock of smaller boxes, adds significant flexibility to workload planning and management. Obviously some of that is less mature on ARM at this point, especially virtualization, but that's certainly going to be fixed in the next few years.

But it really does come down to the costs for each platform, at least for those workloads that don't mind running on smaller images, there's not that much preventing a migration between the ISAs in many cases. I think that was the main point of David’s article – there’s not really all that much room under the basic Xeon-UP pizza box to make a flock of ARMs cost effective.