ARM-Based Servers Coming In 2011

markass530 writes with this from the EE Times: "Arm Holdings chief executive officer Warren East told EE Times Wednesday that servers based on ARM multicore processors should arrive within the next twelve months. The news confirms previous speculation stemming from Google's acquisition of Agnilux and a recent job advertisement posted by Microsoft. East said that the current architecture, designed for client-side computing, can also be used in server applications."

Comments

I feel the pain...

[jackharrer]

I feel little sorry for MSFT. Just a little...

Re:I feel the pain...

[vbraga]

Really? Why? Windows supported Alpha and Itanium (MIPS too? I doesn't remember). It could just support ARM as well.

Re:I feel the pain...

[capo_dei_capi]

Windows NT used to support the DEC alpha, which is certainly a RISC architecture. But I'm pretty sure the Itanium is not a classic RISC architecture, since it's based on the explicit instruction-level parallelism paradigm.

Re:I feel the pain...

[petermgreen]

The problem is more the apps, windows itself could probably be ported without too much trouble but most windows apps are likely to have code that makes x86 specific assumptions and are closed source so only the vendors can fix them.

Emulation is an option but unless arm cores start performing a LOT better than intel cores of a similar power envelope that won't help much.

Re:I feel the pain...

[TheRaven64]

MIPS and PowerPC. It ran competitively on most of these architectures, but the problem was always the missing third party software. If Microsoft just wants ARM servers for internal use, this wouldn't be a problem. Other people could probably manage too. Server software on Windows tends to be either written by Microsoft, open source, developed in-house, or provided by a small number of other companies. The first three mean it can just be recompiled. The fourth means that MS can apply some pressure to encourage an ARM port relatively easily.

A lot of the win32 API makes stupid 32-bit-and-little-endian assumptions, so Windows hasn't been ported to any big endian systems (PowerPC and MIPS are biendian, and Windows ran them in little endian mode). The 32-bit assumptions are hacked in win64 by using an LLP64 model, which breaks the assumption that sizeof(void*) <= sizeof(long). This is not guaranteed by the spec, but since it's true for pretty much every platform in existence before Win64, a lot of people assume that it is.

ARM is 32-bit and little endian, so userland Windows software should be pretty trivial to port. The only real difference you might notice is that ARM doesn't support unaligned loads, while x86 does (it's just really slow). An ARM OS can trap the exception caused by an unaligned load and emulate it, so even code that depends on it could work, just slowly. The only time you'll notice this in C code is if you are doing a lot of pointer casting - if the compiler can tell that it's an unaligned load, it will do two aligned loads, and shift-and-mask the results together. This is not exactly fast, but it's faster than an OS trap.

Re:I feel the pain...

[squizzar]

But in this case that's a good thing. It suggests that they have designed portable code (it was one of the goals of the NT architecture) so they should be able to move to another platform.

Re:I feel the pain...

[Joce640k]

MS provides email, Outlook, SQL and web server applications. Why would you need anything more?

Re:I feel the pain...

[CastrTroy]

Because those applications probably still make a lot of assumptions for running on x86. I wouldn't even think that windows could be compiled to run on ARM in it's current state. There's probably a bunch of assembly thrown in for optimizations. Windows hasn't run on anything but x86 since Windows NT4. A lot has changed since then.

Re:I feel the pain...

[bluefoxlucid]

Microsoft would just use Windows CE as a base, and port IIS and SQL Server to it easy enough.

Re:I feel the pain...

[Anonymous Coward]

Windows NT also supports PowerPC, and the code is quite recent as they were using PPC in the original XBox with an almost-2k kernel.

Re:I feel the pain...

[StayFrosty]

The original XBox used a 700MHz celeron. The XBox 360 uses PPC.

Re:I feel the pain...

[TyFoN]

Windows server still ran on Itanium last time I checked, and that is definitively not x86. You can also argue that x86_64 is a different architecture from x86.

Re:I feel the pain...

[denis-The-menace]

FYI: MS will now drop Itanium support after Windows2008R2
http://en.wikipedia.org/wiki/Itanium#Software_support

"However, Windows Server 2008 R2 will be the last version of Windows Server to support the Itanium and Red Hat Enterprise Linux 5 will be the last version to support the Itanium.[14][15]"

IOW: this is a marketing ploy

Re:I feel the pain...

[Anonymous Coward]

But in this case that's a good thing. It suggests that they have designed portable code (it was one of the goals of the NT architecture) so they should be able to move to another platform.

And remember how well that worked out on MIPS, PPC and Alpha?

Re:I feel the pain...

[MrData]

The current windows OS stack with NT lineage can run on any processor as long as it supports Little Endian. Many processors including ARM can run in either big or little endian mode, so NT can be ported to it.

Re:I feel the pain...

[Anonymous Coward]

If I see another idiot claiming that LLP64 is a "hack" for the sake of endian compatibility, I'm going to smash something. Yes, Windows uses LLP64 most of the time. That's because too many developers used things like DWORD in their structure definitions, which would be broken if DWORD was suddenly 64 bits wide.

And anyone who has ever made the "assumption" that sizeof(void*) = sizeof(long) is an idiot. Sorry, but if you rely on undefined behavior in the standard you accept the results that come from that result. You shouldn't ever be putting pointers into longs anyway.

Re:I feel the pain...

[Anonymous Coward]

Well remember, Microsoft did have NT for the Alpha...

Re:I feel the pain...

[tixxit]

Don't discount MS yet. Windows CE runs on ARM, so clearly they have experience with it. Also, the best wireless router I ever had was running a version of CE. It was rock solid for 8 years, never crapped out or required a reboot (even while my roommate downloaded massive amounts of torrents all day). Finally retired because I wanted a router that supported 802.11n. I can't believe how often I have to restart my new POS router which cost twice as much as the MS one did 8 years ago.

Re:I feel the pain...

[ckaminski]

The MIPS/Alpha/PowerPC failure of Windows was caused by 1 thing only:

    The disgustingly cheap price of the Pentium Pro.

For $10,000 dollars you could have the same (two socket) performance as a $40,000 Netpower, or a $30,000 DEC Alpha.

Intel's volume and engineering skill is what made porting to anything except Intel a waste of time, except on some very special applications.

The fact that MIPS/Alpha/PowerPC where all 64bit CPU platforms back in 1996 should incense anyone who bought into the Itanium myth. Thank GOD we had AMD around to force Intel to move to x64.

Re:I feel the pain...

[ckaminski]

Windows 2000 ran on Alpha.

MIPS was discontinued at NT 4.0, and PowerPC was discontinued at NT 4.0 PPC RC1 or 2(ish). NT 4.0 was already around SP1 or 2 by then for every other platform.

Re:I feel the pain...

[raddan]

If the rumors I hear are true from Microsoft developers, Microsoft is fully committed to moving their applications to the .NET platform. All of that stuff is compiled to an intermediate, interpreted bytecode that runs in a VM, just like Java. So actually, it is very portable. Portable enough that one of the applications I wrote in C#.NET and compiled in Visual Studio on a 32-bit platform ran unmodified on Ubuntu 64-bit with Mono. They may still do some low-level things here and there, but I suspect that if they really need to, they can port to another processor without having to reinvent the wheel.

Re:I feel the pain...

[raddan]

Actually, just a nitpick, ARM itself is bi-endian. It can switch on demand. But machines built with ARM chips tend to settle on one byte order or the other. IIRC, the iPod is little-endian because of assumptions made by PortalPlayer's customizations.

Re:I feel the pain...

[shutdown -p now]

most windows apps are likely to have code that makes x86 specific assumptions

Not really. Or rather, it used to be the case, but that shit had (mostly) already hit the fan back when x64 appeared. Microsoft had to do a lot of things to assist in that transition (e.g. this), and matters have improved significantly since then.

Two problems that this didn't take care of are non-aligned memory access (which is permitted on x84/x64, but is very slow), and endianness. The latter shouldn't be a problem with ARM as it can be configured as needed. Non-aligned memory access is a problem, but it is very rare, and, more importantly, easily found by testing (since it will result in an immediate crash right at the faulting instruction), and is trivial to fix with MS dev tools.

All in all, I don't think there are any significant technical hurdles there. It's only a matter of making those third-party software vendors to bother with recompiling & fixing the aforementioned minor quirks. But, then again, if ARM servers will become popular, software will inevitably follow - so long as the platform is provided.

Re:I feel the pain...

[shutdown -p now]

An ARM OS can trap the exception caused by an unaligned load and emulate it, so even code that depends on it could work, just slowly. The only time you'll notice this in C code is if you are doing a lot of pointer casting - if the compiler can tell that it's an unaligned load, it will do two aligned loads, and shift-and-mask the results together. This is not exactly fast, but it's faster than an OS trap.

You can also help the compiler there.

Re:I feel the pain...

[shutdown -p now]

If I see another idiot claiming that LLP64 is a "hack" for the sake of endian compatibility, I'm going to smash something. Yes, Windows uses LLP64 most of the time. That's because too many developers used things like DWORD in their structure definitions, which would be broken if DWORD was suddenly 64 bits wide.

Presumably, if Windows went LP64 tomorrow, this wouldn't mean that DWORD is suddenly 64-bit wide. It would just mean that DWORD would become a typedef for unsigned int, rather than unsigned long.

Re:I feel the pain...

[TheRaven64]

Ouch. I really hope that the documentation is dumbed down for numpties and it doesn't really read one byte at a time. It should just round the address up and down, do two loads, then rotate, mask, and xor the two results.

Re:I feel the pain...

[Anonymous Coward]

> An ARM OS can trap the exception caused by an unaligned load and emulate it

