Take a look at Google job postings. They're hiring chip design people in Mtn View. Seems unlikely they'd need these microservers if they have their own design team.
Dell has inched ARM-powered servers a little closer to credibility by revealing it has developed a proof-of-concept microserver it has made available for “testing with select customers”. That customers even want to test it suggests ARM-powered servers are of interest to some Dell buyers. That one of the locations Dell will …
Mmm. Now whilst I see where you are coming from, you need to ask yourself one question.
Is X86 the future of the small server market?
Unless I want to run some ghastly Microsoft server thing, why do I care what the CPU architecture is at all?
If it runs LAMP and Samba, that's all I do care about. And if it runs it at one half the power and two thirds the price, that's what I will be using..
Dell presumably knows what its customer base are doing with its servers. If they are almost universally running Linux on em, then this is a straight one for one replacement.
Intel have to show they can do better MIPS per watt with the atom derivatives at less price.
And there is another point too. I run an atom server in a SOHO application. Its more than fast enough. Where it needs more go is in the networking and disk access areas. If some of that functionality gets integrated onto the ARM core chip - in a way that Intel cannot do - then its lower chip count and cost.
Today's server is an intelligent connection between storage and network. It should be possible to make that a one chip solution almost, bar the RAM. OK maybe one serial or USB port for a console ...
Intel is still stuck selling CPU AND peripheral chips.
"Unless I want to run some ghastly Microsoft server thing"
The Windows kernel runs just fine on Arm. A Windows Phone on Arm already outperforms Android for instance and requires less memory - and that's the exact same kernel as the desktop and server Windows versions - just recompiled.
The only question I care about here is - at maximum density in a rack, including purchase costs and power use, which gives me more bang for my pound?
A/C (no doubt the same one that spreads other crap), there are NO ARM server OR desktop versions out there. Also RT is 32bit not 64. Before you say i's "just" recompiles, that's utter crap, you cannot take the "standard" programs and simply load them onto RT.
So apart from those 2 massive flaws, you're spot on.
Oh BTW, I'm primarily a Windows user.
(I still think this AD is Eadon)
"are NO ARM server OR desktop versions out there"
The kernel is ported as stated above. That's the hard bit done. Windows RT is effectively Windows 8 desktop for RT, but delivered in tablet form only.
"Also RT is 32bit not 64"
That's pretty much just a compilation option. And most current ARM chips are 32 bit anyway.
"Before you say i's "just" recompiles, that's utter crap, you cannot take the "standard" programs and simply load them onto RT."
Slightly more complicated than just recompiling. But that's pretty much it. Instructions here:
So apart from everything you said, bang on....
That's not even mentioning that the vast majority of Windows is present in RT8.1. I have used my Nokia 2520 to share out directories on an external USB drive. You have to use local IDs, as there is no domain connection, but other than that you start the computer browser, server and workstation services and it works a treat.
I would be seriously surprised if they don't have a full server build on ARM in rev labs.
Won't be long before Intel leans on Dell to drop it.
I can't see that this would piss Intel off very much more than the fact that all HP's baby servers (which are actually branded "Microserver") use AMD CPUs. OK, the Athlon and Turion Neo chips used by HP are still x86 chips ... but they're not Intel, any more than an ARM chip is.
Competition is generally a good thing. Intel may lean, but will Dell waver?
ARM's biggest issue for mass adoption in microservers is the whole "on-a-chip" approach across multiple licensees who all tweak and fudge the hardware, memory maps and even instruction set.
It might be fine for the likes of Google, Facebook and Amazon who can buy tens of thousands of units to run their own custom workloads but for the rest of us its a fragmented mess that requires porting of some kind for each vendors chip.
This is where intel shines, sure the instruction set is messy and the chips are power hungry but you know your architecture is solid, the operating systems are well known and stable and the tools are easy to use and stable.
Given time I can really see intel eating ARMs lunch, with the money and bodies they are throwing at atom to get the power and performance down to be competition to ARM, the standard and well known platform will become the deciding factor.
If ARM wants to survive this attack by intel it needs to reign in the licensees and require a 100% compatible architecture so if I compile code for Vendor A's server SoC, it will also run on Vendor D's competing SoC. I am not saying all SoCs have to be clones but the core feature sets have to be compatible, leave the integrated prepheral hardware support upto the OS, but I dont want to have to rebuild my workloads for every little variant.
Sigh. Back in the day there was the same issue with 8 bit micros. No compatibility. Unless you used CP/M and a bios..Then along came IBM and defined a standard hardware, and the rest is history.
If Dell do the same thing here, it will be just another example of a big company enforcing a de facto but open-ish standard on the community.
BUT the real point is this: the operating system itself is the interface these days,not the BIOS. Not the hardware.
So long as each manufacturer has a published hardware standard so that linux kernel hackers can easily port their linux to it, then the user wont see any difference. Code compiled on one ARM system will run on another, even with different hardware, in the same way it doesn't matter what graphics or Ethernet or sound card you have in a PC, the Linux examines it and selects an appropriate driver for it.
Funny you should say that. A standard is exactly what has been established recetnly. At around the same time AMD announced their "maybe available to developers in the second half of this year" Opteron A series, there was also an announcement of a standard way (broadly similar to BIOS/EFI on x86) for all the hardware on ARM to be presented to the software layer (e.g. memory maps, I/O ranges, etc.).
This post has been deleted by its author