Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Copper enables the ARM server ecosystem

dell.com

Post reply on HN
Print view View original

81–90 of 94 posts

Re: Copper enables the ARM server ecosystem

#81

Post by ChuckMcM »

I suppose this is one of the things you can do when you take DELL private, no institutional shareholders to sue you because you 'threatened their value' with a radical product idea.

As a systems guy I love the concept, but I'm a bit sad at the implementation. I would have loved to see the back plane of these things connect to a 'switch module' and take the connectors off the front. Basically a 48 port GBE switch with quad 10GbE uplinks out the "end" of the case would have been much nicer. Installing a nice SDN stack in the switch hardware such that one could virtualize the switch topology on the fly and you've got a box that you can configure in lots of ways and still get some economies of scale in both the CPU and switch infrastructure. Install a 24 port 10GbE switch on the top of the rack, and you've to 6 "copper" (18U), 24 port switch (1U), for a rack with 288 hosts, 2.3T of RAM, 288T of storage, and assuming a non-blocking 24 port switch 1. 883Mbits between any two hosts. Add a 1U boot/config management server into the rack and that is a heck of a gizmo.

Re: Copper enables the ARM server ecosystem

#82

Post by michaelt »

ams6110 wrote: post #65
lazyjones wrote: post #49

Earlier quoted context omitted.

I'd vouch for the 3rd possibility: the prices are artificially high because the customers who buy these configurations can afford to pay the premium.

This. Purchasers of the highest-end and/or costly experimental architectures tend to be research institutions or national labs that are using grant money.

Most corporations are happy to spend on the highest end hardware when it's cheaper than spending developer salary on performance.

Re: Copper enables the ARM server ecosystem

#83

Post by kbuck »

voidlogic wrote: post #33

I think x86/amd64 virtualization has made ARM a much less compelling option for servers than what it would have been a few years ago. I'm looking forward to benchmarks of new ARM server CPU (esp. AMDs), but in the past comparing scale out ARM boxes and tradtional servers in the same space has: 1. Been much more more in favor x86/amd64 under low load (much lower latency for users) 2. Been pretty similar under very hig…

To be fair, comparing core counts directly, each of those ARM processors is quadcore - so there are actually 192 physical cores in that 3U rack, not 48.

That said, I'm not convinced ARM is ready for server applications either. This might be interesting to hosting companies that want to sell low-end dedicated servers, though. (OVH already does something similar with Kimsufi, I believe?)

Re: Copper enables the ARM server ecosystem

#84

Post by jlawer »

wtracy wrote: post #39
lazyjones wrote: post #38

Earlier quoted context omitted.

> In reality I could fill a rack with these arm blades or have two quad socket x86/amd64 servers be equivalent or better Quad socket x86 is still prohibitively expensive, but in the price per performance assessment you might be right (at least if you do not consider the expensive high-end x86 CPUs). The ARM blades look interesting for bare metal clouds though.

> Quad socket x86 is still prohibitively expensive Is there an engineering reason for this, or is there just not enough volume for those boards to be economical?

I've been told its intel (Admittedly by my Dell Engineer).

The CPUs & Chipsets to run quad socket are marked up much higher then the dual / single socket options.

Re: Copper enables the ARM server ecosystem

#85

Post by rbanffy »

ansible wrote: post #14
rbanffy wrote: post #2

I couldn't find anything on pricing and availability, but, despite my enthusiasm for Windows-proof servers, I am not sure if having a lot of discrete servers in a 3U enclosure is better than having a lot of containers running on, say, 3 1U servers. Containers (or even VMs) are much more manageable than 48 physically distinct machines (to say nothing of having 4 on each board, meaning an upgrade or defect on one means…

If we could turn it into a NUMA machine with 48 CPUs, that would be a totally different story. This particular version seems to only support 1Gbit Ethernet, so I don't know how well that will work. Still, we're talking about 192 cores with 384 Gbytes of RAM, that's got to be useful for some kind of workloads. Can you get that kind of density with Intel or AMD?

> Can you get that kind of density with Intel or AMD?

The new Xeon Phi's will have an external DDR3 bus. It's a different beast, intended for a different usage, but I always loved to misuse technology ;-)

Re: Copper enables the ARM server ecosystem

#86

Post by rbanffy »

ris wrote: post #36
ansible wrote: post #14

Earlier quoted context omitted.

If we could turn it into a NUMA machine with 48 CPUs, that would be a totally different story. This particular version seems to only support 1Gbit Ethernet, so I don't know how well that will work. Still, we're talking about 192 cores with 384 Gbytes of RAM, that's got to be useful for some kind of workloads. Can you get that kind of density with Intel or AMD?

> Still, we're talking about 192 cores with 384 Gbytes of RAM Seeing as you're going to be keeping 48 copies of the same OS in that memory whether you want to or not, you're going to need those 384G.

These machines are designed for very specific workloads. Don't expect to be able to run Oracle or Exchange on them.

Re: Copper enables the ARM server ecosystem

#87