What exception? An unaligned load simply rotates the word so that the byte at the specified address is the LSB (a word load is the same as a byte load, except that a byte load sets the top 24 bits to zero, while a word load doesn't).

If you want to do unaligned reads, you have to tell the compiler that the pointer may be unaligned via e.g. __attribute__(packed), so that it will generate the correct sequence of instructions. Otherwise, it will just perform a word read, and if the pointer isn't aligned you get garbage.

Re:I feel the pain...

[shutdown -p now]

A good point, so I did an experiment with Itanium cross-compiler (Itanium is currently the only architecture for which this modifier actually has any effect on VC++ code generation; for x64, it spits the same code with __unaligned as without it). The C++ input was:

int main(int argc, char** argv)
{
    int __unaligned* p = (int*)argc;
    return *p;
}

I've made it use arguments and return the computed value so that compiler doesn't optimize away "unused" stuff complete with the computation itself. The above code was then compiled with "cl.exe /O2 /FAs", with IA64 cross-compiler. The assembly output produced due to /FAs is as follows:

main: // COMDAT
// argc$ = r32
// __formal$ = r33
// Output regs: None
 
// 4 : return *p;
// 5 : }
 
  { .mii //R-Addr: 0X00
    and r29=3, r32 //4. cc:0
    sxt4 r31=r32;; //4. cc:0
    cmp.eq.unc p0,p6=r0, r29 //4. cc:1
  }
  { .mmi //R-Addr: 0X010
    and r30=-4, r31;; //4. cc:1
    ld4 r8=[r30], 4 //4. cc:2
  (p6) cmp.eq.unc p0,p7=1, r29 //4.I cc:2
  }
  { .mii //R-Addr: 0X020
  (p6) cmp.eq.unc p0,p8=3, r29 //4.I cc:2
  (p6) cmp.eq.unc p0,p9=2, r29;; //4.I cc:2
  (p7) shr.u r8=r8, 16 //4.I cc:3
  }
  { .mmi //R-Addr: 0X030
  (p6) ld4 r28=[r30];; //4.I cc:3
    nop.m 0
  (p8) shl r28=r28, 16 //4.I cc:4
  }
  { .mii //R-Addr: 0X040
    nop.m 0
  (p6) shr.u r27=r8, 8;; //4.RI cc:4
  (p6) addp4 r8=r28, r8 //4.RI cc:5
  }
  { .mmi //R-Addr: 0X050
  (p6) shladd r31=r28, 4, r0;; //4.RI cc:5
  (p9) shladdp4 r8=r31, 4, r27 //4.I cc:6
    nop.i 0
  }
  { .mmb //R-Addr: 0X060
    nop.m 0
    nop.m 0
    br.ret.sptk.many b0;; //5 cc:6
  }

It's the first time I've seen Itanium assembly code, and it does look very alien to say the least, but so far as I can see, this does two 32-bit loads (ld4), and a bunch of shifts to combine them together. So not byte-by-byte, but not XOR, either. It might have more to do with Itanium quirks, however.

Oh, and by the way - Slashdot is broken as usual: "Your comment has too few characters per line" - oh, really? So it's "News for nerds", but filters aren't even properly tuned to handle assembly and C++ code snippets in comments? I swear, it's almost as annoying as all the poorly coded Ajaxy crap that, apparently, actively conspires to break rendering on small-screen devices (well, at least on my Nexus One, anyway), as well as Opera... they could definitely learn a thing or two from StackOverflow there, and spare me the need to come up with more drivel here to satiate the damn filter.

Re:I feel the pain...

[TheRaven64]

Yup, EPIC asm does look a bit interesting. The braces wrap nstruction bundles, which are 128-bit groups of three instructions that are loaded and executed simultaneously, which accounts for the interesting order. It looks like a relatively sane implementation of an unaligned load, in spite of that.

Re:I feel the pain...

[rdnetto]

This is actually very dangerous for Linux's marketshare in the netbook segment. If MS starts porting Windows to ARM, then it won't be long before they have desktop and netbook editions of it ported as well, which could neutralize Linux's killer feature (on netbooks) of supporting ARM. I know the argument is that there are other x86 apps that won't run, but on a netbook I doubt most people will need much more than Windows+Office+IE.
Best counter strategy would be to try and increase the Linux+ARM netbook marketshare right now, to get a head start.
On another note, does anyone know of any ARM netbooks with 512+ MB of RAM? So far the only one I've found is this one.

Re:I feel the pain...

[Anonymous Coward]

If the killer linux feature for netbooks is running on arm (eg "smartbooks") then I think microsoft can rest easy. smartbooks haven't exactly, er ... caught on like wildfire let's say.

Re:I feel the pain...

[petermgreen]

And they ALMOST had 2K for alpha (they had it up to one of the release candidates but didn't take it through to a final release)

Re:I feel the pain...

[petermgreen]

Not really. Or rather, it used to be the case, but that shit had (mostly) already hit the fan back when x64 appeared.
Admittedly this is a desktop perspective but the impression I get is that only a small handful of windows apps are actually x64 (this contrasts sharply with linux where the norm is to run a system where almost everything is x64).

And even when an app adds x64 support they don't always make everything 64-bit. For example with hfss the simulation engine is 64-bit but the user interface/modelling tool is 32-bit.

Are things different over in server land?

Re:I feel the pain...

[petermgreen]

People have managed to get a little endian kernels running on hardware that was originally intended to run big endian (the linksys NSLU2) sbut my understanding is it was nontrivial (and it took them quite some time to get all the hardware to work with the little endian kernel)

Re:I feel the pain...

[petermgreen]

Otherwise, it will just perform a word read, and if the pointer isn't aligned you get garbage.
Some but not all arm chips can be told to generate an exception in this case.

from http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/1228.html
ARM processors with full MMUs (e.g. ARM920T) support optional alignment checking where the processor will check every access to ensure it is correctly aligned. The MMU will raise a data abort if an incorrectly aligned access occurs.

Some ARM partners using simple cores such as the ARM7TDMI have implemented alignment-checking for their ASIC/ASSP. This can be done with an additional hardware block external to the ARM core, which monitors the access size and the least significant bits of the address bus for every data access. The ASIC/ASSP can be configured to raise the ABORT signal in the case of an unaligned access. ARM recommends that such logic is included on ASIC/ASSP devices where code will be ported from other architectures.

Linux can use these exceptions to fix up access if you desire (or you can set it up to generate a bus error signal to help in debugging)

from http://www.mjmwired.net/kernel/Documentation/arm/mem_alignment
15 Now for user space applications, it is possible to configure the alignment
16 trap to SIGBUS any code performing unaligned access (good for debugging bad
17 code), or even fixup the access by software like for kernel code. The later
18 mode isn't recommended for performance reasons (just think about the
19 floating point emulation that works about the same way). Fix your code
20 instead!

Re:I feel the pain...

[shutdown -p now]

It's true, because most apps don't really use anything x64 offers... still, the 64-bit compatibility checker is on by default in newly created VC++ projects even for x86.

On server, it is somewhat different because e.g. just-released Win2008 R2 is x64-only, and so are some other server MS products (e.g. SharePoint 2010).

Re:I feel the pain...

[capo_dei_capi]

I'd say it was rather Microsoft with its ever more RAM-demanding OSs that forced intel to move to 64bit architectures. AMD just happened to come up with a solution that allowed for backwards compatibility. I guess, hadn't it been for AMD something similar to the transition from PPC to x86 in the Mac world would have happened in the windows/x86-*NIX world, but the transition would have been x86->ia64. Considering that the IA32 ISA is quite much of a hackjob, I'm not so sure that AMD came along with the x86_64 architecture was a good thing..

Re:I feel the pain...

[Hurricane78]

unless arm cores start performing a LOT better than intel cores of a similar power envelop

I was under the impression that they already do that.

Re:I feel the pain...

[Anonymous Coward]

Actually, unaligned loads _that don't cross a cache line_ are almost 100% full speed on x86.

That's actually one of the main reasons why x86 is so good at running all kinds of crappy and/or ancient 286-style code, fast.

Re:I feel the pain...

[Anonymous Coward]

http://www.theregister.co.uk/2010/04/05/microsoft_pulls_plug_itanium/

Re:I feel the pain...

[Anonymous Coward]

MIPS and PowerPC. It ran competitively on most of these architectures, but the problem was always the missing third party software. If Microsoft just wants ARM servers for internal use, this wouldn't be a problem. Other people could probably manage too. Server software on Windows tends to be either written by Microsoft, open source, developed in-house, or provided by a small number of other companies. The first three mean it can just be recompiled. The fourth means that MS can apply some pressure to encourage an ARM port relatively easily.

A lot of the win32 API makes stupid 32-bit-and-little-endian assumptions, so Windows hasn't been ported to any big endian systems (PowerPC and MIPS are biendian, and Windows ran them in little endian mode). The 32-bit assumptions are hacked in win64 by using an LLP64 model, which breaks the assumption that sizeof(void*) <= sizeof(long). This is not guaranteed by the spec, but since it's true for pretty much every platform in existence before Win64, a lot of people assume that it is.

ARM is 32-bit and little endian, so userland Windows software should be pretty trivial to port. The only real difference you might notice is that ARM doesn't support unaligned loads, while x86 does (it's just really slow). An ARM OS can trap the exception caused by an unaligned load and emulate it, so even code that depends on it could work, just slowly. The only time you'll notice this in C code is if you are doing a lot of pointer casting - if the compiler can tell that it's an unaligned load, it will do two aligned loads, and shift-and-mask the results together. This is not exactly fast, but it's faster than an OS trap.

Windows was ported to the xbox360, which runs bigendian.

Yes, all of Windows, not just the kernel. Microsoft decided not to release it, but the port did exist.

Low power server / clusters?

[MC68040]

I can see myself using an ARM-based linux server in the home.

If they get proper business support from some largeish vendor pushing out rack machines then that'd be great too. All the servers I admin currently run x86 from Intel. Saying that, when idling, they're not terribly power hungry; but arm boxes should be a lot better.

Lowering power consumption is never a bad idea for your bottom line, as long as the performance-per-watt is acceptable. The first thing I thought was that it would be useful for larger clusters of machines if the performance isn't on-par with power6/x86 server chips. At the end of the day the deal breaker will be just how much performance you can get out of their server chips, which will affect what type of environment they're suitable for.

Re:Low power server / clusters?

[ls671]

I would rather have a Linux server with feet processor instead of an arm processor:

There seem to be a nice example on the link below:

"This is usually when you try to bend straight in transit (storage, drop, the operation inserted in a socket, etc.) feet processor. "

http://avs-info.net/upgrading_processor_solder_legs.html

Re:Low power server / clusters?

[wvmarle]

And how about small businesses?

I bet those millions of servers handling an office of five people can happily do with half the horsepower and 10% of the power use.

And I'm not just thinking of my own business.... with a 1.8 MHz or so Intel based computer idling most of the time handling the e-mail and files of my staff and me.

Re:Low power server / clusters?

[Matt_R]

I would rather have a Linux server with feet processor instead of an arm processor:

I heard Tux was an extra in Happy Feet.. ;)

Re:Low power server / clusters?

[BikeHelmet]

x86 CPUs are beasts.

I'm wondering how well an ARM multi-core CPU would do just serving up files off a RAID array? x86 quad-core CPUs are probably total overkill for that - and perhaps not worth it because of the power consumption.

Yep, there's a market for ARM.

Re:Low power server / clusters?

[icebraining]

Your server is has a slower CPU than a Intel 8080?

Re:Low power server / clusters?

[TheRaven64]

Another advantage might be lowering the number of components. A Beagleboard would make a great low-volume server, except that it lacks any way other than USB for connecting disks and network adaptors. The same ARM core with the GPU removed and a couple of SATA and GigE controllers added would be a great SMB server platform. You could pop the OS and most apps in the flash and connect an external disk for served files. With the disk spun down, you'd be using under 2W for the rest of the system.

Performance per Watt is a useful metric, but performance-that-you-actually-use per Watt is a better one. There's no advantage to making the machine take 10W and be 100 times as fast if it's already powerful enough for your needs.

Re:Low power server / clusters?

[david.given]

I am using an ARM-based linux server in my home.

cowlark.com is run off a single SheevaPlug with some USB hard drives attached. This is: SMTP server (postfix), spam filter (spey), IMAP server (dovecot); web server (thttpd); Java servlet server (winstone, run in OpenJDK, interpreted. Yuck. No JIT available for ARM); my local news server (leafnode); my local DNS/DHCP server (dnsmasq); my local backup server (rsnapshot). It's also my main shell box for doing downloads and stuff.

The whole hardware stack, UPS included, consumes about 18 watts, although this varies depending on whether the hard drives are spun up or not. Most storage is on a 64GB home-made SSD (4 x 16GB USB keys & RAID!), so it's completely silent.

The SheevaPlug is a 1.2GHz Marvell ARMv5, with 512MB of RAM and 512MB of flash (which I'm not using). It cost me about 70 UKP. Unfortunately it's only got one ethernet port, so I've got way too much stuff hung off its single USB port --- and Marvell's USB hardware is notoriously dodgy. The new GuruPlug looks way more exciting: same processor, but two ethernet ports, more USB ports, and SATA!

Re:Low power server / clusters?

[Anonymous Coward]

Can I have one installed in my toilet seat? We have all this technology, to take us to the moon, watch movies of discs of tin foil etc, but my one dream - a toilet seat with an electronic brain - has not been realised.

Re:Low power server / clusters?

[Eunuchswear]

I can see myself using an ARM-based linux server in the home.

The question is - what do you run on your home server?

Mine is mostly a file server, so I moved over to ARM last year (on a SheevaPlug, with 2 1To USB drives, mirrored of course).

If you run a lot of compute bound stuff you might be unhappy, but simple stuff probably doesn't need multicore.

Re:Low power server / clusters?

[wvmarle]

Exactly.

My previous server was 6, 7 years old when it became my server. It did the job nicely until the hardware broke down. The current server is not serving up files any faster (the 100 Mbit LAN is the limiting factor), it is not serving the web pages or sending/receiving e-mail faster (again the network is the limiting factor), backups took a little longer but that no-one is waiting for so that doesn't matter.

My old server probably used less power overall, so it was better for my power bill even tough it's performance per watt certainly was worse.

I honestly hope that this kind of low-power tech becomes more mainstream, and is not just used in the handhelds and so. If only to give an alternative in the desktop/laptop market to the Intel/AMD processors. But well until Windows runs on ARM that will not happen.

Re:Low power server / clusters?

[mapkinase]

On the home scale hassle very often is comparable to the benefit and the margin of benefit is comparable to economic perturbation (your car damaged by the snow truck during the freak-snowstorm of 2010, for example), while on the google serverfarm scale margin of benefit per a processor multiplied by the number of processors and can exceed economic perturbations.

Consider the analogy: home improvements very often are similar to the desire of the intelligent particle in the medium to avoid collisions to stay the course: the result does not depend of the efforts of such particle, it's still Brownian motion.

You installed your $20,000 (after government rebates and tax deductions) worth of solar panels on your roof only to find yourself fired and unemployed for the next year. Those $20,000 could last you much longer than that year in your house and in the end you lost it to foreclosure and had to move to your parent's basement.

Re:Low power server / clusters?

[jabjoe]

You mean like the SheevaPlug? You can buy one now as a home server, it does me just fine. :-)

