1 Dry Number Look at SBC Speeds

Every computer has things it does better, and things it does worse. Handling integer math, floating point math, moving bytes ( I/O speed ) or doing character manipulation. So it goes. Old IBM 360 machines were actually slow processors, but had several high speed data channels to disk. IBM realized that the typical business transaction moved a large record, but only did math on one or a few fields. The old Cray did a block of 64 double precision math problems with one instruction, but was not so good at “scalar” problems or moving long records of bits. So trying to compare computers based on just one performance number is a bit daft.

You really MUST characterize the problem you are solving and then match that to the kind of computer prior to doing comparisons.

But I’m going to ignore that and look at Just One Number. The Dhrystone benchmark performance.

https://en.wikipedia.org/wiki/Dhrystone

Dhrystone is a synthetic computing benchmark program developed in 1984 by Reinhold P. Weicker intended to be representative of system (integer) programming. The Dhrystone grew to become representative of general processor (CPU) performance. The name “Dhrystone” is a pun on a different benchmark algorithm called Whetstone.

With Dhrystone, Weicker gathered meta-data from a broad range of software, including programs written in FORTRAN, PL/1, SAL, ALGOL 68, and Pascal. He then characterized these programs in terms of various common constructs: procedure calls, pointer indirections, assignments, etc. From this he wrote the Dhrystone benchmark to correspond to a representative mix. Dhrystone was published in Ada, with the C version for Unix developed by Rick Richardson (“version 1.1”) greatly contributing to its popularity.

It isn’t ideal, but it’s good enough for most things and widely used. For a more complete set of benchmarks of many sorts, you can go wandering in the open benchmark site here:

http://openbenchmarking.org/

Basically, what I’m going to do is look almost entirely at just those boards which have a tested production release of Devuan available. If folks don’t care about SystemD, then many more boards have a native Debian or Ubuntu port and the same exercise can be done for them. For now, for this look, I’m starting with the Devuan native boards. (IFF I don’t find anything I like, I can expand the search later).

These are all ARM CPU boards, and mostly all v7 or v8 instruction sets ( 32 bit armhf or 64bit arm64 ). But it isn’t just a 2 way split. Not all cores are created equal per MHz of clock.

A couple of decades back, many or most of these ‘tricks’ were reserved for high end CISC machines (Complex Instruction Set Computer). Now they are showing up in what is nominally a RISC (Reduced Instruction Set Computer) like the ARM. How many instructions can be decoded in parallel? How are the instructions “pipelined” so the next one is started while the last one isn’t done yet? Is hardware floating point fast, faster, 64 bit, 32 bit, or missing? Can a path be executed, then thrown away if not taken by a later test function? So all cores, even of what is nominally the same instruction set and architecture are not created equal. This page gives a rough Dhrystone factor for the various ARM chips along with some details about things like decode width, pipeline, Floating Point Unit (FPU) and out of order execution. At the far right is a “DMIPS/MHz” factor.

https://en.wikipedia.org/wiki/Comparison_of_ARM_cores

What I’m going to do is look up the chipset for each board, the CPU type, and the MHz, then “do the math”, for each of a bunch of boards that have a native Devuan available for download. I’m getting the chip set and MHz information from here:

https://en.wikipedia.org/wiki/Comparison_of_single-board_computers

The list of supported boards is from the Devuan site readme here:

https://files.devuan.org/devuan_jessie/embedded/README.txt

I’m leaving out the Chromebooks as I’m not looking for a laptop right now, similarly the Allwinner Tablet was skipped, and skipping the Nokia phone. I’ve also skipped the “Lomobo R1″just because I’ve never heard of it… and the CubieTruck using the A83T was not in the comparison wiki. Note that many of these boards use the Allwinner A10 or A20 chips, so not that many distinct comparisons to make, really. Though other boards use the same H3 or Samsung chips with different MHz so some variations creep back in.

Currently supported images:

* Acer Chromebook (chromeacer)
* Veyron/Rockchip Chromebook (chromeveyron)
* Nokia N900 (n900)
* Odroid XU (odroidxu)
* Raspberry Pi 0 and 1 (raspi1)
* Raspberry Pi 2 and 3 (raspi2)
* Raspberry Pi 3 64bit (raspi3)

Allwinner boards with mainline U-Boot and mainline Linux can be booted
using the sunxi image, and flashing the according u-boot blob found in
the u-boot directory here. The filenames are board-specific, but this
file is commonly known as “u-boot-sunxi-with-spl.bin”.

Currently supported Allwinner boards:

* Olimex OLinuXino Lime (A10)
* Olimex OLinuXino Lime (A20)
* Olimex OLinuXino Lime2 (A20)
* Olimex OLinuXino MICRO (A20)
* Banana Pi (A20)
* Banana Pro (A20)
* CHIP (R8)
* CHIP Pro (GR8)
* Cubieboard (A10)
* Cubieboard2 (A20)
* Cubietruck (A20)
* Cubieboard4 (A80)
* Cubietruck Plus (A83t)
* Lamobo R1 (A20)
* OrangePi2 (H3)
* OrangePi Lite (H3)
* OrangePi Plus (H3)
* OrangePi Zero (H2+)
* OrangePi (A20)
* OrangePi Mini (A20)
* Allwinner-based q8 touchscreen tablet (A33)

All the A10 use the same MHz as do all the A20, so only one line of data for each. The general layout of the comparison is “chip set”, core count and architecture type, scaling factor (Dhst/MHz), then a relative performance number for that core type at that MHz, and a total for all the cores on the chip set. Finally, a list of the boards using that chip set to make figuring out who’s a A20 easier…

The Rel. Perf. is good for comparing how fast a monolithic task completes in one core (like some browser tasks). It tends to indicate how the board feels in terms of response in use. The Total is better for indicating how much gets done on long fully loaded tasks like running models or doing BOINC. The A15 cores have a range of relative performance from 3.5 to 4. I’ve just used 4 in the posting to keep the chart manageable.

Chip # x Type MHz   Scale  Rel   Total  Boards
Set                 Factor Perf  Rel Perf
             
A10  1   A8   1000  2      2000   2000   Olimex Lime, CubieBoard    
A20  2   A7   1000  1.9    1900   3800   Olimex Lime2, Olimex Micro, Banana Pi & Pro, CubieBoard 2, CubieTruck, Orange Pi & Mini
A80  4   A15  1300  4      5200  20800   CubieBoard4
     4   A7   1300  1.9    2470   9880
                                 30680 total for A80
H3   4   A7   1536  1.9    2918  11672   Orange Pi 2 & Plus
H3   4   A7   1200  1.9    2280   9120   Orange Pi One & Lite
H2   4   A7   1200  1.9    2280   9120   Orange Pi Zero
R8   1   A8   1000  2      2000   2000   C.H.I.P.
Broadcom - Raspberry Pi
2835 1 ARM11   700  1.25    875    875   R.Pi B+
2836 4   A7    900  1.9    1710   6840   R.Pi M2
2837 4   A8   1200  2.3    2760  11040   R.Pi M3
Samsung 
5410 4   A15  1700  4      6800  27200   Odroid XU
     4   A7   1200  1.9    2280   9120
                                 36320 total for Samsung 5410

Not Running Devuan 1.0 native, but via Armbian "Uplift":
Amlogic
905  4   A53  1500  2.3    3450  13800   Odroid C2
805  4   A5   1500  1.57   2355   9420   Odroid C1+
Samsung
5422 4   A15  2000  4      8000  32000   Odroid XU4
     4   A7   1400  1.9    2660  10640
                                 42640 total for Samsung 5422

Now there you can see in one number just why that Odroid XU4 spent so much time doing nothing and was very crisp on web pages and such. The octo core chips are just monsters. More than 3 x the speed of the C2, and single core performance at about 3 x a Pi M3 core. To find some other board like it, running fairly nicely, well, that’s going to be hard, or expensive, or both.

