SBC CPU Throughput

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?

Is it OK if I change the thread title to "SBC benchmarks" this late in the day?  It's never been specific to BBB anyway (it started with Pi) and Minnowboard takes the measurements beyond ARM.  The more general title fits better with E14's topic hierarchy too.

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.

Cubieboard2 A20, seems to run at 912MHz rather than the stated 1GHz, distro is the 217Mb Linux3.3 sdcard image from http://cubieboard.org/download/ the tooltip on that page suggests it's ubuntu but /etc/debian_version suggests it's Debian 7.1

# time echo "scale=2000;4*a(1)" | bc -l

15.328s

Also tried the simplistic hard drive sequential read test with "hdparm -tT /dev/sda", same drive as I've used previously on SL and Minnow. Reasonably surprised to see it deliver 98MB/s

I added your figure of 15.328s and your observed clock speed to the table, but I wish I understood the reason for that slow compute speed better.  On the positive side, that's great SATA performance.  I'm not surprised that it's a bit less than on Minnowboard's x86 Atom, but at least it's getting there.

probably worth making the distinction on the table between the other A10 cubieboard result and the A20.  A8 vs A7 arm core is bound to have some effect.

On the compute speed side, if you remember I saw quite a difference on SL from the stock debian armhf compiled version of bc compared to the optimised one compiled for angstrom.  I'm going to try the angstrom version on the cubieboard and see if there's some similar improvement available.

Posted some other stuff on the cubie2 in another thread.  Was considering a Cubie vs RPi (or BBB) thread, but I still have nightmares about the last one I started like that

Good point about the Cubieboard SoC varying.  I've added a "SoC" column to the table to capture that info.

selsinork wrote:

 

Posted some other stuff on the cubie2 in another thread.  Was considering a Cubie vs RPi (or BBB) thread, but I still have nightmares about the last one I started like that

Haha.

Well this thread is only about benchmarking and/or performance, so a separate thread about Cubieboard in the SBC "non-group" sounds like a good idea to me.  It would be more focused and it would leave my other thread to deal mainly with the OLinuXino series of boards, which is quite a large topic by itself.  A separate thread would ensure that Cubieboard information doesn't get lost under a non-applicable thread title.

Very interesting info getting submerged and lost is my main issue about discussions here.  I think tech needs more attention to permanence and logical access than cat pictures in social networking.

To avoid "the nightmares",  maybe something generic like "vs other boards" or similar will stop anyone getting protective about their current precious.

On the compute speed side, if you remember I saw quite a difference on SL from the stock debian armhf compiled version of bc compared to the optimised one compiled for angstrom.  I'm going to try the angstrom version on the cubieboard and see if there's some similar improvement available.

Ok, so using the BBB/angstrom version of bc the result changes to 12.752s or an improvement of ~2.5s

I have another idea about putting a copy of the BBB angstrom into a chroot on the cubie and see if there's anything else to be gained. Don't have space on the sd card for that, so I'm going to try it on some spinning rust. Not really sure what effect that'll have, but it may have some due to faster loading of libraries.

Do you want me to add that to the table attributed to Angstrom, or would that be questionable mixing of variables since the bc is only a transplant?