Re:Low power server / clusters?

[Anonymous Coward]

So sad, the obligatory "Imagine a Beowulf cluster of these ARM-based devices" will not be funny in the future.... ;-) ...and I do not really think the Intel Atom would be funny considering that I am running a Postgres DB on a MSI WindBox II.

Re:Low power server / clusters?

[Arthur Grumbine]

So sad, the obligatory "Imagine a Beowulf cluster of these ARM-based devices" will not be funny in the future

Don't you say that! Don't you dare say that!!

Re:Low power server / clusters?

[gtall]

Unless windows runs like a drunken slug on ARM that is. So far, MS has needed the extra horsepower to make up for the bloat. It also isn't clear that MS is intending to port windows to ARM. They run XP on Atoms for the reason that 7 tends to squish them flat.

Re:Low power server / clusters?

[wvmarle]

Why Windows? I thought we were talking about servers here.

Re:Low power server / clusters?

[Anonymous Coward]

This is great -- I was just pricing out the Nokia N770 and N800 (both ARM devices) to use as a file server w/ a 1T drive I have kicking around. Slow (Samba over USB 1.2 + 802.11g), yes, but low wattage! Seems appropriate for off-grid solar households.

It will be interesting to see what this does to prices for the older models.

Re:Low power server / clusters?

[hairyfeet]

Correct me if I'm wrong, but wouldn't the Nano make a better choice for a low power server chip, with its hardware based encryption support?

As another poster said it isn't some sort of watts limbo, where the only goal is how low can you go, but more importantly how useful those watts are in actual application. The Nano will run existing x86 software, so backwards compatibility is no problem, and with security being in the forefront of everyone's minds these days it seems to me one would get better performance per watt while still being able to efficiently use encryption with the Nano. Seems like a better fit in the low power server role to me.

Considering Dell has a server based on Nano it seems like I'm not the only one to think that, though sadly Dell only sells the Nano based to "select customers" so if you want a Nano server yourself you would probably have to go with the mini server which would probably be just about the right size for a small business or home server setup.

Re:Low power server / clusters?

[daremonai]

Actually, it has: http://www.totousa.com/Washlet/WashletS400.aspx

Re:Low power server / clusters?

[Anonymous Coward]

A ton of servers out there don't need much horsepower, certainly not all the time. Hence the craze for virtualization and "cloud computing".

ARM can fit a somewhat different niche which requires even lower power and/or physical hardware. Imagine Google serving up data from a zillion little ARM nodes. CPU power isn't their primary concern for much of their infrastructure; hardware failure and I/O are much bigger issues.

And geeky home users probably have a powerful desktop/workstation for all their serious computing/gaming needs. The servers we build are typically routers and, as you say, file servers. Not much power needed.

Re:Low power server / clusters?

[Anonymous Coward]

A Beagleboard would make a great low-volume server, except that it lacks any way other than USB for connecting disks and network adaptors

This seems to be the thing missing in all the low-power motherboards I've looked at. Atom, Nano, and ARM motherboard makers: bring on the SATA ports!! Right now, if your server needs some .. oh, I dunno .. disks, then your CPU socket will be AMx or LGAx.

"Buy a NAS," some people say. Dude, you don't get it. It's a pretty much just a NAS that I want to build. Yeah, it'll be running a few more things than NFS but nothing demanding.

Wanted: approx 10-20 Watt CPU+motherboard, to which I can plug in a Gig or four of RAM, 6 or 8 SATA disks, and ethernet, all Linux-compatible and ready to stick into some monster ATX case. Who will build this motherboard first? Why isn't it already on the market? Every home that contains a television, needs one.

Re:Low power server / clusters?

[smallfries]

What kind of file throughput do you get on client machines?

Re:Low power server / clusters?

[Eunuchswear]

What kind of file throughput do you get on client machines?

Good enough. I've only got 100mbit ethernet in house.

Re:Low power server / clusters?

[smallfries]

That's quite an imprecise number :) I'm wondering as I've currently got a similar setup with 100mbit ethernet and external usb drives. Plugging the drive into a machine that consumes slightly less power would solve a lot of hassles.

Re:Low power server / clusters?

[Daengbo]

Did you write that in a non-western language and use machine translation?

Re:Low power server / clusters?

[ckaminski]

Except NASs are limited to two or four disks, and costs a shitload for what basically amounts to a case and a custom-sourced motherboard.

I want a general-purpose computing device that lets me plug in expansion boards. Give me a lower-power CPU with a couple/three of PCI-x8 slots for serial expansion and let me plug in say, a couple four-port SATA cards or a 4port GigE controller.

What I'm kinda digging now are disks with smart controllers, like the ATAoE->SATA adapter I found. Something like that that supports clustering? Let me take 20 disks, a gig of memory apiece, and let them do load-balancing and shared-nothing clustering to store data. As a SOHO user that needs to get the most out of my storage, (reliability included), I want more intelligence in my NAS devices.

Re:Low power server / clusters?

[Eunuchswear]

Well, I'm at work. Did you think I read Slashdot at home?

I'll try when I get home.

What kind of test would you like to see? Some copies should be pretty simple. (NFS and Samba).

Re:Low power server / clusters?

[Anonymous Coward]

Correct me if I'm wrong, but wouldn't the Nano make a better choice for a low power server chip, with its hardware based encryption support?

In the vast majority of situations where low power server chips make sense, No. If you are serious about low power, Nano doesn't even begin to compare to arm and if you are willing to go with something with the power envelope of a Nano, you have enough CPU power that encryption won't even be noticed as remember, this thing is going to be doing light duty and is limited to network speeds anyway. Furthermore, if this thing reboots for some reason, and you don't notice for a while, how is it going to be doing its job if it can't get to its own data before you decrypt it? What if you're gone for a week or two and have something important running on your server and it's sitting at some prompt waiting for a password before you can even log in? You're stuck until you get back. At the very least, encryption on a server is a hassle. Anything that really requires encryption can be done on an as needed basis and it is unlikely that hardware acceleration is going to be much benefit.

The Nano will run existing x86 software, so backwards compatibility is no problem

Oh, I get it, you're a Windows troll. For people doing real work, backwards compatibility between architectures on servers ceased being a problem long ago.

Re:Low power server / clusters?

[icebraining]

A VIA Epia EN12000E only uses 17W idle, 24W max, it's not too bad. Only 1GB of Ram and 2 SATA, though.

http://www.silentpcreview.com/article609-page1.html

Re:Low power server / clusters?

[inode_buddha]

Imagine using a BeagleBoard with SSD's. Is that enough to make you consider using the USB interface anyway? Granted, I would *love* to do this myself. Same as you. Although I insist on using Linux/FreeBSD on it.

Re:Low power server / clusters?

[TheRaven64]

Well, the other problem with the BeagleBoard is the RAM. I'm looking to build a FreeBSD NAS soon, using ZFS, but this really needs a minimum of 1GB of RAM, and ideally 2GB. Not a problem in theory for ARM, but the BeagleBoard doesn't run traces for off-chip memory, so it's limited to 256MB (you can get 512MB PoP modules now, but I don't think the BeagleBoard ships with them by default).

For my LAN, a USB2 ethernet adaptor would be fast enough. The BeagleBoard actually does support ATA, via the MMC interface, so in theory it could drive a disk or two. You could also use USB disks, but supporting three disks and a network connection over the USB is probably going to be quite slow. In theory, you could still saturate a 100Mb/s network with it, but theory and practice tend to be a long way apart with USB.

Actually, it turns out that there are some third-party expansion that adds a network port, but it's only 10Mbit.

Re:Low power server / clusters?

[washu_k]

I've never used them, but Supermicro does make a couple of boards with Atom CPUs and ICH9R southbridges. 6 SATA ports and a PCIe x4 (x16 mechanical) for further expansion.

Re:Low power server / clusters?

[smallfries]

Thanks, just some kind of file copy over samba would be enough. I just wanted to know if the server acts as a bottleneck, or if the usb connection is the tightest bottleneck in the system. As I've already got drives in a usb box that seems to hold them down to 22MB/s (not sure but I think they would hit 70-80MB/s if they were internal) then if doesn't throttle them any further it seems like a very neat solution for a file server.

Re:Low power server / clusters?

[Anonymous Coward]

But it's fun and exotic, making us feel special? That ego boost is worth the effort of making the available power savings of a single light bulb possible, particularly so if the server is to stay up 24/7 and employ low to medium cost passive cooling.

Re:Low power server / clusters?

[cynyr]

Jetway NF76-1G6E-LF 1.6GHz Via Nano fanless, single DDR2 slot up to 2 GB, 2 onboard sata, gigabit lan. While only 2 sata II 3Gbps on board, jetway has a line of daugther boards for their motherboards, ADPE4S-PB is the 4 port sata card. The sata controller both on board and the daughter board is marvel based and jetway has linux drivers available for download. I do not know if it is in the mainline kernel or not.

If 6 sata II 3gbps ports isn't enough, PROMISE SATA300 TX4 PCI SATA II 4-Port Adapter will give you another 4 ports.

*DISCLAIMER: I am NOT affiliated with jetway or with newegg. I have simply been considering a sillier project my self, and have not purchased the above mentioned products.

Re:Low power server / clusters?

[phantomcircuit]

You might be interested in http://icedtea.classpath.org/wiki/ZeroSharkFaq

Re:Low power server / clusters?

[mapkinase]

Nope. I just do not care much about the rules. If it consoles you, I am equally proficient in two other languages I speak, including my native language.

Re:Low power server / clusters?

[BikeHelmet]

Only if you can access that hardware based encryption - which means drivers and kernel support.

But if that's the route you're leaning, there are Nano systems available. Here's one. It was going for $199 pre-order a couple days ago. Just like a Sheevaplug, you can connect a bunch of external HDDs.