Still, all I need is “fast enough” really. Given the Pi M3 on editing WordPress pages (lots of bytes sent back and forth and a bit of typeahead), I’m likely to need something closer to 3000 or 4000 single core speed. That’s mostly CubieBoards and Odroids. (Or I give up on Devuan or accept an x86 or make some other compromise with my principles).

This is the same reason I bought it and the C2 in the first place. Oh Well.

In Conclusion

I suspect I mostly just need to do my “postmortem” as planned and then work on getting some code working rather than worry about building more “stuff”. I’ve got enough rig for the early stages of work and I can easily use something else as my “daily driver”. But “when the time comes”, knowing how many DMarks / $$$ you get for any given board is going to be a key number. Then those Dhrystones get divided by Dollars and you have yet another very interesting number. All of which needs leavening with things like “Float vs Integer” performance and “can I use the GPU?” along with “Can I get out all the heat at full load 24 x 7?” (so “effective Dhrystones over hours…) and “Is the I/O fast enough to keep the CPUs fed?”…

But that is how you evaluate the “buy” decision on buying more computes. How much do the computes cost, how many can you get done before the machine breaks or becomes obsolete, how much work to keep it up and running right. This is just a first rough cut number, but it lets you rapidly dump some options as “uninteresting”.

Subscribe to feed

Advertisements
Posted in Tech Bits | Tagged , , , , , , | Leave a comment

Odroid Failure

From the “Well that’s a Pisser” department…

A few days back the Odroid C2 didn’t want to boot. Just sat there with a fast blinking red power light.

Despite being pretty sure I had the right chip in it, I figured it was most likely just the wrong chip in for some other CPU type. So it went into the box where systems live when not on the desktop.

Then I spent a couple of days rearranging the cluster and the desktop et. al. Using the XU4 as the power machine on the desktop when I wanted speed.

Just a couple of hours ago I shut down to swap the XU4 and Pi M3 between monitors. In the process also swapping keyboards and what power strip the power supply used.

On boot up, the Pi M3 worked Just Fine. The XU4, however, gave a red power light but refused to give a blinking CPU heartbeat (or even a blue light at all). OK… Maybe the SD card is corrupted or “something”…

So I took a couple of hours for diagnostic work. Took brand new 16 GB Sandisk mini-SD cards and wrote pristine images from the manufacturer “known to work” to each and once again tried to boot both cards. Both continued to act the same.

He’s Dead Jim

At this point I’m pretty sure both are dead cards. I get NOTHING on the monitor with either monitor, either kb/mouse, etc. etc.

Possible causes? I thought about static discharge. But the C2 is in the manufacturers case and ought to be OK. Plus, it’s been humid and raining when it first failed to boot.

The Odroid XU4 was “loose”, so has higher static risk. I have a towel over the desktop as cotton is generally a safe material. It stopped raining 2 days ago, but it still isn’t what I’d call dry and static laden air.

Ground loop? The two power strips on the desktop are plugged into 2 different things. One is straight wall power and the other is a UPS into the same socket. I *think* the wall socket has power and neutral reversed, but it’s a ground fault interrupter socket so nothing too big can happen. Might there have been some volts on the grounds between the power brick ground and the monitor ground? Maybe. Yet it has never bothered any system until now, including prior uses of the Odroids.

There’s a potential for physical fragility. The XU4 was working, shutdown, and monitor cables swapped. Pulling out the old one took some pull, and the board / heatsink flexed a little. Did something crack? These things are built on very thin cards, could it just be the thicker material of the Pi cards? Or better device attachment?

Who knows.

What I do know is I can’t get either one to indicate any attempt to boot with multiple different OS cards and monitors. Not even showing up on the router as a network presence.

It looks to me like they are just not very robust to handling / use.

OK, disappointed. Minor loss of money value. Some annoyance as my fastest SBC isn’t available for use or to drive video. All easily fixed with about a $50 new board buy and waiting 3 days…