Post by voidlogic »

Sssnake wrote: post #61
voidlogic wrote: post #33

I think x86/amd64 virtualization has made ARM a much less compelling option for servers than what it would have been a few years ago. I'm looking forward to benchmarks of new ARM server CPU (esp. AMDs), but in the past comparing scale out ARM boxes and tradtional servers in the same space has: 1. Been much more more in favor x86/amd64 under low load (much lower latency for users) 2. Been pretty similar under very hig…

>that is 32 logical cores at 3.0 GHz Just having 32 logical cores doesn't mean much for performance. Hyperthreading is not magical, dual quad core cpus is still 8 cores, with potentially some minor performance gains from the hyperthreading depending on the application.

In high-load but I/O bound tasks Hyperthreading (Intel market speak for SMT) is magic. If something is compute bound, you are correct and the benefit is often slim, but typically not for application or database servers.

Re: Copper enables the ARM server ecosystem

#88

Post by mjg59 »

notacoward wrote: post #76
mjg59 wrote: post #62

Earlier quoted context omitted.

Those figures are pretty close to being lies. A quad-core 3.3GHz Xeon that's only serving 6950 requests per second isn't going to be at anywhere near 100% utilisation, which means there's no way it's running at anywhere near its TDP. Same for the RAM. The x86 isn't going to be anywhere near 5W, but it's going to be significantly lower than 102W. They're also ignoring the fixed disk and PSU overheads, shifting the pow…

While what you say is true, it's also true that a lot of x86 servers sit idle precisely because they're network-limited. Wasting power that way is no different than wasting power any other way. That effect far outweighs any quibbling about whether the x86 really uses its full TDP (it won't) or needs more support chips that more than make up for it (it will), or what kinds of memory are involved, etc. Just so happens…

Well sure, but you could replace those servers with a low-power x86 and get most of the same benefit that Calxeda are touting. Massively overprovisioning is going to waste power. An 8051 is probably going to give a better power/performance ratio than a quad-core ARM for an embedded controller, which tells me nothing about which I should choose to run my database.

Re: Copper enables the ARM server ecosystem

#89

Post by polshaw »

tluyben2 wrote: post #23
polshaw wrote: post #21

Earlier quoted context omitted.

FYI (re: consumer Atom) Intel have just started taking Atom seriously again, after majorly neglecting it for the previous 5 years. The current Silvermont/Bay Trail is twice as fast as the last, bringing C2D+ performance (eg 2010 MBA) with tablet thermals and battery life. It will now be on Intel's primary process too, so the days of Atom universally sucking are over (thanks ARM).

Offtopic; Can you point me to a laptop with that? I use a 2010 MBA all the time and if I could get something for the price of an atom with that performance...

See UMPCportal. My favourite is the Asus T100, but it suffers from the problem with most of the current crop of Bay Trail-T devices; 2GB of soldered RAM. 64GB model will be around for $300 around black friday. The HP Pavillion x2 should have 4GB, but is much pricier.

IMO the Acer C720 chromebook is the best deal around currently; just put linux on it and replace the 16GB SSD with a larger one, performance should be even better than the 2010 MBA AFAICT.

Things are definitely starting to get very interesting though, I'll be keeping a close eye on devices released in the next 6mo.

Re: Copper enables the ARM server ecosystem

#90

Post by notacoward »

mjg59 wrote: post #88
notacoward wrote: post #76

Earlier quoted context omitted.

While what you say is true, it's also true that a lot of x86 servers sit idle precisely because they're network-limited. Wasting power that way is no different than wasting power any other way. That effect far outweighs any quibbling about whether the x86 really uses its full TDP (it won't) or needs more support chips that more than make up for it (it will), or what kinds of memory are involved, etc. Just so happens…

Well sure, but you could replace those servers with a low-power x86 and get most of the same benefit that Calxeda are touting. Massively overprovisioning is going to waste power. An 8051 is probably going to give a better power/performance ratio than a quad-core ARM for an embedded controller, which tells me nothing about which I should choose to run my database.

Where is that low-power x86 and its fleet of low-power support chips to do what something like an Armada or EnergyCore can do on its own? They have yet to come up with one.

As for your 8051 example, it's bogus because that chip simply can't do the work. It can't run a real OS, and even if it could do that it couldn't keep even a single Ethernet or SATA port busy. Therefore you'd need a lot more nodes, each with their own network/storage/memory that don't come for free, rapidly wiping out any savings on the CPU alone before you even get to the high-node-count coordination problems that would make the whole thing fall flat on its face.

The whole issue here is not just absolute minimum power but balance. In a server environment, where the processor's job is about keeping ports full more than about pure number-crunching, you have to start with what kinds of ports you have. What processor and memory most exactly matches a commodity I/O profile, neither running over nor falling short, while consuming the fewest watts? Modern ARM chips are often a better answer to that question than anything Intel makes. It's a shame that some people who've invested many years in x86-specific expertise might find the market for those skills eroding as a result, but that's the harsh reality.

Post reply on HN