I'm inclined to just go for a full size tower like this. 8 drive bays loaded up with Green drives... tons of space, and very little power consumption. If you use 2 drives, an energy efficient motherboard and energy efficient PSU, you're looking at around 25 watts consumption. Add in 6 more drives and that barely increases to ~40 watts. (Unless they're all active at once)

That's pretty good for up to 16TB of space.

Re:Low power server / clusters?

[jeoeoeoeorb]

I delivered a backup solution for a small non-profit client on an ARM server. It's the Dlink DNS-323 and APC BK 350. Not sure about the UPS but the DNS-323 consumes 23 watts in use and 8 watts in power saving mode. From my observations power management works extremely well.

Re:Low power server / clusters?

[Anonymous Coward]

We use these for embedded servers at work: http://www.embeddedarm.com/products/board-detail.php?product=TS-7800

The TS-7800 runs a full Debian distro and is surprisingly fast on that hardware. Not exactly cheap compared to low end x86 machines, but great for applications that require low power and small size.

Re:Low power server / clusters?

[Eunuchswear]

I just wanted to know if the server acts as a bottleneck, or if the usb connection is the tightest bottleneck in the system. As I've already got drives in a usb box that seems to hold them down to 22MB/s (not sure but I think they would hit 70-80MB/s if they were internal)

Uh, if you're getting 22MB/s off the disks then your bottleneck is the network - 100baseT should be giving you somewhere around 10MB/s.

My hardware: ShevaPlug (1.2Mhz Marvell Kirkwood, 512M memory) 2 x 1To USB drives in a raid1 with dm-crypt on top, plugged into single USB port of ShevaPlug via a USB hub.

I ran:

sync; echo 3 > /proc/sys/vm/drop_caches

between each test.

On the server itself:

$ dd if=western-africa-1216384334.zip of=/dev/null
1198321+1 records in
1198321+1 records out
613540749 bytes (614 MB) copied, 37.4643 s, 16.4 MB/s

kcryptd is running at about 40% cpu during this test.

Pretty slow, but dm-crypt is obviously not helping.

Run on my laptop, using a NFS mount of the plug:

$ dd if=plug/western-africa-1216384334.zip of=/dev/null
1198321+1 records in
1198321+1 records out
613540749 bytes (614 MB) copied, 51.6017 s, 11.9 MB/s

(Over 100mpbs ethernet, i.e. pretty near max network speed).

Re:Low power server / clusters?

[smallfries]

Very cool, thanks a lot for running the tests.

Re:Low power server / clusters?

[Anonymous Coward]

Because their server operating system is called Windows too?

Re:Low power server / clusters?

[itzdandy]

100Mbit Ethernet = 12.5MB/s. Lets be generous and say you get %75 of that after TCP/IP and SMB overhead so = 9.375MB/s. It doesnt matter how fast your USB drives are as long as they can beat 10MB/s then 100Mbit ethernet is your bottleneck.

A sheeva/guruplug/open-rd can handle twice that so your bottleneck is still 100Mb ethernet.

How fast are these on gigabit? I have a sheevaplug with a moderately fast usb drive and I get...........about 6-8MB/s via SMB. How fast on 100Mbit Ethernet? 8-10MB/s. I think the USB chipset is the next slowpoint.

Re:Low power server / clusters?

[itzdandy]

Really? Looks like you write with a thesaurus in hand. I might point out that Einstein wrote and spoke like the common man. So does Gary Kasparov. Trying to sound smart with malformed sentences is...well...having and equal but opposite reaction. Consider the comma a breath mark. If you take a second to breath you might get a little more oxygen to your brain.

I am equally proficient in typing in the 51 languages Google translate speaks in addition to the 1 language I am truly fluent in and the 3 others that I can ask for a date in.

Granted, I'm not a genius like the aforementioned folks so you could just been miles and miles ahead of me, looking down as if I were and intellectual ant in comparison to yourself.

What are we to do with these?

[growse]

Forgive an ignorant person, but what sorts of server-like things are we expecting ARM chips to be good at? My understanding is that the ARM architecture is focussed on a reduced instruction set and running at low power. Does this mean I'll be able to run my 10TB Oracle data warehouse on this, or would I more likely use them in my webserver farm to save on power bills?

Re:What are we to do with these?

[del_diablo]

Performance per watt.
ARM gives performance at without massive cost of watt. Just scaling it up would mean performance.
ARM already got performance on par with x86, but uses less then 10 times the power. Now, if people are stupid to make use of x86 for servers would not a upscaled ARM cluster beat the crap out of it? Uses less power, faster.

And RISC means power, what buzzwords are you listening too?

Re:What are we to do with these?

[Nutria]

Does this mean I'll be able to run my 10TB Oracle data warehouse on this,

Softpedia also points out that there was also no indication that the company plans to go head to head with Intel's Xeon and AMD's Opteron series

Most probably not, and definitely not if Oracle doesn't generate ARM binaries...

or would I more likely use them in my webserver farm to save on power bills?

Instead ARM may limit its options to the print and storage server market.

That's a possibility too.

Re:What are we to do with these?

[Nutria]

ARM already got performance on par with x86

Pull out the benchmarks, or that's complete BS.

Re:What are we to do with these?

[Anonymous Coward]

I'd say that ARM is on par with x86 Hz vs Hz, or even better. The problem is that ARM is barely past 1 GHz while x86 is pushing towards 4 GHz. There are just now ARM processors with two high performance cores, while x86 processors are pushing past 12 cores and climbing. There are no ARM cores that I know of that does hyper threading, while almost all x86 cores do at least two way multithreading.

So.. I'd say that we will be using x86 for high performance servers for quite some time still.
However.. putting litterally thousands of low performance ARM cores in a 3U enclosure would certainly be good for some server applications.

Re:What are we to do with these?

[SpazmodeusG]

Low end stuff.
It simply can't do the high end stuff even when clocked at 2+Ghz as ARM is still a 32bit processor (there are some 64bit instructions but we're talking memory bus here).

I'm not aware of any ARM that can address more than 4GB of memory.

Re:What are we to do with these?

[Nutria]

I'd say that ARM is on par with x86 Hz vs Hz, or even better.

With all the caching and pipelineing and uber-high speed memory buses that x86 has, which ARM doesn't, I just don't believe you.

IOW, benchmarks or you're full of shit.

Re:What are we to do with these?

[kestasjk]

I agree, and I still don't get the justification. I'm guessing it's liberal use of the word "server".

Re:What are we to do with these?

[Anonymous Coward]

Ubiquiti - http://www.ubnt.com
Mikrotik - http://www.mikrotik.com
BeagleBoard - http://beagleboard.org

Re:What are we to do with these?

[Nutria]

Low end stuff.

And the racks upon racks of servers that average 10% capacity. Why couldn't many of them be ARM-based? (Except for the fact that they run Windows.)

Re:What are we to do with these?

[Anonymous Coward]

The first thing that springs to mind is fileserver. In my environment we have racks upon racks of machines doing nothing but taking data off disks and shoving it out the network. Their expensive x64 CPUs are quite idle, yet still use a considerable amount of power. ARM could be a perfect fit for this scenario.

Re:What are we to do with these?

[MemoryDragon]

They can be excellent as fileservers/cloud stuff, given their performance per watt ratio, dont expect that a computing intensive task is run on them (they are barely 2-3x as fast as an atom in their recent incarnations, but at a fraction of the power an atom uses)
but they are an excellent choice for io intensive cloud like tasks where you need a load of machines and have a vfs sitting on top of it.

Re:What are we to do with these?

[SpazmodeusG]

Well that's my point. That sort of thing is what the ARM will be good at. Low end stuff.

Re:What are we to do with these?

[Anonymous Coward]