But will it be replacement Odroids? A major reason for buying them was just to asses their use in a cluster or as a desktop. That’s done now. The C2 has a 64 bit instruction set that makes using it a bit harder as the arm64 code is still a bit young, so buggier than the armhf. The XU4 has a strange mix of 8 cores in 2 different types, so the scheduler is a bit odd, job completion times depend on what core type it gets assigned to first (as it never changes type after that), and it runs hot. Neither one a real candidate for a large cluster going forward given my OS of choice as Devuan.

Now add to that the fact that the Pi B+ laid loose on my desktop for a few years, went to Florida and back a couple of times, and never failed. The 2 x Pi M2 boards had similar lives. In and out of single cases. Into the dogbone case. Power plugged in anywhere. Run headless, or headfull, or having a monitor plugged and unplugged “whenever” and are still doing fine. The Pi M3 has been my “go to board” for all sorts of tests and changes and has been loose on the desk as often as in a case. Heck, even the Orange Pi has been loose laying on the desktop or draped over the Dogbone Stack loose since I bought it. Regularly handled while powered up. ALL of them having zero “issues” from my handling practices and power systems.

So what to do…

I think I’ll set both of them aside for a few days to “clear the attitude”, then do One Last Test of booting before giving up on them and just harvesting the heat sinks.

