SBC CPU Throughput

minnowboard,  Intel(R) Atom(TM) CPU E640   @ 1.00GHz, production-Angstrom-development-GNOME-image-eglibc-ipk-v2012.12-minnow-2013.07.10.img

bc-1.06.95 compiled from source on the minnowboard itself as the version of bc included with angstrom segfaults whenever the -l mathlibrary switch is used.

21 seconds

selsinork wrote:

 

21 seconds

That's interesting, as an initial data point for Atom E640 here.  Probably no surprise given the results of various review sites when comparing Atom (not sure which SoC) versus Cortex-A15 in tablets and chromebooks.

It's just the start of the inquiry though, and I bet the numbers will vary a lot as the platform libraries and optimizations change.  I'd like to see what the Minnowboard forums have to say about it too.  It's still very early days.  More specifically, I'd like to hear whether this initial measurement seems reasonable to them given the instruction set, clock speed, and memory + cache performance.

I'll pop it into the table, but let me know if you decide it wasn't actually representative and needs changing.

I think it's going to be reasonable, as a comparison a different system with an Atom 230 @ 1.6Ghz does it in about 14 seconds in 32 bit mode.

However, historically Atom processors were better in 64 bit mode and the same system with the same version of bc, manages it in 9.3 seconds in 64 bit mode.

Pity then that the E640 is apparently 32 bit only.  Interestingly, when looking at /proc/cpuinfo on the minnow it includes 'lm' which would suggest 64 bit may be possible and I'll try that out at some point too.

Regardless, it seems clear that for this particular benchmark the Minnowboard doesn't do well against it's competition and would seem unlikely to be competitive even in 64 bit mode.

So price/performance comparisons are a legitimate target along with performance per watt, is there really a killer feature that makes the minnowboard worth it ?   I'm not so sure..

selsinork wrote:

 

So price/performance comparisons are a legitimate target along with performance per watt, is there really a killer feature that makes the minnowboard worth it ?   I'm not so sure..

I/O bandwidth perhaps?  With SATA and gigabit Ethernet, it seems likely that Minnowboard would perform well in I/O-limited applications like NAS and also in web services, as long as the web service is not a CPU-intensive one.

Measurements of network, USB, [u]SD, SATA and PCIe latencies and throughputs could be useful when matching boards to applications.

Morgaine Dinova wrote:

 

Measurements of network, USB, [u]SD, SATA and PCIe latencies and throughputs could be useful when matching boards to applications.

Ok, so SATA was next on my list anyway. 

Simplistic sustained sequential read testing showed the SL capable of about 25MB/s from a drive that's theoretically capable of 120MB/s, the same drive and test on the Minnow shows about 110MB/s.

Read from uSD approx 17MB/s with the current card.

selsinork wrote:

 

Simplistic sustained sequential read testing showed the SL capable of about 25MB/s from a drive that's theoretically capable of 120MB/s, the same drive and test on the Minnow shows about 110MB/s.

That sounds very good on the Minnow, and seems inline with normal PC technology which has been delivering good I/O for decades.  It wouldn't surprise me to find that ARM has some catching up to do in this area.

In the spirit of the lightweight CPU benchmark, it would be nice to have a standard one-liner to deliver an estimate of maximum storage read and write bandwidth, one that is inherently immune to Linux disk caching in memory.  How have you been obtaining your figures?

Morgaine Dinova wrote:

 

How have you been obtaining your figures?

Remember I did say they were simplistic tests....

Two ways

hdparm -tT /dev/sda

or

dd if=/dev/sda of=/dev/null bs=1M count=10000 iflag=direct

in the second one, iflag=direct should sidestep any caching, but if not then making bs * count several times larger than available ram gives a similar effect.  The numbers tend to be very similar anyway.

As usual, you can't read a thing into the numbers produced as we're ignoring files, filesystems and everything else deliberately to get a rough idea of raw throughput over the sata cable and not much more.

The funny thing is that the drive I'm using is a recent 2.5" drive with an operating power of 1.6W (on paper, haven't measured it yet) which doesn't compare well to the Minnow at approx 7W.

selsinork wrote:

 

Ok, so SATA was next on my list anyway. 

 

Simplistic sustained sequential read testing showed the SL capable of about 25MB/s from a drive that's theoretically capable of 120MB/s, the same drive and test on the Minnow shows about 110MB/s.

Ok, so this is more about Sabre-Lite than BBB...   I've been spending some time getting 3.12 kernels up and running on my BBB and Sabre-Lite and interestingly have discovered that with this kernel the Sabre-Lite is now able to beat the Minnow for simple sequential disk read tests with 117MB/s.  The original SL kernel was 3.0.35-mangled-by-timesys-no-source-or-config-available,  the one I'm using is referenced in this Boundary Devices blog post  http://boundarydevices.com/mx6-main-line-linux-kernel/

Moral of the story ?  First thing you should do when buying any of these embedded boards is to ditch every piece of software that comes with it and start fresh.

Oh, and the BBB 3.12 kernel can be found here https://github.com/beagleboard/linux/tree/3.12 some details and issues discussed here https://groups.google.com/forum/#!msg/beagleboard/n914vncfPd8/ktY9NHY6SAYJ biggest of which seems to be that cape support is lacking for now

This is excellent!  With CPU, network and storage throughput measured, the major building blocks are covered.

Since you're the only person to have measured SATA throughput so far (I don't have a non-x86 board with SATA yet), how about starting off an "SBC Storage Throughput" thread, or something like that?  (Not sure whether flash and USB storage are best covered together with SATA or not.)

As you noted, our measurements haven't been limited to BBB, so I'll rename this thread to "SBC CPU Throughout" to match the "SBC Network Throughput" one.  (I did ask earlier whether anyone objected to the change, but nobody did.)

Morgaine.

PS. Thread renaming done.

This is excellent!  With CPU, network and storage throughput measured, the major building blocks are covered.

Since you're the only person to have measured SATA throughput so far (I don't have a non-x86 board with SATA yet), how about starting off an "SBC Storage Throughput" thread, or something like that?  (Not sure whether flash and USB storage are best covered together with SATA or not.)

As you noted, our measurements haven't been limited to BBB, so I'll rename this thread to "SBC CPU Throughout" to match the "SBC Network Throughput" one.  (I did ask earlier whether anyone objected to the change, but nobody did.)

Morgaine.

PS. Thread renaming done.

Hmm.. not sure I want to go there just yet.  SATA performance is reasonably simple to do as it's relatively uncomplicated to compare sequential read from a drives datasheet to a simplistic test. That'll easily show up problems like the SLs poor performance with old kernels.  However, as you say, we only have a tiny sample of SATA results to look at so far and they're all from me, so verification of results by someone else would be needed.

SD on the other hand is an absolute minefield, manufacturers claims are usually outrageously ridiculous and unverifiable. Combine that with meaningless 'class X' numbers that take no account that the actual signaling mode required to reach the speed can't be used by your SBC due to lack of voltage switching or similar and it gets messy very quickly. 

Unfortunately not a lot of people understand enough about the intricacies of SDcards vs hardware vs drivers capabilities to get much in the way of worthwhile results.

Just to illustrate the point,  there was a post in the RPI group here a week or so back urging people to ditch class 10 cards as they're 'difficult to setup' and yet I ended up with the most recent kernel update rendering the class 4/6 cards unuseable and the class 10 being the only one that works! Help - R Pi Errors Boot Failing :-(