For some, or even for most. People used to run(I haven't checked likely) web servers on Commodore 64s, it's not like my ARM-powered sub-netbook would be unable to run a real site. If it wasn't put into that little case, with a built-in battery, I would probably be using it as a file server right now.

I will be buying a few of those if they ever come out.

I wish Loongson processors had half the backing ARM has. They are damn MIPS64 processors(the newer ones) and they have been used to build the Lemote, the only laptop with completely open source software(BIOS, wireless firmware and OS(They favor GNU/Linux but OpenBSD targets the architecture as well).

Re:What are we to do with these?

[dkf]

IOW, benchmarks or you're full of shit.

Benchmarks are BS too. Better to check out the in-depth analyses in Microprocessor Report (that was certainly the source for this sort of thing back when I was doing this sort of hardware).

Generally speaking (at a very gross approximation!) the biggest factor in speed seems to be feature size, and ARM cores run cooler than x86 cores. ARM have focussed on the low-power end of the market far more than Intel and AMD (who have been duking it out at the high-speed end) and this means that for some applications, their stuff is absolutely best. I don't know whether that's true for server-class computing; the lower power consumption will get better packing densities but whether that will compensate for the reduced computational power I just don't know.

Of course, a good benefit in the "small server" market would be being able to run normal workloads without active cooling (i.e., fans) in a normal room. That would save loads on power and aircon. (And I know for one thing that there are ARM cores that can cope with very wide temperature variations. It's impressive when you see someone torturing a CPU with a hairdryer and – straight after – some dry-ice...)

Re:What are we to do with these?

[hattig]

The ARM Cortex A8 core is roughly on par with an Intel Atom, clock for clock (maybe a little slower). Of course it tops out at 1GHz, and the Atom is available up to 1.86GHz.

The ARM Cortex A9 is faster than the A8, and will be available at up to 2GHz in single, dual and quad-core versions. A quad-core 2GHz A9 can do 10,000 DMIPS in 1.9W. I would hope that such a CPU would be coupled with decent caches and memory interface, otherwise the cores will get starved.

ARM also needs a 64-bit ISA, but I'm sure that they're working on it, or have even completed it.

Re:What are we to do with these?

[Alioth]

Anything concurrent.

I know that one of the original developers of the ARM CPU is working on a massively multicore ARM-based project (tens of thousands of cores). Apart from just the low power aspect of ARM, what makes it good for hugely multicore projects compared to x86 is that an entire ARM core is smaller than just the part of an x86 processor that figures out the length of the next instruction - x86's ISA becomes a huge ball and chain if you want to make a massively multicore system.

Re:What are we to do with these?

[Anonymous Coward]

Notice that your reduced instruction set refers to (reduced instruction) set, not reduced (instruction set). Big difference there.

If you look at current x86 processors, you will see they are actually RISC processors that emulate CISC. In other words, it uses the simpler instructions to build more complex ones. This adds two things to your x86 processor: Additional overhead on the emulation (either thru microcode or extra circuitry to decode those instructions, circuitry which could have been spent doing something else) and uneeded instructions, the complex instructions can just be replaced by the reduced ones.

This is really a holy war, much like the *nix wars and the editor wars. There are both pros and cons to each side, personally I subscribe to the RISC school. All I can say is, the ARM9 Feroceon 88FR131 at 1.2GHz on my plug computer is capable of handling archlinux running a home server without a sweat or stuttering, streaming HD media and doing mySQL.

Re:What are we to do with these?

[fbjon]

ARM cores have both cache and pipelines, y'know? But lets find those benchmark results by making them ourselves:

Using one core on an AMD X2 2,8GHz and an ARM Cortex A8 core at 600MHz on a beagleboard, I've done some tests. Cache-optimized matrix multiplication of two matrices at 600x600 takes 0.45 seconds on the AMD, and 4.57 seconds on the A8. That's about 10x slower. However, the A8 (in an OMAP3530 package) produces just under 1W of heat. The TDP for the AMD is 65W, but since it's dual-core let's take half of that, plus an additional 20% fuzz factor because the TDP is the maximum rating.

By this slightly fuzzy, synthetic but memory-heavy benchmark, the performance-per-watt difference is about 2,5x in favor of the ARM Cortex A8 core. One core of an AMD X2 would have to put out below 10W to beat the A8. By my fuzzy math that would mean a TDP of 25W or below for the processor.

There you go, you're welcome! :)

Re:What are we to do with these?

[Anonymous Coward]

No, benchmarks really aren't BS. Ultimately if you want to compare two systems you have to run a test workload and compare based on that. Otherwise it's all just theorical performance.

The problem with benchmarks is that they sometimes don't represent real use cases, so sometimes you don't get realistic results. This was the problem with the notorious Transmeta Crusoe benchmarks, for example.

Theoretical ARM vs x86 comparisons omit considerations such as the difficulty of making a true superscalar out-of-order ARM with similar issue width to recent x86s. When you go superscalar out-of-order with ARM, all of the RISC-like benefits basically cease to apply, because you're dealing with instructions that read three registers and update two more, and instructions that can do stupid things like address the PC as if it were a GPR. At that level of performance the ARM benefits are gone, and you have something very like an x86 in terms of performance per watt and chip area. The dirty secret about the ARM ISA is that it's massively braindamaged, which is why they'd like everyone to be using Thumb2 now please.

Re:What are we to do with these?

[rugger]

Once you start pushing the performance envelope with the ARM core, your performance-per-watt advantage will become less pronouced.

The ARM processor looks so good in your benchmark because it is really not asking much of the silicon at all. Increase the ARM processor's clock rate to 3ghz, and you will need to add:

1) More cache to prevent memory core starvation
2) More voltage to make the silicon transistors switch faster.

This will cause the ARM processor to create a LOT more heat.

The key will be to find an acceptable performance level that doesn't work the silicon hard so you don't consume a lot of power. x86 or ARM, it doesn't really matter.

Re:What are we to do with these?

[cheesybagel]

Is this floating point multiplication? ARM processors are known for their usually horrible FP support.

Re:What are we to do with these?

[cheesybagel]

How much die space do Thumb and Thumb-2 add? Precisely. Compact instruction encoding is important.

Re:What are we to do with these?

[cheesybagel]

That used to be true when transistors were expensive and memory was fast. The choice used to be between more CPU registers with less instructions (RISC) or less CPU registers and more instructions (CISC). Today transistors are cheap and memory is slow, so the more things you put on die (within reason) the better. It used to be that multiplication was considered too expensive to put in the ALU of a RISC processor, or barrel shifters, today this is simply not true. In fact even RISC processors have multiply-add instructions today (e.g. Power), more complex than what you see in even a CISC like x86.

Re:What are we to do with these?

[fbjon]

But isn't that the whole point? Push for server performance by adding more processors, and you keep the performance per watt. If you really need fast individual cores for something that doesn't parallellize, it won't work, but I'd imagine the average web server farm would benefit.

Re:What are we to do with these?

[fbjon]

Nope, just plain integers (not long).

Re:What are we to do with these?

[hedwards]

You're making some questionable assumptions. Of course ARM is barely at 1ghz and doesn't have the various performance enhancements that the x86 processor family does, they've been focused on embedded devices and now some netbooks. ARM also lacks the legacy kludge that the x86 chips have as well. At some point there's going to have to be some revision of the processor to get rid of the stuff that hasn't been useful in 20 years.

But more than that, if there is an actual market for ARM based servers, all the things people've cited in other posts here can be remedied. And remedied more quickly than they were for the x86 given the understanding that hardware engineers have now about the challenges of doing it.

I'd be shocked if this doesn't come through with both Google and MS expressing some interest in it.

Re:What are we to do with these?

[wvmarle]

Far from all servers are used in data centres.

Far from all servers have a typical >50% load on their processor.

There certainly is a huge market out there for small, lower-end servers for which your average Intel based box is simply huge overkill.

Re:What are we to do with these?

[wvmarle]

That means it still can do stuff that only a few years ago we called "high end". It is just not top-of-the-line. And what many geeks and nerds tend to forget is that >90% of any market is in the lower end.

Re:What are we to do with these?

[Lunix Nutcase]

Using one core on an AMD X2 2,8GHz and an ARM Cortex A8 core at 600MHz on a beagleboard, I've done some tests

An AMD X2 is fucking ancient. Compare it against something modern like an i7.

Re:What are we to do with these?

[Nursie]

Some of the newer cores have an optional FPU, meaning you need to look at the device/specific chip you're buying to see if it's on there. This helps.

Otherwise yes, FPU is terrible. I'm not sure you need one for file/web/mail/news/torrent/stuff serving in general though do you?

Re:What are we to do with these?

[washu_k]

Even if your "fuzzy" numbers are close enough (all the ARM vs X86 benchmarks I've seen are even more in X86's favor), the AMD X2 is not even close the best performance-per-watt X86 CPU.

A mobile Core 2 or i5 have TDPs or 35W or lower and almost never draw anywhere close to that in actual use. They are also significantly faster than an AMD X2. They would easily beat the A8 in performance per watt if your numbers are correct.

Re:What are we to do with these?

[bluefoxlucid]

Benchmarks ARE theoretical performance. Real-world workloads do weird things the benchmarks don't, mostly using instruction sequences that break the caching method, or having memory scattered around, etc. Benchmarks are simplistic and test "full throttle" but the branch prediction is easy as hell on them and they have small working sets. nVidia was notorious for outperforming ATi by around 30% or more, sometimes as high as 70% more work done in the benchmarks; then in real games, getting 15fps while the relevant ATi card got 40-60fps.

Re:What are we to do with these?

[bluefoxlucid]

Yeah, but in real world workloads where you're doing string manipulation, memory manipulation, complex logic branching through shit, etc, I bet the ARM will perform faster. Try a benchmark such as running MySQL on Linux, on both, with PHP and Apache, generating output (no caching) by doing lookups and lots of decisions in PHP. Then run constant queries as fast as you can on each; figure out who's doing how many requests per second; and then multiply the benchmark off the AMD by (.6 / 2.8) to get a performance-per-clock index. Oh, as the AMD is dual core and the scheduler will use both for the required loads, you will probably want to divide the AMD performance index by 2 for this particular test.

Re:What are we to do with these?

[Daengbo]

I'm sure he used what he had. Geez.

Re:What are we to do with these?

[Nutria]

Well that's my point.

I don't always disagree. Sometimes I try to bolster other peoples' arguments.

Re:What are we to do with these?

[Lunix Nutcase]

That's fine but his benchmarks are then worthless in the context of the real world. Not to mention the fact that comparing a 4-5 year old x86 processor to a relative newer ARM is highly disingenuous. Xeons from even two years back are far more efficient per watt than that X2.

Re:What are we to do with these?

[LWATCDR]

But you are missing the point.
At my office we have a Linux NAS running a P3 that supports 50 people with no problem.
We have a PostgreSQL server that runs our call management system that supports 50 or so users and that is running on a 600 Mhz P3 with no problems.
We have firewalls, mail servers, and web servers.
We could probably virtualize them all on a quad core x86 but that would give us a massive single point of failure. Also we like to keep our firewalls on separate boxes anyway.
Probably an ARM would be more than powerful enough for many of these tasks. It would probably be cheaper, and more power efficient as well.
If we had a smaller office I would be willing to bet that a single ARM based box with the right storage system could be our NAS, Database server, intranet webserver, and maybe mail server.

Re:What are we to do with these?

[LWATCDR]

"ARM also needs a 64-bit ISA, but I'm sure that they're working on it, or have even completed it."
A I think they have
and
B I am not so sure. You only need 64 bit if you are going to use very large integers or if each task needs more than a 32 bit address space.
It is entirely possible for a 32 bit cpu to have more than four gigabytes of memory. You only really run into issues if any one task need a very large address space.
While some server tasks do fit those requirements a lot of them will do just fine with 32 bits. At least for a while.

Re:What are we to do with these?

[rbanffy]

Who would want a server running Windows, anyway?

Re:What are we to do with these?

[snadrus]

They are now releasing dual and quad ARM chips at those speeds, which gets them around the midrange desktops.

Re:What are we to do with these?

[Nutria]

Who would want a server running Windows, anyway?

Regardless of whether it's "morally right" to run Windows servers, the fact is that much commercial software with no adequate FLOSS counterpart requires Windows, and also there's a bajillion MCSEs living in Steve Ballmer's rectum who love running Windows.

Thus, that's an incredibly stupid question.

Re:What are we to do with these?

[tzot]

You do know that AMD's TDP and Intel's TDP numbers are not directly comparable, don't you? They don't report the same thing. For example, look here.

Re:What are we to do with these?

[inKubus]

Yeah, I could see these replacing the Celerons in Cisco hardware.

Re:What are we to do with these?

[jon3k]

An average of 10% utilization sounds like a great candidate for virtualization. VMWare with DRS to consolidate guests and power down some host machines during off peak processing times.

But let's not forget that while an average of 10% is fine you still have to accommodate peak demand.

Re:What are we to do with these?

[evilviper]

And the racks upon racks of servers that average 10% capacity. Why couldn't many of them be ARM-based? (Except for the fact that they run Windows.)

Because VMWare, Xen, et al. on 1 or 2 full-fledged servers would provide better performance for less money, and less power.

Re:What are we to do with these?

[fbjon]

Good point, though the difference between the processors is more like 3-4 years. So here is the same test lopsided in favor of the AMD, using a Zaurus:

The processor is a PXA255 XScale 400MHz (ARMv5) from 2004, package power rating 1.4W. Same code, runs in 7,54 seconds. The performance-per-watt still comes out as 1.08x in favor of the XScale, which is 2 years older.

Now I don't know anything about Xeons, but judging by some specs from Wikipedia, an 3GHz Xeon from 2008 at 45W - AFAIK not the maximum rating - would have to do the same work in 0,21 seconds to beat the Cortex A8, i.e. twice as fast as the AMD X2 or thereabout. Using the Tom's Hardware charts as a very rough guide, I would expect the Xeon to be only about 30%-40% faster than the X2, so I still wouldn't expect it to have a better performance-per-watt compared to the A8.

Re:What are we to do with these?

[itzdandy]

(this one got long, skip it if you are drowsy)

Here is a metric that I think is realistic. power * instructions/s * size.

You can put a dual quad core intel system in 1U of a rack and its going to draw 500W without any drives

How many ARM cores can you put in that same 1U of space, what is the power usage, and does that perform better for your workload?

x86 systems have a very complex set of requirements in motherboard and overall system. This gives a ton of flexibility. ARM systems need substantially less on the mainboard but the systems are less flexible in this regard as a result.

My math says that the ARM board out of the sheevaplug is 4"x6" (or slightly smaller). A 1U Rack is usually 19"w x 30"d. so 24"sq vs 570"sq means roughly 23-24 sheevaplug boards at 4W each. Ill round to 24 considering form factor can be adjusted pretty easily on these.

24 ARM cores at 1.2Ghz vs 8 Intel cores at 3Ghz. Thats 28.8Ghz ARM vs 24Ghz INTEL. Its also 500W vs 100W. if we are talking power usage here then its 5:1 or 144Ghz ARM vs 24Ghz x86 and I suspect that margin is enough to readily beat x86 at the same power consumption. If its raw performance then I suspect that the 24Ghz of x86 is going to run circles around the ARM setup.

So right now, I suppose you can match x86 in power/performance. If you need truly high performance computing, ARM isnt your choice. at $.10-.15/KW of power ARM cant beat x86 in the server rack but it can challenge it.

Where can ARM win in reguard to servers? here are some thoughts. DNS servers. do you need to burn 400W for DNS when you can burn 4W? Proxy server. email server for 100 users. small file server. IPPBX for 20 users. Firewall for 10Mb/s WAN.

In the datacenter I think that high performance vs price is the key. power only comes into play when the cooling systems have to be upgraded, price of power spikes, etc. Getting stuff done in a rack is more important than using less power because simply put, you could use less, high powerformance systems to reduce your power consumption.

I think ARM servers place is in small offices, homes, small businesses etc. you can build a VoIP PBX, DNS server, File server, email server, Firewall and Router out of a handfull of ARM servers in some modular design for under a grand and use under 100W

Re:What are we to do with these?

[itzdandy]

With all the caching and pipelineing and uber-high speed memory buses that x86 has, which ARM doesn't, I just don't believe you.

IOW, benchmarks or you're full of shit.

Though I agree, I would point out that much of that pipelining is the break jobs down so they can be handled by complex CPUs and the caching is to hide the very long pipelines. ARM is a very very simple cpu in comparison with a much shorter pipeline. ARM7 just 3 stages. Cortex-A8 has 13 BUT many of those are really substages and many instructions can flow through a bunch of the pipeline in one clock.

What this really means is that an ARM7 cpu can do many MANY more very simple instructions in the same amount of wall time as an intel chip. 1.2Ghz x3 stages vs 3Ghz x14 stages is a big deal. The Core2Duo's 14stages can do some serious work, but the simplest work gets done slower than on an ARM system because it takes more clock cycles to get it done.

Whatever happened to MIPS?

[Colin Smith]

Low power per operation and all that?

 

Re:Whatever happened to MIPS?

[GuyFawkes]

My RAQ2 is still going strong, home server, uses according to a kill-a-watt meter about 20 watts, which I could reduce significantly by replacing the old 80 gig IDE with a laptop drive and adapter.

Apart from that, runs stone cold, fanless, so silent, and 100% reliable.

I've tried to talk up MIPS / Cobalt before, but it has fallen on stony ground, frankly I think most /. readers just have zero hands on knowledge of these devices.

The RAQ550 and XTR (got 2 each of them too) were abominations by comparison with the 2, also got two 4's running 550 OS.

Long live MIPS

Re:Whatever happened to MIPS?

[cheesybagel]

I guess they never could license it properly, or the licensees lack volume. Also MIPS R&D was usually done by SGI. Well SGI was never exactly interested neither in low power, nor in being cheap. I guess that matters.

Re:Whatever happened to MIPS?

[cheesybagel]

Cobalt was bought by Sun which was bought by Oracle IIRC. Also Cobalt delved into X86 processors later in their design cycle. MIPS was not cheap enough.

AFAIK there are some Chinese CPUs which are MIPS compatible (Loongson) and Tilera's design is also MIPS like.

Re:Whatever happened to MIPS?

[CAIMLAS]

While I agree with you completely, it doesn't seem like it's possible to find MIPS based devices for sale any longer, short of the occasional ancient device or Chinese netbook via eBay.

I suspect the licensing costs are too high or something like that. Back around ~2000 there were a number of handhelds/portables that had MIPS processors; later versions had SmartARM and were not proportionately faster (by clock). MIPS does not appear to have matured as fast as ARM has in terms of most modern features, either - aside from the fact that there are 64 bit MIPS out there and have been for some time.

Frankly, I'd love to get my hands on a "desktop" multicore MIPS or ARM board or four. As much time as I spend computing at home these days, it'd be useful for the power savings alone (no, I'm not keen of turning my computers off; why?)

Re:Whatever happened to MIPS?

[drinkypoo]

MIPS was eaten by ARM, in the market anyway. The last people to use it for a successful mass-market computing appliance were Sony, and there's three MIPS chips in the PS2's Emotion Engine; one on the frontend to act as a decoder, switchboard, and to handle general processing tasks like input, and two more 64-bit cores with some 128-bit data types behind them, V[P]U1 (they've been alternately referred to as VUs and VPUs over time) and VU2. They're full-fledged processor cores being used as vector units. I forget what kind of cores they all are, this information was floating around when the PS2 was coming out but it's not on Wikipedia, or at least, I didn't find it in a cursory glance. However, Sony carefully avoided any mention of MIPS in the PS2 marketing literature. The Playstation also used a MIPS core, an R3000, just as you might have found in an SGI Indigo in terms of capabilities.

Re:Whatever happened to MIPS?

[GuyFawkes]

Longsoon-3 (they already built a world ranking supercomputer based on Longsoon-2)

Longsoon-3 is 4 cores on a die and 4 Mb on L2 cache on chip, running at > 1.25 GHz

see http://www.computer.org/portal/web/csdl/doi/10.1109/MM.2009.30 for more

Re:Whatever happened to MIPS?

[Steve Blake]

Look at Cavium Octeon or Netlogic (was RMI) XLR/XLS/XLP. All of these are multicore MIPS. They are frequently used in security appliances, but occassionally also in storage boxes.

To serve what

[wmac]

ARM based servers are coming to serve what?

ARM is not even that suitable for a PC. On a server you need multiple fast cores and good I/O. Which of these are provided by an existing ARM CPU?

In my opinion if there are 10 fields that ARM can be used , this one is the worse.

Re:To serve what

[obarthelemy]

some say you need good perf/watt and low idle power ?

Re:To serve what

[wmac]

I am more than fine with that. But the question that what it is going to serve remains there.

We need to see what applications can be run on such a server? By focusing on idle power we are talking about an application server which is being used a limited period of the day? Or a server which is rarely used?

Otherwise, even a mobile phone can be used as a server. In fact we used mobile phones as grid computing nodes in our lab (which serve computing power to the grid). But it was just something to prove such a crazy idea is possible but not practical necessarily)

Re:To serve what

[ByOhTek]

You don't need multiple fast cores necessarily - it depends on the server.

You do need good I/O on most servers. The earlier benchmarks of the Sun T1 was a nice example of this. IIRC 8 cores, each with two threads of execution, back when x86 was single and dual core. The cores were wimpy, but on many server applications (web, file, I believe database) it beat x86.

You need a lot of cores, yes, but they don't need to be powerful for most server applications - since most are parallel.

Re:To serve what

[petermgreen]

Afaict datacenters generally charge based on peak current anyway since much of the cost of datacenter electricity is actually in the infrastructure (generators, UPSs etc).

Performance per watt does matter to an extent but performance of individual threads also matters. The longer each individual request takes to deal with the more ram you need and the longer you keep any DB locks open for increasing the chance of lock contention there.

Another big problem with arm is that you can't rely on the presence of any particular floating point instructions. So you either compile everything for the specific FPU variant you have or you end up using softfloat

Re:To serve what

[jedidiah]

ARM is fine for a PC. Most people don't push desktops just as most companies don't push servers.

Just as with Solaris x86, the real problem is getting good enough 3rd party applications support.

What's what "detractors" usually whine about first when it comes to Linux netbooks.

Re:To serve what

[bluefoxlucid]

ARM based servers are coming to serve what?

man.

Re:To serve what

[tzot]

The day the aliens come with a "To serve man" book under their armpits (if available), I'm certain we'll find out that ARM meant Appropriately Roasted Meat.

They are already here

[Anonymous Coward]

Depending on your needs you can already use ARM servers. This http://www.open-rd.org/ is perfect as a dns server, dhcp server, firewall, mail server or even a webserver on a small network. I really like using those devices as 'physical virtual servers': ideal as an isolated, task oriented server for tasks that do not need a full fledged server.

I have one of these at home (with Debian on it and a 2TB hard disk attatched).

Re:They are already here

[Nursie]

Hell, you could do that with an NSLU2, running an arm core at 266MHz with 32MiB of RAM and an external drive. That *and* a simple torrent box.

You can do much more with a sheevaplug, mine has a full vnc server and gnome running on it at reasonable speed, or at least it had before I emigrated and gave it away. An OpenRD box should be fully capable of being a basic linux desktop machine.

MSFT will just make a leg-based server

[Anonymous Coward]

Then port Windows to both.

Microsoft will then have an arm-and-a-leg OS.

Re:MSFT will just make a leg-based server

[silentcoder]

>Microsoft will then have an arm-and-a-leg OS.

Finally, a feature-set to match their pricing !

Re:MSFT will just make a leg-based server

[ooshna]

Actually... Windows 7 cheapest version yet.

Re:MSFT will just make a leg-based server

[ckaminski]

$299 for Windows 7 Professional, to get the same features as the Windows XP Professional license I bought in 2002 for $199 (Retail-boxed prices both). Not even inflation can account for that.

It's at the point now where Windows is almost a 1:1 expense with the platform I'm running it on.

Oh wait, you mean their predatory OEM licensing prices? Right. :-)

Re:MSFT will just make a leg-based server

[Tubal-Cain]

That doesn't refute silentcoder's claim.

MIPS

[CondeZer0]

It is nice to see some alternatives to the x86-monoculture coming along, but I wish MIPS was still around, it is a beautiful architecture with the same efficiency advantages of Arm but an even cleaner design.

Re:MIPS

[Anonymous Coward]

It is nice to see some alternatives to the x86-monoculture coming along, but I wish MIPS was still around, it is a beautiful architecture with the same efficiency advantages of Arm but an even cleaner design.

AFAICS it's still going. There was a recent announcement of a MIPS SOC with a built-in GPU.

Re:MIPS

[ishobo]

Still around? MIPS is going strong in the embedded market. My company works on transit systems and MIPS represents about half of our work. There are lots of networking products that uses MIPS, from the customer to the core. RMI has a MIPS64 eight core SoC with four threads per core.

Re:MIPS

[TeknoHog]

You can get a MIPS64 netbook today, it's called Lemote Yeeloong.

Re:MIPS

[CondeZer0]

I'm aware that MIPS is alive and well in the embedded world, but it has pretty much disappeared from the server market where it used to have a very strong presence.

Also, for somebody just interested in playing around with alternative architectures, it has become harder and harder to find cheap MIPS systems to play around with (the PS2 was a mips system, but the PS3 is PPC, the PSP is probably the only easily 'hackable' MIPS hardware still being produced in considerable quantities).

And yes, I'm aware of the Chinese MIPS laptops, but they not easy to find and at least outside china they seem overpriced given their specs. But maybe there is still hope...

Re:MIPS

[Nursie]

Also, just to add to your list, the Sony PSP runs on MIPS IIRC

Re:MIPS

[ld a,b]

I don't think Loongson is dead just yet.

MIPS64 for you. They even bought a license after doing it the arr way.

http://en.wikipedia.org/wiki/Loongson

Re:MIPS

[Anonymous Coward]

No, you can't. Not a single store sells them and the company behind it doesn't even bother to put out a english version of their mandarin site. In fact, does this product even exist beyond press releases and marketing ploys?

Re:MIPS

[TheRaven64]

They weren't selling outside of China due to patent issues preventing import into anywhere that the MIPS Technology patents were valid (which is most of the western world - they're hardware patents). That should change now that they've licensed the patents. A few have been available before then - I've heard from a couple of people using them, but they had to import them themselves.

