Re: cheap 8-core ARM board

[Christian Baer <christian.baer%uni-dortmund.de@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/23/16 21:11, Reinoud Zandijk wrote:

Mello greetings, everyone!

> Really laptops with MIPS CPUs? Haven't seen one come by yet but
> maybe I wasn't looking hard enough :)

Oh yeah, believe you me! :-)

https://en.wikipedia.org/wiki/Lemote#Netbook_computers

The development seems to have stalled a bit there, although Loongson
is at least down to a 28nm process und thus can clock up to 1500MHz.
I've always wanted to get myself one of these things - just for kicks.
:-) But they are very hard to get in the western world, because they
were mainly made for the Chinese market.

> My biggest problem with the ARM boards that are generally available
> is that the CPU is OK but the memory bandwidth is just not up to
> spec. Esp. with the PI1 and the PI2 (dont know about the PI3) the
> CPU can do a fair amount but don't try to crunch data with it since
> its 16 bit databus cripples the entire beast. Manipulating local
> data goes fast but as soon as you start processing larger things it
> just slows down tremendously. I should compare my PI board with
> both linux and NetBSD to see if it matters much; then we can
> exclude the pmap stuff.

These boards were designed primarily to be cheap - and a lot of
compromises were accepted to keep the prices down. At the smae time, I
think it's pretty amazing what the 2nd and 3rd generation of PI get
done. Using a GUI on a PI1 was not fun at all. You could write mail
and news with user agents like Mutt, tin or slrn. I once signed and
encrypted an email with a 10MB attachment on a PI1. Won't be doing
that again any time soon. :-) But even on a PI2, running something
like Claws is fine. It's not at snappy as the Xeon in my workstation,
but it's perfectly ok to work with.

Because of the memory bandwidth issue you mentioned, I never quite got
why people started making clusters with PIs. The usual reason "because
we can" just didn't cut it for me. Sure, the computer looked good on
paper (in terms of FLOPS), but in practice, the memory bandwidth makes
these things a waste of money - because the cost were still a couple
of thousand dollars. Just my two cents on the matter...

> My current NAS, a LG Marvell board has the same performance
> problem. Next to this the amount of `system time` it eats when
> streaming data to/from its SATA over the gb network port is
> appalling. Sometimes in the 30-50% and you get a few mb/sec max.

That is the exact reason why I have never owned a NAS. Most of them
are used as data archives or as backup systems. But because the data
is sensitive, the data is to be encrypted. Some have encryption chips
which increase performance, but these are often not compatible to
anything (including themselves somehow). And quite often, the CPU is
so weak that and operation maxes it out nearly completely.

A friend of mine tried to work around this issue by connecting his NAS
via iSCSI and doing the encryption locally. As long as only one person
wants access to the NAS and the Firmware of the NAS is current, that
will work - sorta. But the CPU is working quite heavily and the whole
thing seems slow at any rate. My alternative (real computer with ECC
RAM, CPU with AES instruction set, FreeBSD, ZFS and geli) is much
faster, much more flexible and has cause way less headaches in the past.

> So yes, 8 cores might look fine but if they share a common 16 bit
> databus to DRAM, then thanks but no thanks. There are board like
> the NVidea (Tegra?) board that are exceptions on the rule but even
> then its max 32 bits wide AFAIR.

When we start talking Tegra, we start talking about different price
ranges too. Even a TK1 board (which is two years old now and has been
superseded), is still being sold for well over 100 bucks - and
requires active cooling. This is a little like apples and oranges.

Take care!
Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iL4EAREKAGYFAlg2zapfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldDgzRDQzNjY2NUYzMDVBMTYxMDY0ODYwNzMy
MDIxMzQyODdFMUJGQjIACgkQMgITQofhv7J8OAEA1f9/9dpqhjmDi4p6a0opvBu6
vThkzgrgHQKhaVUtvwEA/jMfRxAmyDsk8xNZyyQWRb5THIIMAhEOuHhUc+kOe+GP
=2Wjw
-----END PGP SIGNATURE-----