Intel Atom: pros/cons/hazzards?

Hi,

I've rescued a couple of Atom-based SBC's.  Essentially
diskless workstations.

Am I correct in assuming these are just "yet-another-x86"?

Are there any downsides/upsides/problems to watch for
when porting desktop OS's/apps to these sorts of boards?
Or, just treat it like any other x86 (686?) for all
practical purposes?

Should I accept *more* of them?  (within reason)  Or, are
they just "ho-hum" (dust collectors)?

(Boxes in question are 1.6GHz, <4G DDR2, with all the
typical "PC" I/O's)

Thx,
--don

On 9/17/2014 3:46 AM, Don Y wrote:
> Hi,
>
> I've rescued a couple of Atom-based SBC's.  Essentially
> diskless workstations.
>
> Am I correct in assuming these are just "yet-another-x86"?
>
> Are there any downsides/upsides/problems to watch for
> when porting desktop OS's/apps to these sorts of boards?
> Or, just treat it like any other x86 (686?) for all
> practical purposes?
>
> Should I accept *more* of them?  (within reason)  Or, are
> they just "ho-hum" (dust collectors)?
>
> (Boxes in question are 1.6GHz, <4G DDR2, with all the
> typical "PC" I/O's)

They are essentially netbook class computers.  Atoms have been used 
extensively in netbooks.  I have one that is dog slow running Win7. 
Browsers especially are hard to use on them.  If you have 4 GB that 
would help a lot, mine only has 1 GB.  You seem to be saying yours have 
less than 4 GB... still 2 is better than 1.

I wouldn't mind having one for a workbench computer to run basic stuff 
like a serial port terminal.  But I think you get them for a non-profit 
and can't share even for a price.

-- 

Rick

In sci.electronics.design Don Y <this@is.not.me.com> wrote:
> Am I correct in assuming these are just "yet-another-x86"?

Mostly.  I think they are really a RISC CPU that pretends to be an x86
to the outside world.  Intel learned from Itanic... yay backward
compatibility! [0]

> Are there any downsides/upsides/problems to watch for when porting
> desktop OS's/apps to these sorts of boards?

At the time I was playing with a few of these (about 3-4 years ago), I
was using Linux, and it was pretty much just "boot and go"; most of the
onboard peripherals were standard enough that they just came up and
worked.  You could then run regular Linux apps (including X).

The exception was the video drivers.  Out of the box, it wasn't any
problem getting a text console and the "old standard" VGA modes, like
640x480, 800x600, 1024x768, and so on.  If you wanted to run the
graphics at full capability, though, you sometimes needed a driver from
Intel or the SBC manufacturer, and you would run into the usual problem,
which is that their unspecified "Linux driver" depended on a particular
kernel version down to the ninth decimal place.  I suspect as time
marches on, more Linux distributions now ship with suitable drivers.
But you still may need to "goose" the kernel with a boot-time command
line option to get it to do the right thing.

If I remember right, some of the SBC vendors said you could use a
relatively huge heatsink (a few inches on a side) and no fan.  Most of
them advised at least a small fan.

Upside: you don't have to use 12 gauge wires to power it.  :)

> Should I accept *more* of them?  (within reason)

They might be good for media PCs, although I don't know if they can do
full HD or not.  If you have applications that you'd like to dedicate a
PC to, like packet radio, weather station support, home automation, or
stuff like that, they'd be good for that - low power and either zero or
one fans.

Matt Roberds

[0] On the other hand, when they are hooking me up to the machines in
    the hospital 50 years from now, I fully expect one of them to
    project "NO ROM BASIC, SYSTEM HALTED" as a hologram, if the quantum
    storage isn't plugged in at boot time.

On 9/17/2014 1:21 AM, mroberds@att.net wrote:
> In sci.electronics.design Don Y <this@is.not.me.com> wrote:
>> Am I correct in assuming these are just "yet-another-x86"?
>
> Mostly.  I think they are really a RISC CPU that pretends to be an x86
> to the outside world.  Intel learned from Itanic... yay backward
> compatibility! [0]

Understood.  But, still execute IA instruction set, etc.?
(perhaps different opcode timings, no FPU?, etc.)

>> Are there any downsides/upsides/problems to watch for when porting
>> desktop OS's/apps to these sorts of boards?
>
> At the time I was playing with a few of these (about 3-4 years ago), I
> was using Linux, and it was pretty much just "boot and go"; most of the
> onboard peripherals were standard enough that they just came up and
> worked.  You could then run regular Linux apps (including X).
>
> The exception was the video drivers.  Out of the box, it wasn't any
> problem getting a text console and the "old standard" VGA modes, like
> 640x480, 800x600, 1024x768, and so on.  If you wanted to run the
> graphics at full capability, though, you sometimes needed a driver from
> Intel or the SBC manufacturer, and you would run into the usual problem,
> which is that their unspecified "Linux driver" depended on a particular
> kernel version down to the ninth decimal place.

Exactly.  So much for "open" software!  :>

> I suspect as time
> marches on, more Linux distributions now ship with suitable drivers.
> But you still may need to "goose" the kernel with a boot-time command
> line option to get it to do the right thing.

I'm not interested in them as graphic workstations.
Rather, I would like to use them to replace some of the
dedicated machines that I have here.  E.g., RDBMS server,
audio server, etc.  In those roles, I would be happy with
a text console (assuming I can't telnet/xdm to the device).

And, as "generic" SBC's that I can use in lieu of custom
hardware to prototype some of my algorithms (currently using
1GHz/1GB similar SBC's... though the old ones are probably
twice the size, physically, and require an external "brick").
In these roles, no console is necessary (having one would just
be overhead as I don't need "video" in those devices)

> If I remember right, some of the SBC vendors said you could use a
> relatively huge heatsink (a few inches on a side) and no fan.  Most of
> them advised at least a small fan.

These have no fan but a cooling pipe to a remote radiator.

> Upside: you don't have to use 12 gauge wires to power it.  :)
>
>> Should I accept *more* of them?  (within reason)
>
> They might be good for media PCs, although I don't know if they can do
> full HD or not.  If you have applications that you'd like to dedicate a
> PC to, like packet radio, weather station support, home automation, or
> stuff like that, they'd be good for that - low power and either zero or
> one fans.

Exactly.  See above.  I've been tentatively targeting ARM at
a few hundred MHz (for the system being prototyped) and figure
these are roughly the same ballpark ("a small integer factor")
given differences in the efficiency of the instruction set,
I/O's, etc.

> [0] On the other hand, when they are hooking me up to the machines in
>      the hospital 50 years from now, I fully expect one of them to
>      project "NO ROM BASIC, SYSTEM HALTED" as a hologram, if the quantum
>      storage isn't plugged in at boot time.

No doubt Bill Gates dressed as Max Headroom!

On 17/09/14 11:00, Don Y wrote:
> On 9/17/2014 1:21 AM, mroberds@att.net wrote:
>> In sci.electronics.design Don Y <this@is.not.me.com> wrote:
>>> Am I correct in assuming these are just "yet-another-x86"?
>>
>> Mostly.  I think they are really a RISC CPU that pretends to be an x86
>> to the outside world.  Intel learned from Itanic... yay backward
>> compatibility! [0]
> 
> Understood.  But, still execute IA instruction set, etc.?
> (perhaps different opcode timings, no FPU?, etc.)

Yes.

All fast, modern CISC CPUs are implemented as a sort of RISC CPU and a
x86-to-internal-RISC translator.  The details of the RISC CPU itself
will vary wildly between implementations, and they are invisible to the
outside (other than timings) - so you ignore them and treat the chip as
a "native" x86 cpu.

Atom chips, AFAIK, all have FPUs - but things like the SSE instruction
support will vary from device to device, just as it does on big x86 cpus.

In short, your original assumption - these are just "yet another x86"
devices - was correct.

> 
>>> Are there any downsides/upsides/problems to watch for when porting
>>> desktop OS's/apps to these sorts of boards?
>>
>> At the time I was playing with a few of these (about 3-4 years ago), I
>> was using Linux, and it was pretty much just "boot and go"; most of the
>> onboard peripherals were standard enough that they just came up and
>> worked.  You could then run regular Linux apps (including X).
>>
>> The exception was the video drivers.  Out of the box, it wasn't any
>> problem getting a text console and the "old standard" VGA modes, like
>> 640x480, 800x600, 1024x768, and so on.  If you wanted to run the
>> graphics at full capability, though, you sometimes needed a driver from
>> Intel or the SBC manufacturer, and you would run into the usual problem,
>> which is that their unspecified "Linux driver" depended on a particular
>> kernel version down to the ninth decimal place.
> 
> Exactly.  So much for "open" software!  :>

Intel used to be difficult regarding its openness around its graphics
chips.  These days it is much better.  Use a modern kernel, and you'll
/probably/ have no problems.

> 
>> I suspect as time
>> marches on, more Linux distributions now ship with suitable drivers.
>> But you still may need to "goose" the kernel with a boot-time command
>> line option to get it to do the right thing.
> 
> I'm not interested in them as graphic workstations.
> Rather, I would like to use them to replace some of the
> dedicated machines that I have here.  E.g., RDBMS server,
> audio server, etc.  In those roles, I would be happy with
> a text console (assuming I can't telnet/xdm to the device).

Should be fine - and once you've got the initial installation in place,
ssh is usually the best way in (it has several advantages over telnet,
even if you are not concerned about security).

> 
> And, as "generic" SBC's that I can use in lieu of custom
> hardware to prototype some of my algorithms (currently using
> 1GHz/1GB similar SBC's... though the old ones are probably
> twice the size, physically, and require an external "brick").
> In these roles, no console is necessary (having one would just
> be overhead as I don't need "video" in those devices)
> 
>> If I remember right, some of the SBC vendors said you could use a
>> relatively huge heatsink (a few inches on a side) and no fan.  Most of
>> them advised at least a small fan.
> 
> These have no fan but a cooling pipe to a remote radiator.
> 
>> Upside: you don't have to use 12 gauge wires to power it.  :)
>>
>>> Should I accept *more* of them?  (within reason)
>>
>> They might be good for media PCs, although I don't know if they can do
>> full HD or not.  If you have applications that you'd like to dedicate a
>> PC to, like packet radio, weather station support, home automation, or
>> stuff like that, they'd be good for that - low power and either zero or
>> one fans.
> 
> Exactly.  See above.  I've been tentatively targeting ARM at
> a few hundred MHz (for the system being prototyped) and figure
> these are roughly the same ballpark ("a small integer factor")
> given differences in the efficiency of the instruction set,
> I/O's, etc.

Expect more processing power per MHz than an ARM chip, but more
variation in latency on I/O.  Apart from that, an Atom SBC sounds fine
for you use.

> 
>> [0] On the other hand, when they are hooking me up to the machines in
>>      the hospital 50 years from now, I fully expect one of them to
>>      project "NO ROM BASIC, SYSTEM HALTED" as a hologram, if the quantum
>>      storage isn't plugged in at boot time.
> 
> No doubt Bill Gates dressed as Max Headroom!

On Wed, 17 Sep 2014 13:08:11 +0200 David Brown <david.brown@hesbynett.no>
wrote in Message id: <lvbq2s$39h$1@dont-email.me>:

[...]

>Intel used to be difficult regarding its openness around its graphics
>chips.  These days it is much better.  Use a modern kernel, and you'll
>/probably/ have no problems.

That was when IP in the Atom chips GPU was held by PowerVR. Thankfully,
Intel dumped them and went to their own graphics processor.

Avoid any of the Atoms that utilize PowerVR GPUs. They suck on video
performance for the most part, anyway.
http://en.wikipedia.org/wiki/Atom_%28system_on_chip%29

Graphics performance is quite good on the latest iteration of the Atom
platform, code named Baytrail.

On Wednesday, September 17, 2014 1:21:35 AM UTC-7, mrob...@att.net wrote:
> In sci.electronics.design Don Y <this@is.not.me.com> wrote:
> 
> > Am I correct in assuming these are just "yet-another-x86"?
> 
> Mostly.  I think they are really a RISC CPU that pretends to be an x86 to the outside world.  Intel learned from Itanic... yay backward compatibility! [0]
> 
> > Are there any downsides/upsides/problems to watch for when porting desktop OS's/apps to these sorts of boards? 
> 
> At the time I was playing with a few of these (about 3-4 years ago), I was using Linux, and it was pretty much just "boot and go"; most of the onboard peripherals were standard enough that they just came up and worked.  You could then run regular Linux apps (including X).

My HP Atom laptop was built 5 years ago. It has Nivida ION graphic core build-in. It plays full HD video and mp4 well.

> The exception was the video drivers.  Out of the box, it wasn't any problem getting a text console and the "old standard" VGA modes, like 640x480, 800x600, 1024x768, and so on.  If you wanted to run the graphics at full capability, though, you sometimes needed a driver from Intel or the SBC manufacturer, and you would run into the usual problem, which is that their unspecified "Linux driver" depended on a particular

No, it works out of the box from standard kernel 3.14 and 3.15.

> kernel version down to the ninth decimal place.  I suspect as time marches on, more Linux distributions now ship with suitable drivers. But you still may need to "goose" the kernel with a boot-time command line option to get it to do the right thing.

No, you don't.

On 2014-09-17, mroberds@att.net <mroberds@att.net> wrote:
> In sci.electronics.design Don Y <this@is.not.me.com> wrote:
>> Am I correct in assuming these are just "yet-another-x86"?
>
> Mostly.  I think they are really a RISC CPU that pretends to be an x86
> to the outside world.

Yep.  That's exactly how Intel's x86 CPUs have been built for ages.

-- 
Grant Edwards               grant.b.edwards        Yow! Was my SOY LOAF left
                                  at               out in th'RAIN?  It tastes
                              gmail.com            REAL GOOD!!

> I've rescued a couple of Atom-based SBC's.  Essentially
> diskless workstations.
>
> Am I correct in assuming these are just "yet-another-x86"?

Basically so (taking into account that the "x86" family includes a
huge range of architectural implementations and performances.)

Think "Pentium, with most of the newer instruction set additions such
as MMX/SSE, but without hardware virtualization support, scaled down
to a small and relatively lower-power silicon process, with only
modest amounts of on-chip cache."

>> Are there any downsides/upsides/problems to watch for
>> when porting desktop OS's/apps to these sorts of boards?
>> Or, just treat it like any other x86 (686?) for all
>> practical purposes?

They usually come with on-chip graphics support (so you don't need a
separate graphics card) using a shared-memory implementation.  The
older ones generally have graphics performance in the "meh"
class... fine for server-console use, but sluggish for modern desktop
use (e.g. they often don't have multi-plane compositing).  If you pick
your desktop environment properly, though, and turn off a lot of the
fancy "desktop/window visual effects" eye-candy nonsense, they can be
quite usable.

Some of the newer Atoms are designed for home-theatre PC applications,
and have much faster graphics (often with on-chip video decompression
support).

I've been using a small Atom-based motherboard as my home's firewall,
web server, domain name-server, DHCP server, and mail server for
several years.  It works just fine in that application, and the fact
that the CPU runs fine without a fan is a definite win.  I can do
CD-quality audio capture on it (from a turntable and an external ADC
board, into a S/PDIF digital input) while it's doing everything else,
and it never misses a beat.

On Wed, 17 Sep 2014 00:46:51 -0700, Don Y <this@is.not.me.com> Gave us:

>Hi,
>
>I've rescued a couple of Atom-based SBC's.  Essentially
>diskless workstations.
>
>Am I correct in assuming these are just "yet-another-x86"?
>
>Are there any downsides/upsides/problems to watch for
>when porting desktop OS's/apps to these sorts of boards?
>Or, just treat it like any other x86 (686?) for all
>practical purposes?
>
>Should I accept *more* of them?  (within reason)  Or, are
>they just "ho-hum" (dust collectors)?
>
>(Boxes in question are 1.6GHz, <4G DDR2, with all the
>typical "PC" I/O's)
>
>Thx,
>--don


  If they are the new Atoms, they are made to replace Xeons in single
task network server applications.

  Even the old ones are nice.  Yes they are fully x86-64 compliant IIRC.

  All of mine run various Windows OSes.  I have 2 Acer Aspire Nettops
and use them as HTPCs.

  Collect those things you have...  sell a few, and buy an established
consumer product.  Though I do not know if the Atom is still being
incorporated into these mini PC form factors any more.

  AMD and ARM and others are weighing in.  I have a cubox-i4Pro ARM
processed 'box', which literally is a tiny box.

http://www.solid-run.com/product/cubox-i4pro/