Re:MIPS

[TeknoHog]

At least two European online stores sell them:

http://lemote.kd85.com/

http://www.tekmote.nl/epages/61504599.sf/nl_NL/?ObjectPath=/Shops/61504599/Categories/%22Lemote%20linux%20PC%20and%20Linux%20laptops%22

Re:MIPS

[Anonymous Coward]

The patent that MIPS was suing everyone over (US 4814976) expired in 2006.

Re:MIPS

[sznupi]

Well, PS2 is a MIPS system...production continues and Sony stated it will continue as long as demand for consoles and games is there (new ones scheduled for this year, too)

That's probably in large part due to so called "3rd world" countries, but I'm sure you can pick one up easily where you are.

Re:MIPS

[Nursie]

Depends what you want to hack. My Netgear ADSL router is MIPS based and runs linux so you can roll your own distro if you want.

Not that I did, but I like that the option's there.

Re:MIPS

[CondeZer0]

AFAIK recent PS2 systems do no support Linux or other OSes. But I must admit that I have not kept up with the homebrew community.

I do know that the PSP has a cpu similar to that of the PS2, and that it has been hacked and has a healthy homebrew community, but still, it is not the same as a really open and documented system.

Re:MIPS

[Rozzin]

No, you can't. Not a single store sells them and the company behind it doesn't even bother to put out a english version of their mandarin site.

Just click on the link on http://www.lemote.com/ that says "English" (in the upper-right corner) and it'll take you to the English version: http://www.lemote.com/en/

In fact, does this product even exist beyond press releases and marketing ploys?

Freedom Included sells them in the US: http://freedomincluded.com/

Re:MIPS

[ishobo]

it has pretty much disappeared from the server market

I would disagree with that with that statement. It is in the server makert, in application specific appliances. The only server maker pushing MIPS was SGI and it was not exactly going anywhere under their ownership.

it has become harder and harder to find cheap MIPS systems

You can get development boards. I would not know about Linux. I work on reliable systems, that means QNX and Integrity for us.

I just did a quick search and found a few boards from $100-$200, including from MIPS itself.

Fairy Tale: ARMs Race Against x86

[reporter]

ARM is almost like a fairy tale in which the underdog triumphs. ARM was developed on a shoestring budget by a small team of brilliant anti-establishment engineers. By contrast, the x86 processor was developed on a multi-million-dollar budget by a large team of disciplined slaves across 2 continents.

ARM is David. x86 is Goliath.

Most of us inherently favor David.

Re:Fairy Tale: ARMs Race Against x86

[devent]

I favour anyone who can build and deliver a laptop with 12 hours battery live. In addition, a low power ARM server for office work (small and middle enterprise) is a nice to have, too. I think most users don't give a piece if it's x86 or ARM, as long as their applications are running and it's a good deal. I, for myself, am really glad finally see any innovation in desktop CPUs. I thought in 20 years we will still be using x86 compatible CPUs.

Re:Fairy Tale: ARMs Race Against x86

[bhtooefr]

Of course, you can spin it another way. ARM is an IP company - they don't make chips, they make IP (their architecture specifications, and their CPU designs) that they then license to other companies. Then again, they're not a patent troll, their IP is generally fairly good (even if the various architecture versions and features are ridiculously confusing,) and they actually do license it, rather than just keep it so they can sue people.

Application specific servers

[msgmonkey]

Whilst ARM processors do have excellent MIPS/Watt the processors do have lower clock rates, smaller cache, slower/narrower buses so I do n't see these being very useful for general purpose multi user servers. However if your application is mainly I/O bound and you can do most of it via DMA they would be great. I can imagine for google they make alot of sense, however for something that runs on PHP like facebook less so.

Re:Application specific servers

[cynyr]

they would make very nice home servers, or SMB NASs. Assumming you could get a sata controller on them.

Re:Fairy Tale: ARMs Race Against x86

[gzipped_tar]

I've always thought that the x86 architecture is a dead horse beaten to the speed of light. It is the 21th century and we need something slightly better than rocks and sticks and x86 to throw at the old monstrosity known as computation. If we're still going to depend on x68 in 20 years I'd rather kill myself by banging my head against an x86 chip.

Re:Fairy Tale: ARMs Race Against x86

[MemoryDragon]

s/anti establishment/shoestring budget and you are correct :-)
ARM nowadays is a big company but originally it was a sidedevelopment for the next BBC machine.

Re:Fairy Tale: ARMs Race Against x86

[kangsterizer]

well i bought a R3 6 years ago. with a R6-9 battery which adds like 1000 mah it reaches 12-13H and its a lot faster than any atom or arm based netbook of course. stock, i had approx 10h

note that this is with 50% brightness, doing basically text and stuff, browsing with wifi is prolly a few hours less give or take

that's a pentium m ulv for the record

It makes some sense...

[Anonymous Coward]

If you can use an arm based server farm as base infrastructure to deploy a VM OS like VMWare, or other.

It would have a performance handicap, but the power costs would be lower and it would be flexible. And probably makes a lot of sense if you are hosting cycle hungry applications.
And even for those it could be solved by adding extra machines to share the load.

For example on a navy ship it would make perfect sense, you could have a series of small distributed clusters, all running a distributed virtual OS running the ship's main operations and integration functions.
If necessary it could be possible to degrade the service to save power, and when it's necessary run more services.

Competition is good.

[robcfg]

After many years, Intel finally has some challenge. And for those of you who doubt what ARM chips are able to do, I'll tell that I've been surfing the web and chatting through MSN Messenger on an Acorn A7000+, which runs on a 48 Mhz ARM 7500FE. Now, if they can raise that to 2ghz, I see very nice performance while still retaining a fairly low power consumption.

Re:Competition is good.

[Brianwa]

I browse the web and use chat every day on a 312 MHz XScale machine. It also makes phone calls :D

Re:LEG

[Anonymous Coward]

Available already. They just cost you an ARM and a LEG.

Btw. just running on ARMs seems a bit backwards.

Or people could stop buying stupidly large gear

[Gothmolly]