I’m also going to move up doing a search of the Devuan `1.0 release build boards. I’m leaning toward any of: Cubie / Banana Pi / Orange Pi. Need to look at cores, power, heat, performance, etc. etc. given that now I know what to look for.

I’d expected to lose a board or 2 during the cluster burn-in as I’m running them 100% to the wall 24 x 7 and the heat management on small SBCs is generally “not good”. What I didn’t expect was to have boards NOT in the cluster be the ones doing the dying…

So, needless to say, I’m not looking fondly at more Odroids…

Buying a replacement will have to wait a while. I’ve already blown my “mad money” for the month on the TV, and next month is Christmas so that money is going to others. Figure sometime next year I’ll have to know what to replace them with. Until then, I’m going to route the TV monitor cable over to the Odroid C1 and use it for videos. That will also let me check on its robustness to use and ability to provide a high enough frame rate. It is in the Dogbone Case and plugged into the common power strip used for everything but the standard desktops. That’s a small UPS plugged into a bigger one in the wall. The idea being that the big one in the wall gives me time to shut down anything non-essential and then the DNS / File server infrastructure stuff gets a longer run in case I’m out of the house when power fails.

So we’ll see if a 3rd one blows when the HDMI cable goes to a monitor plugged directly into the wall…

So, ok, the purpose was to assess the boards. They’ve now served that purpose. Moving on…

Subscribe to feed

Posted in Tech Bits | Tagged , , , , , | 11 Comments

The Worricker Trilogy

A remarkably good Spy Story from PBS / Masterpiece.

http://www.imdb.com/title/tt6451170/

The IMDB doesn’t say much. Then again, for a Spy Mystery you really don’t want to say much or you are spewing spoilers…

A British intelligence analyst with MI5 has to work out why the PM had his best boss and best friend killed.

It leaves so much important laying on the ground… First off, this is a series of 3 movies. The “blurb” under the title on Amazon says:

David Hare’s thrilling spy trilogy exposes the battles raging inside the intelligence community in the name of security. The Worricker stories include: Page Eight; Salting the Battlefield; and Turks Caicos.

Not a whole lot better, but you begin to get the sense of it.

First off, this is a British Story with British Actors. It starts off so low key and slow most Americans will have fallen asleep or gone for coffee. But, to quote someone… KBO.. “Keep Buggering On” and it picks up speed. Somewhere along the line I picked up from Mum the love of a slow building mystery in the British style. Also a sensitivity to the low key way a raised eyebrow, nod (or lack of a nod), and even a terse “I see.” can carry more than a paragraph. This is in that style. Not to be watched with senses chemically dulled, nor when multitasking with the phone or tablet. Put them down and pay attention. Those dry details in passing are going to matter later. Keep track of Colonel Mustard is hiding!

The story manages to mix a realistic romance (with issues…) along with the kinds of twists and turns any real life spy drama is likely to have. Guessing which side who is on? How about guessing which side YOU are on in what you are doing… Of course, there are several twists, turns and plot reversals. Wouldn’t be right without them. There are shifting allegiances, entrapments, “turned” agents, and more.

What make it special for me? Aside from just a much more realistic portrayal of spycraft, the main spy is a 60 something, so a demographic I can relate to. No 30 something guy shooting up anything that moves, this is an old crafty guy working the system, even while it threatens to kill him. The other interesting bit is that the plot reflects some things hinted at in our news and worries… the potential for intelligence agencies to forget who is the boss and think governments are theirs to manage…

The acting is superb. So much said with just a subdued smile, a raised eyebrow, a slump or a tightening of the shoulders.

Hopefully I’ve not given away too much of the plot. Go find it. Watch it. Think about the news and nations.

I found it on Amazon (free as part of the Prime package that we only bought for shipping costs). It is likely in other places as well.

Subscribe to feed

Posted in Arts, Movies & Media | Tagged , | 2 Comments

BOINC-ing A Cluster

Got a little bit tired of having a stack of cores not doing anything. Now that it’s all configured as I like it, open a panel on each, and pop up an “htop” display. A nice load bar for each core. 16 of them just sitting there near or at zero…

Couldn’t stand the waste… so spent some time looking at how to set up a code running OpenCL on the GPUs. Found a recipe for doing it on the Odroid. It’s not easy, and filled with “issues”. Climate Models not ready to run yet (still digging though all the knobs to set…)

So I decided to go ahead and put “BOINC” on the cluster. At least it would be doing something worthwhile (sort of ;-) and I’d get my burn-in / acceptance test out of the way. Nothing like running a stack of cores at 100% for a few days to find out if it’s going to crash in the middle of a model run… or something else you care about.

https://boinc.berkeley.edu

Open-source software for volunteer computing

Use the idle time on your computer (Windows, Mac, Linux, or Android) to cure diseases, study global warming, discover pulsars, and do many other types of scientific research. It’s safe, secure, and easy:

For Android devices, get the BOINC app from the Google Play Store; for Kindle, get it from the Amazon App Store.

You can choose to support projects such as Einstein@Home, IBM World Community Grid, and SETI@home, among many others. If you run several projects, try an account manager such as GridRepublic or BAM! .

I’ve run SETI @ Home, on and off, since sometime in the 80s. (Still no aliens, though… dang it.) It was the first one of these distributed things to make a splash. Then they generalized the process and you can now use the BOINC framework to run any of many different projects.

Not all of them run on an ARM chip, though. Interesting to note that now some of the PC oriented ones also will run in the GPUs on those boxes.

I just semi-randomly signed up for 3 projects. SETI @ Home, an Enigma crack (seems someone has 3 old Enigma encrypted messages from W.W.II that have never been decoded, so they are going for a crack of it), and an Asteroids program that is using known astro-data to fully describe all the asteroids they can (rotation etc.) At some point I ought to find out just what all works on the ARM chips and settle on those I think have the most benefit. For now it was just “what runs and looks at all fun?”.

Installing the application is trivial. It’s in the Debian build already. On the headless boards, do “apt-get install boinc-client”. On the master / headend station, do that and do “apt-get install boinc-manager”

https://boinc.berkeley.edu/wiki/Installing_BOINC_on_Debian

But then there’s some configuration bits to do… I’ve bolded the bit that was annoying for me:

If you do only the basic installation as described above, BOINC manager will not be able to automatically connect to the client. To connect the client you will be required to give the GUI RPC password every time you start BOINC manager. That is not a bug, it is a security feature to prevent other users from using the manager to manipulate the client, changing your projects, etc. Another inconvenience is that boinc (the user named boinc) owns /var/lib/boinc-client/ and all the files and directories in it so you will not be able to edit those files from your regular user account unless you add your username to the boinc group and adjust some permissions as follows, substituting your username for :

Open /etc/group in a text editor.
Look for the line starting with boinc:x::
Edit the line to look like boinc:x:: ( will be a number, do not change it)
Save the file and close the editor.
Open a terminal and enter the following commands, substitude your username for :
sudo ln -s /etc/boinc-client/gui_rpc_auth.cfg /home//gui_rpc_auth.cfg
sudo ln -s /etc/boinc-client/gui_rpc_auth.cfg /var/lib/boinc-client/gui_rpc_auth.cfg
sudo chown boinc:boinc /home//gui_rpc_auth.cfg
sudo chown boinc:boinc /var/lib/boinc-client/gui_rpc_auth.cfg
sudo chmod g+rw /var/lib/boinc-client
sudo chmod g+rw /var/lib/boinc-client/*.*

So I read that, and proceeded to rote do the commands listed, but missed the importance of it. There are files in that directory that must be changed.

The other “quirk” was that the BOINC manager lets you change what machine your are managing with a dropdown menu choice of changing computers, but then it prompts for “computer name” and “password”. Who’s password? On what machine?

So I tried my login name password. Nothing. I tried the boinc account. I changed the boinc account password (as I’d never set it so what was it?) and still no go. Eventually I found out that it has it’s own ‘special’ password. It also has a magic file where you must put the IP number of any managing workstation on each of the client headless boards.

https://boinc.berkeley.edu/wiki/Controlling_BOINC_remotely

Access control for GUI RPC

GUI RPCs are divided into two categories:

Status operations which return information about tasks, project, etc.
Control operations which change the state of BOINC (suspend/resume, add project, etc.).

Some GUI RPCs are authenticated with a GUI RPC password. This is stored in the file gui_rpc_auth.cfg in the BOINC data directory. On a multiuser computer, this should be protected against access by other users. When BOINC client first runs, it generates a random password. You can change it if you like; max length is 255 characters.

Local access

A “local” RPC is one that comes from the computer where the BOINC client is running (but perhaps from a different logged-in user).

Local status RPCs are not authenticated. On a multiuser computer, a user can see the status of any other user’s BOINC client.

Local control RPCs are authenticated using the GUI RPC password.

Remote access

A “remote” RPC is one that comes from a different computer.

All remote RPCs (both status and control) are authenticated using the GUI RPC password.

By default, remote RPCs are not accepted from any host. To specify a set of hosts from which RPCs are allowed, create a file remote_hosts.cfg in your BOINC data directory containing a list of allowed DNS host names
or IP addresses (one per line). Only these hosts will be able to connect. The remote_hosts.cfg file can also have comment lines that start with either a # or a ; character.

Now despite what it said, there was no default password in that .cfg file. So in fact, I had to just not put ANY password into the prompt to connect to another node. Just the computer name. HOWEVER, until the IP number of the management station was put in the remote_hosts.cfg file on the headless nodes, it would not allow the connection…

Once It Works

Then you get to add “projects”. These want an email account and a new password for the project login on the web page. Then you get the software for that project loaded and it starts.

The Management Station lets you allocate how many cores, and what percentage of CPU, and what times of day, and… lots of other controls. The tasks for a given project run niced to very low priority, so generally get out of the way of other use; but on a Pi if it is also your desktop, you will want to limit the use to 50% or 75% of cores, just so you don’t have to wait for a swap when starting to do something.

So as of now, I’ve got 16 cores running full boogie on BOINC. I’ll be leaving the cluster running this way for a day or two, then asses things like stability and core temperatures. Also actual work done.

For now I’m just happy to see all the CPU load bars up there at near 100% showing something is being done ;-)

Subscribe to feed

Posted in Tech Bits | Tagged , , , | 6 Comments