I requested a small server for a project at work - the minimum my shop buys is an 8-way,16GB beast. I need to run 1 single-threaded app, and I get this.

Re:Or people could stop buying stupidly large gear

[arndawg]

But we, the people, don't buy stupidly large gear. We virtualize. What kind of place is this?

Re:Or people could stop buying stupidly large gear

[Anonymous Coward]

I think the word "server" confuses the fuck out of some people. They think it's code for "heavy workload" when in 90% of the cases, it's exactly the opposite.

beagleboard

[Anonymous Coward]

i already have a beagleboard as a home server. :-)

Re:Fairy Tale: ARMs Race Against x86

[Zoxed]

> ARM is David. x86 is Goliath.

ARM is British. x86 is from that-place-across-the-water-that-seems-to-be-doing-quite-well. :-)

Beowulf cluster

[threaded]

What's the point of a Beowulf cluster if it doesn't cause the lights to dim when you're performing your mad scientist calculations?

Re:Beowulf cluster

[not-my-real-name]

I used to have a PDP-11/10 that would do that.

Re:Beowulf cluster

[cyberthanasis12]

What's the point of a Beowulf cluster if it doesn't cause the lights to dim when you're performing your mad scientist calculations?

You have a point. But imagine a cluster that does NOT and CAN NOT run Windows.

Re:Beowulf cluster

[Hurricane78]

No wonder with your sissy simpleton calculations. ;)
Real mad scientists simulate whole universes. At least.
And the solution is simple: MOAR CORES! ;)

Re:Fairy Tale: ARMs Race Against x86

[Haxamanish]

I used to run MS-DOS (*) in the x86 software emulator on my 4-8MHz (**) ARM2-based BBC Archimedes in 1987 - some people then refused to believe this was even possible.

(*) MS-DOS 5.2 IIRC - I needed the TopSpeed Modula2 compiler for my programming assignments & WordPerfect to open some docs.

(**) 4 MHz when reading ROM, 8 MHz when reading RAM (there was a command to copy the entire ROM into RAM in Arthur 0.2/RISC OS 1.2)

Re:Fairy Tale: ARMs Race Against x86

[Anonymous Coward]

Anti-establishment in what sense?

Are ARM chips planning a reactionary counter-revolution to overthrow the state? Is the branch predictor full of anarchy, the instruction cache full of civil disorder?

For Christ's sake, these guys were funded by the BBC. You don't get any more Establishment.

Also, your David versus Goliath comparison is bizarre. Did you actually read that bit of the Bible? Because David is already king of embedded systems and has a bit more to fight with than just a sling and a stone.

Re:Fairy Tale: ARMs Race Against x86

[squizzar]

Israel? I thought that was where the current Intel Architecture was designed?

Cool - a Windows 7 Mobile Server?!

[howardd21]

Inevitably, somebody will try a server running Windows mobile or one of the other phone OSes, and have no multitasking or cut and paste, and which runs only SilverLight or XNA apps. Oh the humanity.

Re:Cool - a Windows 7 Mobile Server?!

[Tapewolf]

The Casio IT500 (Windows CE 4) shipped out-of-the-box with running web, FTP and telnet services. I have no idea why, since it was the sort of thing you'd use to scan package barcodes in a warehouse.

Re:Cool - a Windows 7 Mobile Server?!

[silverglade00]

Maybe for firmware updates and troubleshooting by Casio tech support?

OK

[Anonymous Coward]

I assume this is in response to the $200 Intel Atom based servers out there now.

I'm already using an ARM based server in the home.

[gmarsh]

I have a Marvell openrd-client. This thing has the guts of a Sheevaplug except it comes in a fancier case, uses a separate wall wart, has onboard video, more peripherals and a spot for a 2.5" hard drive inside.

I've got a 500GB 5400rpm hard drive poked inside and Debian Linux installed, and it acts as a file server, music server, torrent downloader, etc. Pulls about 8 watts from the wall, though I've got video disabled, second ethernet disabled, etc. Couldn't be happier with the thing.

Linux for the win, even if Microsoft plays

[IGnatius T Foobar]

As the cost of energy continues to rise (due to purely political reasons rather than any actual scarcity, which is sad) there's going to be more and more demand for computing equipment with low power consumption. ARM fits that requirement nicely ... and it's all going to be running Linux, even if Microsoft enters the game.

Why?

Windows running on ARM would suffer from the same (imho perceived) problem that desktop Linux on x86 has: it wouldn't be able to run Windows x86 binaries. In fact, for Microsoft it would actually be worse because they'd have to deal with irate customers who thought they'd be able to pop in that CD and install some application they already own.

Linux has been playing this one well by establishing a large base of open source software that can be built on any platform. Combine this with your favorite APT or YUM repository and what do you get? The equivalent of an "app store" which is something the world is now quite familiar with. Linux for the win!/p?

Re:Fairy Tale: ARMs Race Against x86

[the_womble]

They also usually license designs rather than just ideas.

The architecture licences (to Intel and others) may be exceptions.

I must be missing something

[jjohn]

Wikipedia says that ARM's are 32-bit RISC processors from the stone age used in many mobile and embedded devices. Why on earth are these attractive for modern servers?

Even if you could get a thousand of these CPUs in one box and the energy consumption is less than a comparable Intel/AMD system, these are seemingly less capable processors.

Re:I must be missing something

[Ant P.]

Why on earth are these attractive for modern servers?

Because you would be able to run a server room without 20 tons of cooling equipment and the associated costs.

Re:I must be missing something

[CAIMLAS]

Even with marginal CPU capability and a 1-4GB RAM limitation, there are many places which could make use of a single-point system which is low heat, low power, and low cost. If the thing has onboard SSL processing built in, it'd be a huge plus.

I can think of about a dozen systems that I manage which I could replace with ARM boards tomorrow to immediate benefit, provided they've got 4GB of RAM and sufficient interfaces (SATA, Eth). Yes, I'd have to rebuild the systems, but it's a fairly inconsequential process.

Re:I must be missing something

[Rockoon]

Step back and look at your argument.

In the case of "single-point" setups that could be served by low capability cpu's with a low ram ceiling, is there anything that ARM solves that needs to be solved?

Certainly heat isnt a problem in this scenario on Intel? ..and power?

We can't talk about cost so much because we have no idea what the price point for multi-core Arm's will be, but Intel certainly hasnt created a price barrier on its Atom's.

Re:I must be missing something

[bluefoxlucid]

Because a 600MHz ARM processor boots Debian and runs GNOME about half as fast as a 3GHz single core.

Re:I must be missing something

[Anonymous Coward]

Heat and power are issues on these systems. Why?

Because they make, and use, a lot of them relational to the actual work being done. Even with fairly high airflow, you're going to have heat issues - and moving parts. Those moving parts are killers, whether they're fans or disks. Solid state stuff will live indefinitely they're fairly well made and have clean power. The added power to the system, regardless of how much heat it uses, is also a systemic strain: higher quality parts (capacitors, etc.) are not only good to have but necessary to handle the higher wattage required. A (conservative) 220 watt ceiling for two systems vs. the same for 10 systems is a no brainer in that regard.

So, the argument isn't completely against x86 intel or for ARM, because fans can be used or not used on either platform (if you're including Atom), but ARM certainly has a big "win" in not needing those at all in most cases.

Atoms are another alternative, of course, but there has been nothing on the market yet which is cost competitive with a full-on "real" server.

Re:I must be missing something

[jon3k]

Why not replace them with a (or pair, for redundancy) machine and virtualize them? Are they not physically close to one another or something?

This is all messed up!

[cpscotti]

And will they run OS X? with fancy faboi(ish) desktop effects!!

What's next? iPhones for as industry machinery controllers?

I'm off!

4 GB of DRAM ought to be enough for anybody

[DrDitto]

ARM currently supports 4 GB of memory since the ISA is 32-bits. Full 64-bit addessing support is years away. Interim "PAE" extensions will be just as ugly and unused as the x86 PAE.

Re:4 GB of DRAM ought to be enough for anybody

[adrianmsmith]

Yes !! I don't get why this isn't mentioned more ... 4GB will not be enough for desktop computers pretty soon, and certainly isn't enough for servers.

Re:4 GB of DRAM ought to be enough for anybody

[Nursie]

What do you do with your server?

Server doesn't necessarily mean "super-beefy computer in the back room", it can mean "file server for a small office" or "part of a web-serving cluster".

Neither of these (nor a lot of other server activities) require either masses of memory or ultra-fast cpu. In many cases it's far better to reduce the power usage.

Re:4 GB of DRAM ought to be enough for anybody

[Anonymous Coward]

Yeah, they don't need an ultra-fast CPU; the multi-core CPUs are just for the aesthetics of it and to avoid bad feng-shui. LOL

(Seriously, did you even bother to RTFA? Whoever modded you up obviously didn't.)

Re:4 GB of DRAM ought to be enough for anybody

[cynyr]

I'm not sure anyone one is saying that ARM will replace Intel/AMD on the 300TB DB Servers, but it stands to make inroads into the "mail archiver", SMB NAS, home server, and other lower performance, markets. Also if you are limited not in terms of single threaded CPU performance, but simply running enough threads, i could see something like a cluster of ARMs beating Intel/AMD per watt (if ARM can get on board with the faster interconnects).

Re:4 GB of DRAM ought to be enough for anybody

[adrianmsmith]

True, but the summary was talking about Google and Microsoft.

And things always get larger so even if 4GB isn't a problem now it might be pretty soon. For example our (front-end) web servers has 512MB in 2003 but now the smallest we have is 2GB and I reckon 512MB wouldn't be enough any more (although I couldn't say off the top of my head why).

Although 2GB < 4GB, who knows what will be standard in 10 years.

Re:4 GB of DRAM ought to be enough for anybody

[kwalker]

How do you figure? "PAE" is so easy as to be a "gimmie" outside of the Windows world. And the company I work for just finished virtualizing almost 70 servers, only 10 of which are rigged for more than 4GB of RAM.

Re:4 GB of DRAM ought to be enough for anybody

[Anonymous Coward]

32-bit virtual addresses are only an issue if you need more than 4GiB for a single process. The size of the physical address space only matters to the kernel's memory-management code.

If there's a demand for systems with more than 4GiB of physical RAM, then it will happen. One of the ARM's strong points is that there's a competitive market: you can get ARM-based chips from over a dozzen different manufacturers. The owners of the ARM "IP" don't care what extensions the individual manufacturers add so long as they're paying royalties.

Re:4 GB of DRAM ought to be enough for anybody

[Hurricane78]

Well, add more cores with their own memory. ^^

Re:4 GB of DRAM ought to be enough for anybody

[soppsa]

Sorry it doesn't quite work that way. I'm not sure you understand how SMP works. Your ^^ smiley indicates to me that you like anime and Japan though, so kudos for being so cute and clever!

Re:Fairy Tale: ARMs Race Against x86

[Sleepy]

You misunderstand - just know that words have multiple meanings. No, really - it's true. (rolls eyes).

OK, ARM is "twice" David:
1) for being a challenger to the biggest chipmaker, Intel
2) because ARM is RISC... and RISC has always been a niche or vertical application part challenging the dominant CISC designs (Intel, AMD).

Re:Fairy Tale: ARMs Race Against x86

[sznupi]

Thing is, quite cheap and rather small laptops based on Intel CULV chips showed up recently; some of them certainly can do 10h, perhaps there are some with 12h. And they are fast, if needed.

On top of that, if I look at announcements of ARM netbooks - even though they will be purposely quite limited machines, it doesn't appear like manufacturers want a price reflecting that. Certainly not as long as there's not much competition yet, as long as they can offer it as a "premium" machine. Which has a big chance of killing them altogether...

Re:Fairy Tale: ARMs Race Against x86

[Zoxed]

> Israel? I thought that was where the current Intel Architecture was designed?

Although my post did not mention it I was thinking of where it was *invented*. AFAIK the 8086 was created by Intel in the USA. But I could be wrong :-(

Re:Fairy Tale: ARMs Race Against x86

[EponymousCustard]

Goliath was just a big bloke. David had the God of the universe on his side.

disappointed, while thrilled...

[CAIMLAS]

I'm a bit disappointed that this is coming to pass, as it was a venture project I wanted to possibly get into at some point. I saw the potential, but obviously someone else did, too...

Thus, I might be able to have ARM servers. That excites me. Thermal and power issues at the data center have always been an issue, as I'm sure they have for everyone.

And realistically, many (if not most) systems don't need the power of a multicore Xeon server. I've got older P4 era infrastructure systems which barely even see a 10% load on most days: something like a multicore ARM board with 1GHz cores would be more than enough to handle what these systems do, and those racks would no longer have the heat or power management issues.

What's more, we might start seeing 1/2 rack wide 1U systems. In-chassis system redundancy on a 1U, anyone?

Very exciting.

QNAP as NAS Arm server

[Alastair]

I'm already running an Arm based server. It's called a QNAP NAS and the TS419P runs a Marvell Feroceon CPU "Feroceon 88FR131 rev 1 (v5l)" (cpuinfo).

It's running Debian Lenny (2.6.30-2-kirkwood) and thanks go to the Debian Arm team and Martin Michlmayr. Runs great.

Alastair

Re:QNAP as NAS Arm server

[Nursie]

I too would like to thank Martyn.

I used to run two NSLU2s, now I have a sheevaplug. His work enabled me to turn them all into debian boxes.

How is the QNAP stuff? What's the core speed/RAM?
Was toying with buying one but they were expensive compared to sheeva. Of course you have to get the disk caddy extra for the plug.

Re:Fairy Tale: ARMs Race Against x86

[jedidiah]

> Goliath was just a big bloke. David had the God of the universe on his side.

That and some well aimed bullets.

Where's the Smart Book?

[Anonymous Coward]

Still waiting for my ARM based Linux running smart book.

Pure Politics? Not so.

[Anonymous Coward]

Going off on a tangent here: The energy scarcity isn't purely due to political reasons.

I live in Alberta, Canada, the land of low-hanging energy fruit (although not as low and as plentiful as the middle-east). We've pumped the easy oil & gas and have moved on to the harder stuff (ie. tar sands, heavier bitumen products, tight natural gas, etc.). We have had exactly two local political factors in our oil production history: The National Oil Program scare in the 70s and the recent move to increase taxation of Alberta oil and gas production. If you actually look at the production figures, it is very hard to see any impact from these two events. The middle-east's over production that caused the oil crises in 1973 and 1979 had a far larger impact, but the recent US real estate bubble's affect was fairly minor and short-lived. Again, I'm talking about production figures here. Our local economy definitely took huge hits from all of these events, but production soldiered on.

I've watched oil & gas fields through discovery, development, decline, and closure. Politics rarely factors in. In all honesty, price hasn't been much of a factor either. Mostly, this is because Alberta's energy resources have been profitable despite price or politics. The major factor has been the presence of resources. If it's there, we extract it and sell it.

The problem is we're running out of the easy to extract resources. So the margins are shrinking and politics is becoming a factor. As time goes on, politics will play more and more of a roll, but it will only do so because we are extracting resources with less luster.

OW MY BRAIN HURT

[GameboyRMH]

Commas: They're free and eco-friendly, try using more.

Linux, and one other....

[SuperKendall]

ARM fits that requirement nicely ... and it's all going to be running Linux, even if Microsoft enters the game.

Your reasoning is interesting but you forget there is one other major OS vendor that runs on ARM TODAY.

And unlike Microsoft, has well over 100k binaries for the ARM platform.

And over 3000 applications specifically devoted to a larger form factor.

I think you know who.

Re:Fairy Tale: ARMs Race Against x86

[Anonymous Coward]

I wish that people would stop making technical arguments about facts by substituting opinions. Reality doesn't bend to your will. Please educate yourself a little bit. It's not that you're so wrong it hurts, it's that you're subtly wrong and someone might take you seriously.

Re:I'm already using an ARM based server in the ho

[Anonymous Coward]

I have a Marvell openrd-client. This thing has the guts of a Sheevaplug except it comes in a fancier case, uses a separate wall wart, has onboard video, more peripherals and a spot for a 2.5" hard drive inside.

I've got a 500GB 5400rpm hard drive poked inside and Debian Linux installed, and it acts as a file server, music server, torrent downloader, etc. Pulls about 8 watts from the wall, though I've got video disabled, second ethernet disabled, etc. Couldn't be happier with the thing.

Where did you buy your OpenRD-Client? The online vendor I found wants "partnerships" with its customers and seems set up to sell these by the pallet and not onesy-twosey. I do not want a relationship, just a seller of the darned computer. Thanks!

Bullshit

[Erich]

No 64 bit architecture now... I'll bet anyone they won't have any 64 bit products by 2011.

I guess you could stick a Coretex A9 in a box and call it a server, just like you can stick an Atom in a box and call it a server. At least the atom would support large address spaces.

Remember MS' forays onto other architectures?

[pwinkeler]

Remember Windows on:
  Dec Alpha
  Intel Itanium
I wouldn't trust Windows running on anything other than Intel x86 for a long time - there is just too much crappy code there that never even could handle byte-order.

Not to mention that from a sysadmin perspective the notion of servers with differing binary architectures are a nightmare unless you have an executable file format that can hide these details. So we're talking something like CMU's mach-o, as used on Macs. Here I would like to recall the fun days when Sun claimed it had a multi-architecture solution when all they did was create NFS mountpoints with embedded environment variables that expanded based on the mounting system's native architecture.

There needs to be some serious fundamental re-architecting in that OS before it's ready to run on more than architecture.

Re:Remember MS' forays onto other architectures?

[shutdown -p now]

Remember Windows on:
    Dec Alpha
    Intel Itanium

Yes; it worked. What about it?

there is just too much crappy code there that never even could handle byte-order.

... which isn't a problem with ARM, anyway.

Not to mention that from a sysadmin perspective the notion of servers with differing binary architectures are a nightmare unless you have an executable file format that can hide these details.

What would having such a format change for admins?

There needs to be some serious fundamental re-architecting in that OS before it's ready to run on more than architecture.

NT has historically ran on more than one architecture - indeed, it started as a non-x86 OS - so this is demonstrably false. Of course, it would also help if you'd be more specific about what "fundamental re-architecturing" you believe is needed, and why.

Re:Remember MS' forays onto other architectures?

[cynyr]

I would expect any of the server software that MS says works on ARM to work on ARM (would be a PR disaster otherwise). Now a lot of 3rd party addons to that stuff will not work. Linux on the otherhand will work just fine ARM, as well as many others. At least for the server software end (firefox/chomium, Gnome, etc may not work well)

Re:I'm already using an ARM based server in the ho

[gmarsh]

Mine came from Nu Horizons, an electronic component distributor - http://www.nuhorizons.com/ - part # is 003-RD0004.

They're out of stock, but they seem to allow qty. 1 orders with a 2 week manufacturer lead time - you can try ordering one and see what happens.

However looking at Globalscale's site, it looks like they've now depreciated the openrd-client and openrd-base, and now have the "openrd-ultimate" which has a PCIe slot sticking out of it where the SD card slot used to be, and a MicroSD slot added by the audio connectors. Nu Horizons might sell that instead, but I can't find it.

Re:Fairy Tale: ARMs Race Against x86

[vjoel]

Thing is, quite cheap and rather small laptops based on Intel CULV chips showed up recently; some of them certainly can do 10h, perhaps there are some with 12h. And they are fast, if needed.

Yup: http://www.engadget.com/2009/11/11/asus-ul80vt-review. I have a UL80vt, and get about 9-10 hours reliably (both linux and win7), and that's while running overclocked by 33%.

Re:Fairy Tale: ARMs Race Against x86

[Blakey Rat]

I favour anyone who can build and deliver a laptop with 12 hours battery live.

I would too, except ARM has consistently failed to do this for ... well years now. How long has Slashdot been talking about the mythical 20-hour ARM-powered Linux-running netbook? I'm sick of hearing about nothing but vapor from the ARM camp.

It would be nice if they stopped running these articles until the product *actually existed*.

I thought in 20 years we will still be using x86 compatible CPUs.

Well, first of all, we're not using x86 compatible CPUs right now. At least, not unless the *only* device in your home is a PC-- all the game consoles released right now aren't using x86, for example.

Secondly, the reason that x86 is good at beating rivals is that it, generally speaking, can adopt the advantages of the rivals without losing compatibility. That's pretty much exactly what happened with PPC.

Re:Fairy Tale: ARMs Race Against x86

[RightSaidFred99]

Nonsense. The number of people in the software world who have to deal with x86's idiosyncrasies is tiny. OS and compiler developers, some driver developers, a handful of other functions. For the rest of us it doesn't matter and x86 has proven it's able to keep its performance up with any other architecture (watch what happens to IBM's POWER over the next 5 years if you don't believe me) at a lower price.

Re:Fairy Tale: ARMs Race Against x86

[shutdown -p now]

If we're still going to depend on x68 in 20 years I'd rather kill myself by banging my head against an x86 chip.

FYI, self-immolation is rather painful. ~

small servers

[DaveGod]

Instead ARM may limit its options to the print and storage server market.

THG may well be on the money there. I don't do much IT but I do know small business (working as an accountant). Loads of small businesses require one performance server to run their main productivity server and everything else is printing and storage. It's the same at our practice: we have 3 big servers, one of which is choked for performance in every way while for the others the CPU is almost idle while the bottleneck is something else.

Even if all you want is a lot of hard drive space for a lot of people to share, you end up having to get a server that has expensive-everything just so you get the fast storage etc. We have basically a server that cost a ton of money to basically be a NAS box. Saving some money on that to spend it on the one that needs everything it can get would be pretty good for productivity. Sure there are options out there, but they're not really available to small businesses who basically have to buy off the shelf gear that their IT contractor can support.

From there ARM can look at moving in on home servers, if they ever get going. I still think there's potential for a "media centre" server that is mostly about connectivity and content storage (rather than pushing actual video about), think a souped-up router with hard drives and some functionality software.

ARMy Ants?

[metaforest]

Seems like this might lead to a higher density computational framework.
How about some computational LEGO bricks?

We know from Apple's example(s) that a functional system will fit into a very small form factor, and
consume minimal power, even while running flat-out.

IIRC: The iPod Touch G3 is running a 600MHz A8 can run flat-out for 3 - 6 hours on
~1200mAH (~4.44W) battery without getting particularly warm. (unlike a MacBook(pro))
I could see a 4 - 8 watt budget being reasonable for a complete 1 - 2 GHz ARM server-brick,
with 4GB of memory and a 80GB FLASH drive in the chassis. SDHC/MMC for kernel image and app storage?

With a reasonable "brick" design it should be possible to stack a lot of these systems
into a very compact space and add a few channels of GigE or, 4-way-LVDS links,
with GigE bridges at the edges of the array. Power would also be provided at the edges
of the array.

With a decent cabinet design clusters could be convection cooled.
Cost per unit might be spectacularly low if the input power is 3.7 - 12 VDC.

If the brick-to-brick mesh interconnect is fast enough, who cares if the local storage is limited to 32b addresses?

2.5" or 3.5" form factor?

Need more mass storage? Notice that modern hard-drives don't have full size controller boards anymore?
Put the computational unit in the other half of the drive-controller foot-print.

Now.... how are ya gonna program this? IMO: The compiler geeks need to get off their collective duffs and
figure out a C-like language that parallelizes well... without shared memory. Maybe something similar to XMOS XC?
   

Can it run Java / .Net?

[GWBasic]

Can ARM run Java / .Net / CLI / mono? Will JIT-ing Java or .Net result in comparable performance? I always thought that part of Microsoft's strategy for .Net was to allow their programs to run on computers with different instruction sets?

Re:Fairy Tale: ARMs Race Against x86

[evilviper]

ARM is David. x86 is Goliath.

IBM is Goliath. x86 is David. ARM is David's annoying little brother, angry at not being in the spot-light, and insisting he can do everything better than David....

I'm voting for x86. It's the only architecture with two suppliers (no, Via doesn't count), and has continued to advance consistently for decades. It's only very recently that it has pushed mainframes off their pedestal thanks to clustering and virtualization technologies, and only in the past few months has it started making waves at the very high end, with (just a few) RAS features FINALLY being integrated.

ARM is all hype, playing fast and loose with specs to pretend they're competitive anywhere else outside their niche. Frankly, I'd say they have more money than they know what to do with, and are trying longshot after longshot to fight back against x86, as it starts impeding on their market.

Re:I'm already using an ARM based server in the ho

[evilviper]

Pulls about 8 watts from the wall, though I've got video disabled, second ethernet disabled, etc. Couldn't be happier with the thing.

I've got a K6-3 550 underclocked and undervolted, drawing 8 watts from the wall. Cost me $20 for CPU+mobo. PSU, case, and HDD (flash) were would probably put the total price around $60 if I didn't have it all lying around... Been my firewall/router for years now. Couldn't be happier.