To some extent this is a “marker post”. I’ll be adding bits to it as I unpack and try out my New Toys.
For now it’s just saying that I’ve received them. What are they? They 3 SBCs that I ordered from Ameridroid with the Tip Jar. This makes somewhere around 7 or 8 things I’ve ordered from them. Every one is lower in price than Amazon, arrives a bit faster than the “slow shipping” choice claims, and has been “exactly right”. It probably helps that I’m in the same State as they are; but still: They do a good job of doing exactly what they say they will do without any negative surprises.
So what did I get?
Rock64 – smaller than I expected
Physically about the size of an Orange Pi One, but with a lot more computes inside. 8.5 x 5.6 cm. That’s small!
Here’s the blurb on it:
ROCK64 Single Board Computer
$29.95 USDGreat features at a great price!
ROCK64 is a single-board computer with a footprint similar to the ODROID-C2 and Raspberry Pi 3, but with some extra cool features! In addition to a Quad-Core ARM Cortex A53 64-bit processor, USB2.0 ports, 40-pin GPIO header and microSD slot similar to the C2 and RasPi3, it also shares the following features with the C2 that are not present on the RasPi3: eMMC module socket,4K/60fps video decoding, gigabit Ethernet and IR receiver. But the real kicker is that the ROCK64 trades 2 USB2.0 ports for a USB3.0 port to provide high-speed USB access to your projects!
Additional items required to operate – see “NOT INCLUDED” section below
KEY FEATURES
Powerful Linux/Android Computer
RK3328 1.5GHz 64-bit quad-core CPU, multi-core GPU
Mali-450 MP2 GPU supporting up to 4K@60fps video decoding via VP9 or 10-bit H265/H264
User may choose between 1GB/2GB/4GB LPDDR3 RAM (selectable on purchase, memory not expandable)
10/100/1000Mbps Ethernet with RJ-45 LAN jack
2x high speed USB2.0 host ports
1x super speed USB3.0 host port
40 GPIO pins (quasi-Raspberry Pi compatible) + Pi-P5+ Bus
128Mb SPI Flash on board
3.5mm A/V Jack on board
Physical power / reset / recovery buttons
IR Receiver
Linux or Android available
Size: 85 x 56 x 18 mm, Weight: 40g
Package includes main board
IMHO it very much will need a heat sink. I didn’t order one with it as I want to test it bare first. I’ve got an Amazon ‘wish list’ up with a package of a half dozen heat sinks in it for something like $8. If it doesn’t show up by Christmas I’ll just hit the button myself. In terms of build quality and ‘feel in the hand’, so far I like it the most ;-)
In theory, this ought ot be 1.25 or so faster than the R. Pi M3 (or hopefully about enough to be just enough…) Note that it has a USB 3.0 port, so can likely be even faster with the I/O factor. Finally, I was feeling morose about the sloth of my Pi M3 on Devuan 2.0 when I remembered that the Clock was set artificially low on Raspian. Surely Devuan fixed this, no? No.
Well I changed the setting to “On Demand” and now the Devuan 2.0 is performing much better. Can you say 2 Times Better? At the advertised 1.2 MHz clock rate… It really REALLY is important to keep an eye on what the OS does to your clock settings and what kind of heat sink you have.
Now, take that double from getting back to full clock speed, multiply it by 15/12 (or 5/4) for the higher clock speed on this board, season with the fact that the Mali GPU is OpenGL friendly and it ought to be ready to rock with GPU based math, and this ought to do a great job of various math based jobs in a cluster. As we saw in a prior posting on benchmarks, with a v8 based operating system, the NEON calls really accelerate math!
At $30, it isn’t going to break the bank, either.
So after I fire it up and push it “to the wall” (and maybe a bit beyond), then, and only then, I’ll order a heat sink for it ;-)
Pine A64 – the Allwinner variation
A much larger SBC, a bit larger than the Raspberry Pi even. Slightly larger than a small USB disk. Here’s their blurb:
PINE A64
$22.95 USDThe PINE64 PINE A64 is an amazingly low-cost 64-bit single-board computer! It sports a quad-core ARM Cortex A53 64-bit processor, Mali 400 MP2 GPU, dual I/O expansion slots, HDMI 1.4a video port and 10/100 Ethernet port on the 512MB model, and 10/100/1000 Ethernet port on the 1GB model.
KEY FEATURES
Powerful Linux/Android Computer
Allwinner A64/R18 1.2GHz 64-bit quad-core CPU
Mali-400 MP2 GPU
User may choose between 512MB & 1GB DDR3 RAM
10/100/1000Mbps Ethernet with RJ-45 LAN jack on 1GB/2GB LTS models, and 10/100Mbps on 512MB model
2x high speed USB2.0 host ports
40 GPIO pins (quasi-Raspberry Pi compatible) + Euler Bus
1GB model has CSI camera port, DSI display port and touch control port
Linux or Android available
Package includes main board
Weight: 46 g
Dimensions: 127 x 79 x 21 mm
This is a $23 low cost board. I got the 1 GB version, the 512 MB board is $18. These are the “cheap seats” with zip. At 12 cm long, we’re talking a big board. Roughly 5 inches. (Remember the ancient 5 inch floppy disks? Yeah, that big.) But at $18 to $23 I’m not going to complain. No USB 3.0, so not for the Disk Server. Still it’s basically a Raspberry Pi M3 class machine for significantly less and with a Mali GPU and GigE networking. We’ll see if I can get the GPU to be a math engine or if software issue make it too much of a PITA.
RockPro64
The very high end 6 core machine with two very hot A72 cores. It’s roughly the same size a the A64 board, but a lot more computes.
This is basically a 1.5 GHz quad core A53 board with two A72 cores added onto it. All for $60. It’s a new design, and will likely have various teething problems. Still, I’m willing to “go there” and see how it does as a desktop machine (where single core performance does matter) with a proper build of a v8 64 bit OS (even if I have to build it myself). The hardware ought to rock, but the prior benchmark makes it look like they put a v7 32 bit Ubuntu on the board and hobbled it with the wrong software. We’ll see…
ROCKPro64
$59.99 USDLooking for a powerhouse of an SBC, but one that is still affordable? The ROCKPro64 is the most powerful Single Board Computer released by PINE64, powered by Rockchip’s RK3399 processor. The RK3399 is a 6-core chip with two ARM Cortex-A72 CPU cores, four Cortex-A53 cores, and Mali-T860MP4 graphics. This impressive single board computer is offered in 2GB and 4GB configurations.
Moreover, the board comes packed with features, including an USB 3.0 and USB type C with DP1.2 port, a full PCIe x4 as well as eMMC module socket. You also get a 40pin header with I2C, SPI, UARTs and GPIOs.
The board is backwards compatible with many of the existing PINE64 peripherals, including the Wifi/BT module, camera module and LCD panel. All this in the exact same model “A” dimension as the original PINE A64.
KEY FEATURES
SoC – Rockchip RK3399 Hexa-Core (dual ARM Cortex A72 and quad ARM Cortex A53) 64-Bit Processor and MALI T-860MP4 Quad-Core GPU
RAM – 2GB or 4GB LPDDR4
PCIe x4 open ended slot
eMMCmodule/microSD card storage (not included)
1x USB 3.0 type C Host with DP 1.2, 1x USB 3.0 type A Host, 2x USB 2.0 Host
Gigabit Ethernet
PI-2 GPIO Bus
1x HDMI 2.0 port, MiPi DSI interface, eDP and Touch Panel interfaces, stereo MiPi CSI interfaceRESOURCES
https://www.pine64.org/?page_id=61456
Please Note:
1. Pine64 is committed to supplying the ROCKPro64 board for at least 5 years until the year 2023.
2. The ROCKPro64 is still in early stage development cycle, so the current batch is only suitable for developers and early adopters.
I did buy the extra large heat sink for this puppy (something like $7?) as I’m certain it will be heat limiting.
What Now?
I’ll be downloading the Usual OS Build for each board and doing some general benchmarking between them (and compared to the XU4 and Pi M3). Then once I’ve worked out the details on the Gentoo build process, putting The Exact Same OS on each of them for further “head to head” runs.
I’ve likely got a couple of months of work ahead of me out of this, but I ought to have a decent idea of what is good and what is junk by the end of the week (just in case anyone is thinking Christmas ;-)
With that: Thank YOU! to all the folks who tossed some coin in the PayPal Tip Jar and made this possible. Hopefully the investment in the tip jar will return information you find worth it.
With that, I’ve got to get back to work making these things run ;-)
Update: First Benchmarks!
I’ve settled on 2 benchmarks to run. I’ve run them on the RockPro64, but can’t post captured images at the moment. I downloaded the basic OS (not a “desktop”) and tried to install LXDE on it. That turned into a bit of a goose chase, so I ran the benchmarks in a plain terminal session and wrote down the results. I’ve now downloaded the Ubuntu Desktop software, though inspecting the uSD card with gparted (intending to grow the ext4 file system) it’s all a “bag of bits”.. I’m hoping it does something trick on First Fire and turns into a system. Otherwise I’m back at a restart download uncompress etc. etc.
I also ran the benchmarks on the Odroid UX4Q (fanless). Those are the numbers I’m going to cut / past here. I ran sysbench with max prime at 20000 and max iterations at 100,000 (and it hit max iterations). Threads set to number of cores. 6 on the RockPro64 and 8 on the Odroid XU4. I also ran the “armbianmonitor -z” benchmark. I’m using the Armbian OS releases as that’s what is on the Odroid and it gives a same base of comparison. It also means I can worry about Gentoo another day.
With that:
Odroid XU4Q
First off, what kind of code are we executing?
root@odroidxu4:/# which sysbench /usr/bin/sysbench root@odroidxu4:/# file -s /usr/bin/sysbench /usr/bin/sysbench: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=664005ab6bf45166f9882338db01b59750af0447, stripped
It is 32 Bit ARM executable, so v7 instructions. But we knew that because that’s all the XU4 has. A set of 4 simple v7 CPUs and 4 A15 that are also v7 cpus, but much faster. This means that to get the 64 bit precision, sysbench will need to do multiple 32 bit operations. From the man page on sysbench:
cpu
The cpu is one of the most simple benchmarks in SysBench. In this mode each request consists in calculation of prime numbers up to a value specified by the –cpu-max-primes option. All calculations are performed using 64-bit integers.
That’s going to put all 32 bit machines in the bind of using 32 bit ints to calculate a 64 bit int.
How well did it do?
chiefio@odroidxu4:/$ bench
sysbench --num-threads=8 --test=cpu --cpu-max-prime=20000 --max-requests=100000 run
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 8
Doing CPU performance benchmark
Threads started!
Done.
Maximum prime number checked in CPU test: 20000
Test execution summary:
total time: 503.1545s
total number of events: 100000
total time taken by event execution: 4024.7536
per-request statistics:
min: 22.32ms
avg: 40.25ms
max: 82.01ms
approx. 95 percentile: 49.11ms
Threads fairness:
events (avg/stddev): 12500.0000/2254.45
execution time (avg/stddev): 503.0942/0.02
503 seconds elapsed and 4024 CPU seconds. Or about 8.3 minutes and 67 CPU minutes. For comparison, the RockPro64 had:
33 seconds elapsed and 201 CPU seconds. Or about 1/2 minute and 3.35 CPU minutes. This with no heat sink too!
Clearly if you are doing 64 bit math you want a 64 bit hardware math processor.
So I’ll need to look over some of the climate model codes I’ve got again and see if they mostly do 32 bit or 64 bit math. IIRC, it was mostly 32 bit… but I wasn’t looking all that carefully…
Next up, the Armbianmonitor test:
root@odroidxu4:/# armbianmonitor -z
Preparing benchmark. Be patient please...
7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,8 CPUs)
RAM size: 1996 MB, # CPU hardware threads: 8
RAM usage: 1701 MB, # Benchmark threads: 8
Dict Compressing | Decompressing
Speed Usage R/U Rating | Speed Usage R/U Rating
KB/s % MIPS MIPS | KB/s % MIPS MIPS
22: 5764 641 875 5607 | 88379 685 1163 7970
23: 3539 481 750 3606 | 87062 679 1172 7965
24: 4305 552 838 4628 | 85001 699 1127 7884
25: 4214 572 841 4812 | 83972 721 1095 7896
----------------------------------------------------------------
Avr: 561 826 4663 696 1139 7929
Tot: 629 983 6296
Monitoring output recorded while running the benchmark:
Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St.
16:18:50: 1100/ 600MHz 0.83 34% 1% 29% 0% 3% 0% 58.0°C 0/3
16:18:55: 600/ 600MHz 0.76 0% 0% 0% 0% 0% 0% 55.0°C 0/3
16:19:00: 2000/ 600MHz 0.70 1% 0% 0% 0% 0% 0% 66.0°C 1/3
16:19:07: 1600/1500MHz 1.36 89% 2% 87% 0% 0% 0% 83.0°C 3/3
16:19:13: 1600/1500MHz 2.46 72% 2% 69% 0% 0% 0% 81.0°C 3/3
16:19:18: 1100/1500MHz 2.42 58% 2% 56% 0% 0% 0% 70.0°C 2/3
16:19:24: 1600/1500MHz 2.87 84% 1% 82% 0% 0% 0% 85.0°C 3/3
16:19:29: 1600/1500MHz 2.96 57% 3% 54% 0% 0% 0% 83.0°C 3/3
16:19:35: 1500/1500MHz 3.36 88% 3% 84% 0% 0% 0% 84.0°C 3/3
16:19:40: 1600/ 600MHz 3.81 72% 2% 69% 0% 0% 0% 79.0°C 3/3
16:19:47: 1500/1500MHz 3.59 64% 1% 62% 0% 0% 0% 86.0°C 3/3
16:19:52: 2000/ 600MHz 3.94 58% 0% 58% 0% 0% 0% 83.0°C 3/3
16:19:58: 1500/1500MHz 3.71 81% 5% 75% 0% 0% 0% 83.0°C 3/3
16:20:03: 1400/1500MHz 4.29 87% 3% 83% 0% 0% 0% 84.0°C 3/3
Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St.
16:20:08: 1400/1500MHz 4.50 90% 2% 87% 0% 0% 0% 84.0°C 3/3
16:20:13: 1500/1500MHz 4.78 92% 2% 90% 0% 0% 0% 85.0°C 3/3
16:20:18: 1700/ 600MHz 4.72 59% 2% 57% 0% 0% 0% 82.0°C 3/3
16:20:24: 1800/ 600MHz 4.58 23% 1% 22% 0% 0% 0% 78.0°C 3/3
16:20:30: 1400/1500MHz 4.86 98% 2% 96% 0% 0% 0% 87.0°C 3/3
Particularly interesting to me is that this one, if run as root, tells you what your core temperatures are doing. Here we can see the A15 cores sometimes hitting 2 GHz, but frequently heat limiting back down to 1400-1600 MHz. I suspect the model with the fan would do better here ;-) FWIW, it doesn’t take much air movement to help. In a different test I just fanned the thing with an Airstream Sales Brochure and dropped the temp down to 79 C. Very modest air flow.
This test does not always fully load the CPU, so some of the lower freq settings are when load is low. Clearly the 600 MHz is when near idle.(CPU shown as 0%) then it jumps up to 2 GHz at the first hit of the load, then drops back at 89% loaded. Further down it hits 83 C and starts to heat limit with freq held back to 1600 MHz (notice that the “little” cores are left fully loaded and full speed at 1500 MHz). Then the load drops off to 58% and the BIG CPUs are idled back to 1100 MHz. This benchmark does bursts of p7zip compresses and decompresses and there are times the CPU load is not filling up all the cores.
I *THINK* the R/U is rated MIPS / CPU.. but the man page is unenlightening. In any case, it gets 825 Ave Mips/u and 4663 total on compression with 1139 /u and 7929 on decompression.
The RockPor64 came in at 895 / u and 4323 total on compression with 1516 /u and 8014 total on decompression.
895/825=1.085 x the per core speed for the RockPro64 average.
4323/4663=0.927 x the total throughput,or about 93% of the XU4 fully booked – but no heat sink.
1516/1139=1.33 x the per core on decompression, a full 1/3 faster on average.
8014/7929=1.01 x the total on decompression, so roughly a wash on total throughput.
So what’s that mean to me? Looks like with fewer cores, the RockPro64 overall beats the Odroid XU4Q even without a heatsink(!) and only slightly under performs it on one compression benchmark test. Furthermore, when you just need One Fast CPU Core for some single threaded job, it will way outperform using just the A72 core. Hopefully I’ll be able to put a suitable desktop OS on it and see how FireFox does. That’s the one limiting / irritation on the R. Pi M3. Which reminds me, I ought to benchmark it next…
Overall, I’m quite pleased with the RockPro64. As soon as I’ve got some decent screen grabs of the benchmark without heat sink, then I’ll apply the one I have and re-run the tests. See if it is heat limiting or not. Watching the CPU freq display, it looked like it was holding a steady 1.8 GHz the whole test with temps ranging from 46.9 C to 79.4 C so not getting that hot. It looks like this chip does better overall heat management. Don’t know if it is just more efficient (smaller gate sizes), the metal packaging, or heat being sent out through the PC Board. Whatever it is, I’m liking it. It did get hot to the touch during testing (that 80 C point is kinda hot to touch ;-) but seems to have not slowed down.
One Caveat:
At first unboxing, I shut off the XU4 (where I’d made the OS chip for the RockPro64) and unplugged it’s power brick from the power strip. Then unplugged all the various wires from it to move things like Ethernet, KB/Mouse/USB-hub, Monitor, etc over to the RockPro64. Plugged the (relatively huge like a laptop “rat on a rope” 12 VDC power brick) in for the RockPro64, then reached over and plugged the round power connector into the board.
Nothing Happened
WT? Click power switch on board. Plug and unplug barrel connector. Look up web page for what switch is a which… Got the Voltmeter to test the power brick for V out. Read that the green LED by the power in connector out to light up when power is on. White near the reset button when the OS loads. No LEDs on. Go to unplug the power from the board to apply Voltmeter… and notice the wire is a little thin and doesn’t seem to be going to the right place… Follow it and find the 5 VDC power wall wart for the XU4 laying on the desktop. Oh Dear.
WARNING: IF you have multiple SBCs, and one of them has that size barrel connector, I’m sure it would do Very Bad Things to send 12 VDC into your Odroid XU4. Only my habit of unplugging both ends prevented a “wrong volts” event (though hopefully 5 VDC in to the RockPro64 would do no harm).
OK, nag mode off ;-) Now I’ll go see if I can get a desktop up, do a set of Pi M3 and RockPro64 with data grabs, and maybe work in the Rock64 after dinner ;-)
Raspberry Pi Model 2 – 64 Bit Devuan OS
Well, this is a bit of a surprise. The Raspberry Pi M3 running a full 64 bit Devuan 2.0 OS did a very credible job on the sysbench benchmark. It isn’t running Armbian so no Armbianmonitor results. (I’ll need to boot a different chip for that).
Only 4 cores, so run with only 4 threads, it finishes far faster than the XU4, and only takes 2 x as long as the RockPro64.
root@devuan:/SG2/ext/chiefio/bin# ./bench 4
sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 --max-requests=100000 run
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 4
Doing CPU performance benchmark
Threads started!
Done.
Maximum prime number checked in CPU test: 20000
Test execution summary:
total time: 77.5115s
total number of events: 100000
total time taken by event execution: 309.9987
per-request statistics:
min: 3.05ms
avg: 3.10ms
max: 30.34ms
approx. 95 percentile: 3.10ms
Threads fairness:
events (avg/stddev): 25000.0000/110.88
execution time (avg/stddev): 77.4997/0.00
Compare 77 seconds vs 33 seconds for the RockPro64 and 503 seconds for the XU4.
root@devuan:/SG2/ext/chiefio/bin# file -s /usr/bin/sysbench
/usr/bin/sysbench: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=60f81f8faa3466144dadca7bf3f1e368a40d3159, stripped
That full 64 Bit math sure is a winner!
The R.Pi didn’t heat up all that much either.
root@devuan:/home/chiefio# cpustate
Freq
1200000Temp x 1000
60148Freq
1200000Temp x 1000
61224
These results also make sense as the 4 A53 cores in both chipsets are running almost the same clock speed while the 2 x A72 cores are about double the throughput as an A53 core. In short, the RockPro64 ought to be about double the total computes of the Pi chip.
For 32 bit problems, the XU4 and RockPro64 are about the same, but for 64 bit math, the 32 bit hardware takes it in the shorts; and even the R.Pi M3 beats it.
Rock64
First off, I’m posting this from a Chromium browser on the Rock64. The Armbian OS for it is built with an XFCE desktop and Chromium browser. Not my favorites, but certainly nice enough. The “htop” command has the very nice feature of displaying CPU frequency by CPU along with chip temperature. I hope that migrates to other systems ‘soon’.
I ran into one “almost show stopper” on the Rock64. It uses an odd size barrel connector PSU. I’d just “lept to the conclusion” that as a very small board it would use uUSB for the power. Nope. The Orange Pi One also uses a small barrel connector at 5 VDC, but it’s about 1/2 mm too big. Well, with a bit of force, not so much as to break anything but more than for “on a regular basis”, I got it to connect and power up the board. When I’m done posting this it will be powered off until I can get a proper PSU for it. (Power Supply Unit).
The O.Pi One is 4 mm OD x 1.7 mm ID.
The Rock64 is 3.5 mm OD x 1.35 mm ID.
So 1/2 millimeter squashing of the fitting on the board and then .35 mm ‘looseness’ on the inner pin. Not good, but not catastrophic for one use.
Overall, I like it. With the USB 3.0 port and Mali video, it is likely a better choice for general use (for my kinds of use) than the R. Pi M3. It is also 4 c A53 cores and at 1.3 GHz is trivially faster than the 1.2 GHz of the Pi M3 but trivially slower than the 1.4 GHz Pi M3 B+. For file server duty, with the USB 3.0, it will be better. For GPU based computing, it will be easier to “make go” as it is a more common GPU (Graphics Processor Unit).
Basically, I like this little board.
On to the statistics of the benchmark. They are remarkably similar to the R. Pi M3. The Pi M3 is 77 1/2 seconds elapsed 310 seconds total CPU time. The Rock64 is 72 seconds and 290. I doubt folks will notice the difference. What I DID notice was that it didn’t heat limit even without a heat sink. Never went above 72 C. It also runs at full 1.3 GHz “out of the box” (unlike the Pi that is set to 1/2 speed clock unless you intervene.) For most folks, those two things alone will be worth it. For the model I got, the 2 GB of main memory is also nice. Reduced need for swapping. Being $30 is nice too. (Made in China not so much…)
OK, here’s the report:
root@rock64:/SG2/ext/chiefio/bin# ./bench 4
sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 --max-requests=100000 run
sysbench 0.4.12: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 4
Doing CPU performance benchmark
Threads started!
Done.
Maximum prime number checked in CPU test: 20000
Test execution summary:
total time: 72.4354s
total number of events: 100000
total time taken by event execution: 289.6596
per-request statistics:
min: 2.80ms
avg: 2.90ms
max: 57.89ms
approx. 95 percentile: 2.83ms
Threads fairness:
events (avg/stddev): 25000.0000/220.63
execution time (avg/stddev): 72.4149/0.01
armbianmonitor -z
Preparing benchmark. Be patient please...
Selecting previously unselected package p7zip.
(Reading database ... 67333 files and directories currently installed.)
Preparing to unpack .../p7zip_16.02+dfsg-3+deb9u1_arm64.deb ...
Unpacking p7zip (16.02+dfsg-3+deb9u1) ...
Setting up p7zip (16.02+dfsg-3+deb9u1) ...
Processing triggers for man-db (2.7.6.1-2) ...
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs LE)
LE
CPU Freq: 1283 1281 1283 1271 1278 1271 1282 1286 1284
RAM size: 1991 MB, # CPU hardware threads: 4
RAM usage: 882 MB, # Benchmark threads: 4
Compressing | Decompressing
Dict Speed Usage R/U Rating | Speed Usage R/U Rating
KiB/s % MIPS MIPS | KiB/s % MIPS MIPS
22: 1781 305 568 1733 | 53464 381 1198 4561
23: 1903 328 592 1939 | 54009 390 1197 4673
24: 1883 340 596 2025 | 51261 380 1184 4500
25: 1848 351 602 2111 | 50178 389 1149 4466
---------------------------------- | ------------------------------
Avr: 331 589 1952 | 385 1182 4550
Tot: 358 886 3251
Monitoring output recorded while running the benchmark:
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St.
05:09:21: 1296MHz 2.63 24% 2% 14% 0% 7% 0% 59.5°C 0/7
05:09:26: 600MHz 2.42 4% 1% 3% 0% 0% 0% 55.0°C 0/7
05:09:31: 1296MHz 2.30 29% 1% 27% 0% 0% 0% 60.0°C 0/7
05:09:36: 1296MHz 2.60 54% 2% 52% 0% 0% 0% 66.5°C 0/7
05:09:43: 1296MHz 2.71 93% 2% 90% 0% 0% 0% 70.8°C 0/7
05:09:48: 1296MHz 2.73 79% 2% 76% 0% 0% 0% 67.7°C 0/7
05:09:56: 1296MHz 3.00 90% 2% 88% 0% 0% 0% 72.5°C 0/7
05:10:01: 1296MHz 3.14 80% 1% 78% 0% 0% 0% 68.5°C 0/7
05:10:07: 1296MHz 3.13 85% 2% 82% 0% 0% 0% 69.6°C 0/7
05:10:12: 1296MHz 3.28 91% 2% 88% 0% 0% 0% 70.0°C 0/7
05:10:18: 1296MHz 3.18 92% 1% 90% 0% 0% 0% 72.5°C 0/7
05:10:24: 1296MHz 3.00 67% 2% 65% 0% 0% 0% 67.7°C 0/7
05:10:29: 1296MHz 3.00 83% 2% 80% 0% 0% 0% 68.5°C 0/7
05:10:34: 1296MHz 3.00 86% 2% 83% 0% 0% 0% 70.0°C 0/7
Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St.
05:10:39: 1296MHz 3.00 89% 2% 87% 0% 0% 0% 69.6°C 0/7
05:10:44: 1296MHz 3.00 93% 3% 89% 0% 0% 0% 69.6°C 0/7
05:10:50: 1296MHz 3.38 96% 3% 92% 0% 0% 0% 69.6°C 0/7
05:10:55: 1296MHz 3.51 98% 3% 95% 0% 0% 0% 70.0°C 0/7
The CPU is pegged more often on this armbianmonitor benchmark than were the other boards. Understandable as the speed is slower so less likely disk or other things will limit first. Note that CPU temp never goes over 72.5 C so this is one cool cookie. Frequency stays 1.3 GHz throughout. Nice.
With that, time to shut it down and order the proper power supply…
RockPro64 – Armbian Ubuntu
This is significantly faster than the terminal only version. 10 seconds vs 33. What’s different? Don’t know exactly. Different builds, different flags.
Here’s the run results:
root@rockpro64:/SG2/ext/chiefio/bin# ./bench 6
sysbench --num-threads=6 --test=cpu --cpu-max-prime=20000 --max-requests=100000 run
WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options.
WARNING: --num-threads is deprecated, use --threads instead
WARNING: --max-requests is deprecated, use --events instead
sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 6
Initializing random number generator from current time
Prime numbers limit: 20000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 2460.55
General statistics:
total time: 10.0037s
total number of events: 24622
Latency (ms):
min: 1.41
avg: 2.44
max: 28.27
95th percentile: 3.55
sum: 59969.86
Threads fairness:
events (avg/stddev): 4103.6667/1891.79
execution time (avg/stddev): 9.9950/0.00
armbianmonitor -z
Preparing benchmark. Be patient please...
7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,6 CPUs LE)
LE
CPU Freq: 359 1291 596 1077 1798 1797 1797 1798 1797
RAM size: 1991 MB, # CPU hardware threads: 6
RAM usage: 1323 MB, # Benchmark threads: 6
Compressing | Decompressing
Dict Speed Usage R/U Rating | Speed Usage R/U Rating
KiB/s % MIPS MIPS | KiB/s % MIPS MIPS
22: 4400 482 888 4281 | 93959 525 1527 8013
23: 4427 510 884 4511 | 91859 523 1521 7948
24: 4077 493 890 4384 | 89059 528 1480 7817
25: 4079 529 880 4658 | 86386 545 1411 7688
---------------------------------- | ------------------------------
Avr: 504 886 4458 | 530 1485 7867
Tot: 517 1185 6163
Monitoring output recorded while running the benchmark:
Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St.
06:51:55: 1800/1416MHz 3.08 17% 1% 15% 0% 0% 0% 63.8°C 0/3
06:52:00: 600/1416MHz 2.83 1% 0% 1% 0% 0% 0% 56.7°C 0/3
06:52:05: 600/ 600MHz 2.61 1% 0% 1% 0% 0% 0% 55.0°C 0/3
06:52:10: 1800/1416MHz 2.48 51% 1% 49% 0% 0% 0% 67.2°C 0/3
06:52:15: 1800/1416MHz 2.76 92% 0% 91% 0% 0% 0% 72.8°C 0/3
06:52:20: 1800/1416MHz 3.18 81% 2% 79% 0% 0% 0% 72.8°C 0/3
06:52:25: 1800/1416MHz 3.33 93% 0% 92% 0% 0% 0% 78.8°C 0/3
06:52:30: 1800/1416MHz 3.38 63% 2% 60% 0% 0% 0% 75.6°C 0/3
06:52:36: 1800/1416MHz 3.59 93% 1% 91% 0% 0% 0% 76.2°C 0/3
06:52:42: 1800/1416MHz 3.70 82% 1% 81% 0% 0% 0% 80.0°C 0/3
06:52:47: 1800/1416MHz 3.97 67% 1% 65% 0% 0% 0% 78.8°C 0/3
06:52:53: 1800/1416MHz 4.05 79% 2% 77% 0% 0% 0% 80.0°C 0/3
06:52:58: 1800/1416MHz 4.05 95% 2% 93% 0% 0% 0% 80.0°C 0/3
06:53:04: 1800/1416MHz 4.21 98% 1% 96% 0% 0% 0% 80.0°C 0/3
Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St.
06:53:11: 1608/1416MHz 4.35 87% 1% 85% 0% 0% 0% 81.1°C 0/3
It only has 24,622 “events”, were the other one had 100,000; and yes, I re-ran it with the new approved –events=100000 and that made no difference. It just isn’t clear what’s different. It IS a newer sysbench. It’s also a different release of Linux, so may be missing some of the CPU slowing patches for Specter and Meltdown. Just don’t know.
Note that on the armbianmonitor -z test it holds full clock all the way to the last item when it touches 81 C and drops the BIG cores back to 1.688 GHz for a moment. This with no heat sink. Unlike the R. Pi where you MUST have a heat sink to get full speed, or the XU4 where even with a big heat sink it heat limits, this board is much more workable even without a heat sink. I’m good with that.
Overall, I’m very much impressed with the “snappy” character of this board. Even with Chromium it’s not pausing / slowing like other boards did (spell checking seems to be the issue in that it constantly scans all the text for spelling)
Frankly, I find this a quite nice “desktop experience”. I know this isn’t a Devuan and it has SystemD on it. I’ll try a Devuan “uplift” later. But for right now, I think I’m going to make this my “Daily Driver” for a while. It is interesting to watch the HTOP display that shows CPU freq for each CPU and see tht in full typing on Chromium toe two BIG cores are down at 600 MHz. Basically just the 4 x A53 cores at 1.42 GHz are “enough” for it to feel responsive.
I’ve got to think there’s some software tuning that was done that both sped up the benchmark AND makes it feel so “snappy”.
Well, this completes my benchmarks for the day. I still have a Pin64 board. It is a lower priced bigger PC Board area relative of the Rock64, using the Alwinner CPU chip. I’ll give it a go tomorrow and post results here then.
For now, I’m just kind of “really surprised” by how much different OS builds changes the performance of the hardware. Even from the same provider.
https://www.armbian.com/rockpro64/
reports this as kernel 4.4.y Bionic (the Ubuntu name) and the other system was “Stretch” – the Debian name, also on legacy kernel 4.4.y (so ought not be those Specter / Meltdown patches).
OK, I’m going to call it a night and tomorrow redo both runs on the RockPro64, just to make sure I have it right and “it isn’t about me” ;-)
Musings from the Chiefio 
E.M. I gave up on the Pine delivery schedule, and cancelled then ordered from Ameridroid. Their delivery should be ~ 1 week earlier than Pine’s, Friday. I will be watching your results.
E.M. what are you using for the cluster mgmt S/W?
@CoRev:
I’m using “me” for cluster management ;-)
Really, at present it is just a “stack of boards” in an experimental state. The only thing remotely production I do on it is distcc for big long compiles of things. Mostly I use it as a play space. I do have the parallel script code stuff, but I’ve not done much with it.
https://www.gnu.org/software/parallel/
Between them you can do parallel builds of large compiled systems (the only huge load I’ve put on things personally) and parallel execution of things driven by scripts (that is attractive but I’ve not found a big use for it yet).
I’ve been way too slow about working on a parallel climate model port. Partly because it became clear that the “science” in Global Warming was just a sham to cover for the Politics of it and that the Politics was going to roll on whatever was shown to be fraudulent in their so called “science”. Partly just from early testing on the R. Pi showing that parallel FORTRAN was no faster than single thread.
That’s one of the things I want to test on the other boards. Just which boards do things like MPICH / MPI with some gain. Given that the Rock64 definitely was using NEON / parallel math, in the benchmark, it has great potential as a Math Engine for the FORTRAN codes. (It will also be important to check the precision of the results as some NEON math is shorter than IEEE precision and that may depend on the board… so finding out if it’s doing 64 bit, 32 bit, or shorter precision will matter).
So early testing of MPI calls in FORTRAN on the R. Pi gave roughly the same time to execute as plain old FORTRAN. Not much reason to go chasing after that… But if I can show a reasonable speed up in FORTRAN using MPI (or similar) on some other hardware / OS set; then it’s worth it to pick up the porting / development work again.
Once that’s running, then I might have some need for cluster management beyond “me” ;-)
For better or worse, the kind of stuff I do is mostly compiling OS code and script driven things, so distcc and gnu-parallel tend to cover most of my actual use cases. I also want parallel FORTRAN codes to run faster, but until I have something that shows benefit, I’m not going there… Benchmarks not only give you the Wow Factor on a hot board, but they also tell you where you will be wasting your time so don’t go there… and MPICH / MPI on the R. Pi was a zero sum…
OK, was hoping you had broken this ground.
New toys are always fun, At least until the new wears off. Then you will have to find them a job. Kind of like kids,,,
In the search for the “right” fix I would get rid of any fans. If all you want is a Fast Gaming machine fans might be fine. but efficient use of energy during practical use is important and excessive heat generation due to excessive local component density greatly shortens their life. Your months to years of being “up” and on line is amazing to me. This wintel machine will rarely last a week without needing a reboot. And it is an energy hog. All of these cpu’s are fast, but IO is the bottle neck that stands in the way of getting real work done…pg
I’ve put up a benchmark for the Odroid XU4 along with notes about the relative performance of the RockPro64 at the end of the article. Bottom Line: The RockPro64 is about the same total throughput but with much faster single core performance, even without a heat sink.
OS releases are still a bit “young” on the RockPro64, so a few more rough edges than older ports.
@P.G.:
I’ll be doing some I/O benchmarks too, but in a second round. The fact that the USB 3.0 is now working correctly on the UX4 has let me experience MUCH faster I/O. The RockPro64 looks to be in the same class.
It’s my opinion that they will be Just Fine as a general purpose desktop, for whatever is needed. Hopefully this round of testing will bear that out.
As for “getting them jobs”: Mostly I’m able to do that. I can now take one of the R.Pi boards and turn it into a “Mobile Server”. Replaced in the cluster with one of the newer faster boards. This would be a Pi-in-the-Box with battery and wifi dongle. Now “whatever” device I’m using at places like Starbucks will get MY ad filtering DNS, my IDS / IPS, my VPN choice, my Proxy server, etc. etc. and my devices will only be doing WiFi to my dedicated little server in a box. IT will do the connection to the Vendor / Store WiFi, so all anybody ever gets from it is that it was there. Everything else goes inside protected encrypted connections (MY private WiFi with my encryption and MY encrypted VPN so to sites I visit it doesn’t even look like I’m at StarBucks… and I also Do Not need to put the StarBucks “track me” authorization on all of my devices…
The two biggest boards ( XU4 & RockPro64 – provided I can get the OS / desktop right) will be my major desktops. I usually have two of them set up and running at any one time with 2 monitors on the desktop.
One Orange Pi One is running the NFS server for my 8 TB of “stuff” ;-)
One R.Pi original is the DNS Proxy server.
That leaves a “Stack” of 5 boards as the “Distcc Compile Cluster” and “GNU-Parallel” cluster. Whenever I’m doing “big stuff” where those benefit, the cluster gets powered on. As a Someday Project is to learn Docker and that whole dispatching Containers to the cluster thing… Dispatchable services. Then there’s testing MPICH FORTRAN on these newer boards to see if I can get some net increase to happen. I was sorely disappointed when the R.Pi M3 gave zero speed gain from multithreaded distributed MPI based FORTRAN or C.
So they are all used and have jobs. Some just part time though ;-)
Well, time to go make dinner… Back in a bit.
I would be VERY curious to know if the same program/model using the same data and running in the same OS produced different results on the different boards. This only because I’m old and remember the Intel Pentium “floating point” processor’s division bug.
Not, however, SO curious as to buy and run several such SBC’s my own self. Sorry. About the best case I have for a small SBC is to put an otherwise very good printer that lacks ethernet or wifi back into use for the home network / “Windows Workgroup”. With the Black Friday promotions it’s almost cheaper to buy a comparable new printer with built-in wifi than it would be to buy the SBC and related kit.
But anyhow I encourage you in your experiments.
@Pouncer:
For a printer driver / WiFi interface, the little $10 sized SBCs would be more than fine. The only issue would be how to connect it to the printer. IF the printer has regular ethernet, then a simple cable would do. But if it is a serial line, you would be in the hardware business looking at how t add a serial socket to the SBC… THE key bit on costs is what is the cost of the ink they use. The really cheap printers often have very expensive very small ink cartridges…
As for things to do with an SBC: The number of things is huge. These little guys bring so many projects into the “acceptable price” range that it would take a lifetime to do them all. One example I’ve seen (but decided not to do) is an SBC based PBX Private Branch Exchange. Essentially a phone switch for the home. Someone calls your “home number” they get the SBC PBX. It gives them a phone tree: “Enter the security code to ring through, or the extension of the party you are calling.” Family can punch in the magic number and the phone rings. Other folks can put in the extension for, say, the garage and either ring there (or without the security code leave a voice mail).
No more solicitor / junk calls! Everyone gets a phone in their room and it only rings with calls for them. Everyone gets a private voice mail box.
Had we not gone to all cell phones, I’d have built one of these.
My little Pi DNS / Proxy server has saved me untold hours of time from wading through ads on pages and much bandwidth too. As a proxy server it also prevents a variety of attack modes (probes back up the Web connection hit the proxy server, not my laptop that’s having requests proxied. That’s why most corporations use a proxy server, BTW.)
Well, it’s either of use and you are willing to “go there”, or you are one of those people who have a life and friends and stuff that keeps you busy ;-)
Per results being different:
Almost certainly, if you do enough of the right kind of math…
It is one of those areas of data processing that a few folks are aware of and think about, and that most folks find “crazy talk” or just don’t think of at all…
Consider the various “Model Runs”. Those are all divergent precisely due to math diverging with multiple iterations of some kinds of problems. Move a model between systems of different word length, you get different results. Use different math libraries (new software release) results will drift a bit. Change the “data type” of variables, the results change. (INT vs Double vs Float vs…)
For simple Integer Math without multiplication or division and avoiding extremely large and extremely small numbers you can have consistent results. Do fancy math or with numbers near the smallest or largest the machine can “represent” and things start to diverge (or go completely bonkers… Like “overflow” where your INT reaches the largest value possible and then rolls over to either zero or the most negative number possible (depending on how your computer handles integers…)
We spent weeks on this kind of thing in my FORTRAN class back in the ’70s. Now it’s rarely mentioned to all the folks writing JavaScript dancing crapletts and other junk on your screen; nor do the Climate Scientists necessarily get the fine points… (Though in one of the models they did ‘get it’ and even mentioned what compiler you had to use to get consistent results. Yes, use a different compiler, you get different results…)
It is possible to write whole volumes on the subtleties of computer math and foibles. For things that really do need to be exactly the same each time, there are infinite precision math libraries and languages. They are rarely used due to being incredibly slow…
Maybe I’ll work up a couple of example programs “just for fun” to illustrate the issues… It would be interesting to see what I remember from the FORTRAN class ;-) FWIW, one bit is that originally the word length of most computers was 16 bits, so that was the length of an integer, and a double int was 32 bits. Then folks went to largely 32 bit words and 64 bit double ints. Moving codes between those machines often gives different results (especially since a 16 bit integer can not represent nearly as large or small a number so rollover / rollunder is much more common). A similar issue comes up in the 32 bit to 64 bit transition. A LOT of the porting work to move things like FireFox to 64 bit and debug it comes out of that kind of unexpected variation that the original writer didn’t anticipate.
Well, enough on that. Just realize it is common for different computers to give different results on complex codes, and sometimes even on simple ones.
OK, I have the Ubuntu Bionic version on the RockPro64. First off, the speed of the benchmark is significantly faster than on the “Stretch” terminal only build. No idea why at this time. I’m going to re-run the tests tomorrow to be sure I didn’t write something down wrong.
I’m VERY impressed with the “feel” of things. Fast. Snappy. No waiting. No pegged CPUs when using the browser. It’s like a “real computer” ;-) Perhaps some of it is Chromium being more efficient than FireFox (where we know it has memory hog issues). Still, this is nice…
This is going to be my “Daily Driver” for a while. It really is just “no waiting” user experience – especially compared to the R. Pi. Hopefully that experience stays across a move to a Devuan operating sytem and an LXDE desktop. XFCE is OK, but not my favorite.
With that, I’m a happy camper. The “expensive” $60 board (RockPro64) is a real treat. The “cheap” $30 board (Rock64) is quite well suited to lots of work tasks I’ve got for it, and is an OK desktop if a bit prone to moments of “lag” in typing in a browser editor (lots of browser code) for WordPress. I like it more than the Raspberry Pi M3. Then there’s just the fact the CPUs can run nearly 100% solid for a decent period of time without a heat sink and not slow down the CPUs. Nice, very nice.
E.M. now you making me regret my Rock64 decision over the Rockpro64. I might wait a few months for it and other versions to become available and then get it as my daily driver.
BTW, do you have the scripts for making the RPI DNS proxy server?
My Linux desktop box failed to boot yesterday. I put it together, buying the case, motherboard, CPU, DVD drive, etc. It has worked fine for several years now. fsck was able to patch up the drive and the machine booted, but I consider that a shot across the bow – it is time to get a new computer. The case is fine, so I would probably use it, replacing the two fans. I like to program, so I need a machine that can handle eclipse, R, and other programming platforms.
@CoRev:
Don’t suffer too much regret. The software on the RockPro64 is still a bit “young” and that means choices are limited and there will be occasional bugs pop up. Some bits will just be a tiny bit “odd”. Hopefully it won’t be very many such, but on young ports it’s always an unknown.
For example, there is no Devuan port. I’m using Ubuntu with SystemD. Now I get to “roll my own” to get a Devuan. Debian has a generic ARM64 port, but will it work? Hard to say, it is highly unlikely to have been tested on a new board, and if any device needs a new device driver that isn’t in the mainline kernel, well…. (Though the Ubuntu is running on a “legacy” 4.4 kernel so maybe not, or maybe they just added some kernel modules they compiled from scratch at Armbian…)
Those kinds of questions / issues are what you sign up for when you are an early adopter of a system. Let me “run ahead a little” and I’ll let you know if anything bites ;-)
Per Proxy / DNS server:
I think I did an article on that… or was it comments in other articles… It isn’t a build script so much as it is building a system for purpose. I settled on Alpine Linux for the operating system. It started life as a router oriented port (LRP Linux Router Project IIRC) and is clearly aimed at being secure fast and stable.
It would be an annoyance as your “Daily Driver” since it only has Busybox as the init system (so some commands are limited and a bit different and it can’t start too much other stuff – but that’s also a security feature – no general purpose init system to exploit and no giant attack surface like SystemD)
Any changes must be EXPLICITLY saved to disk (uSD) or they are lost at next reboot. Exactly what you want in a headless router, a bother for the desktop.
After that, it was just install and turn on dnsmasq and proxy services, and find / download a large blocklist. Then I added sites that annoyed me over time. (Just watch the traffic that goes to google ad service and block every name that goes by ;-)
Here’s that article:
https://chiefio.wordpress.com/2016/11/06/dns-server-on-pi-alpine-linux/
part “How To” and part “What Happened”.
Interesting to notice that it’s now been running for 2 years straight, only taken down when powerfails happen…
If you think you need more than that, let me know. It might be time for an update / do-over. Also note that now I’d be likely to build a “Blackhole Server” and avoid my own kill list for most of it.. There’s lots of pages for help on setting up a Pi Hole server:
https://duckduckgo.com/?q=Pihole+server+howto&t=canonical&ia=web
This one looks nice, but it does have a pop-up nag for some newsletter or such:
https://community.spiceworks.com/topic/1486986-guide-installing-pihole-on-an-ubuntu-server-to-block-ads-on-your-network
This one is more filled with screen grabs:
https://www.ubuntuboss.com/how-to-install-pihole-on-ubuntu-16-04/
Don’t know if the ncurses is how it really works, or if the page is just a bit old ;-) though the date on it is only 1 year ago.
So there’s some pointers. Let me know if that’s not what you wanted.
@Jim2:
If fsck fixed it, then it’s the disk drive that’s starting to have issues. Over time, small amounts of oxide can become unstable and a tiny bit of ‘dust’ starts forming. The other thing is that the bearings wear. One or the other tends to kill disks that die. Either the spindle freezes up with a horrible squeal of death, or you get a slow cascade failure as a little loose oxide starts to abrade more disk surface and then suddenly all sorts of dust is scrubbing away and your fsck becomes unrecoverable.
IF you disk has been running “for several years” on a regular basis, it is most likely the disk is just physically wearing out. Most likely you can shove a new disk into it and be done (unless you want a lot more speed too ;-)
Regardless, make sure to take a backup copy of your disk as soon as possible…
Yep, started the backup last night and finished this morning (due to a file I didn’t have permissions for – Opera – and that’s OK. I’m of a mind to re-build it all. But might get just a new drive until I have a bigger chunk of time. We use this computer almost every day. At night, I shut it down and turn off its power strip. I have a laptop and the RPi+ in case it bites the bullet completely.
I’ve added the heat sink to the RockPro64. Fairly trivial process. A thin slighly tacky surfaced layer of rubbery stuff has the clear plastic pealed off, gets stuck on the heat sink, and that gets pushed onto the board; then the little anchor pins get a firm push through the board to click / lock in place. Only “trick” was that the rubbery bit didn’t really stick to the heat sink, so you hold the heat sink “pins up” and bring the board down from above it.
Here’s the benchmark run with heat sink. Notice that it’s never over 49 C, and this giant heat sink is likely a bit of overkill. I could likely have done just fine with the low profile one (but I just knew I wanted all the heat sink I could get so bought the extra height one… )
root@rockpro64:/SG2/ext/chiefio/bin# ./benchn 6 sysbench --threads=6 --test=cpu --cpu-max-prime=20000 --events=100000 run WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options. sysbench 1.0.11 (using system LuaJIT 2.1.0-beta3) Running the test with following options: Number of threads: 6 Initializing random number generator from current time Prime numbers limit: 20000 Initializing worker threads... Threads started! CPU speed: events per second: 2519.33 General statistics: total time: 10.0025s total number of events: 25208 Latency (ms): min: 1.41 avg: 2.38 max: 13.85 95th percentile: 3.55 sum: 59968.09 Threads fairness: events (avg/stddev): 4201.3333/1968.00 execution time (avg/stddev): 9.9947/0.00 armbianmonitor -z Preparing benchmark. Be patient please... 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,6 CPUs LE) LE CPU Freq: 646 1784 1792 1797 1798 1797 1798 1797 1798 RAM size: 1991 MB, # CPU hardware threads: 6 RAM usage: 1323 MB, # Benchmark threads: 6 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 4653 491 922 4527 | 94287 521 1542 8041 23: 4285 480 910 4366 | 92355 523 1528 7991 24: 4185 494 911 4500 | 89477 519 1515 7854 25: 4287 550 890 4896 | 87457 523 1488 7783 ---------------------------------- | ------------------------------ Avr: 504 908 4572 | 521 1518 7917 Tot: 513 1213 6245 Monitoring output recorded while running the benchmark: Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 14:36:57: 1800/1416MHz 1.02 7% 1% 4% 0% 1% 0% 39.4°C 0/3 14:37:02: 600/ 600MHz 0.94 0% 0% 0% 0% 0% 0% 32.8°C 0/3 14:37:08: 1800/1416MHz 0.86 1% 0% 1% 0% 0% 0% 34.4°C 0/3 14:37:13: 1800/1416MHz 1.20 51% 1% 50% 0% 0% 0% 41.1°C 0/3 14:37:18: 1800/1416MHz 1.42 90% 0% 89% 0% 0% 0% 45.0°C 0/3 14:37:23: 1800/1416MHz 1.87 82% 1% 80% 0% 0% 0% 44.4°C 0/3 14:37:28: 1800/1416MHz 2.20 85% 0% 85% 0% 0% 0% 46.9°C 0/3 14:37:33: 1800/1416MHz 2.74 70% 1% 69% 0% 0% 0% 45.0°C 0/3 14:37:39: 1800/1416MHz 3.00 96% 2% 93% 0% 0% 0% 45.0°C 0/3 14:37:45: 1800/1416MHz 3.24 77% 0% 76% 0% 0% 0% 47.5°C 0/3 14:37:50: 1800/1416MHz 3.06 59% 2% 56% 0% 0% 0% 45.6°C 0/3 14:37:55: 1800/1416MHz 3.38 94% 2% 92% 0% 0% 0% 46.2°C 0/3 14:38:01: 1800/1416MHz 3.67 97% 2% 95% 0% 0% 0% 45.0°C 0/3 14:38:07: 1800/1416MHz 3.94 98% 2% 96% 0% 0% 0% 45.6°C 0/3 Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 14:38:13: 1800/1416MHz 4.33 89% 2% 87% 0% 0% 0% 49.4°C 0/3Even that last line is at a full 1.8 GHz (where it dropped to 1.6 GHz w/o heatsink at 81C) So it’s got a full 32 C more of temperature rise before it heat limits. Given that this was nearly 100% use, I doubt it’s possible to get there with this heat sink. Maybe running in the sun at noon in the Sonora Desert ;-)
Generally, I’m comfortable with the board. I’ve installed FireFox as I’m more fond of that “look & feel”. It now comes with ever more intrusive advertising like content and more privacy intrusions turned on by default. I’ll need to see if GNU-SeaMonkey is portable to this board (The GNU folks are hard core on privacy and security ;-) It looks like FireFox is trying to “Monetize Me” too much now. It is much more multi-core friendly though, and all the lags and slows seem gone from it.
Since 90% of what I do is use the browser, that matters. (Well, 90% of elapsed time – I have a browser open even when I’m doing other stuff like compiles in other windows.)
At this point, I’ve only got the Pine A64 (very low cost) board to benchmark, then tidy up the desk A Lot ;-) So time for that second cup of java and tear down the RockPro64 / set up the Pine A64. I’ll be back in a bit.
Well, the Pine64 bring up was marred by the HDMI being unwilling to play well with the HDMI / DVI adapter. Just a dead blank screen (like the Orange Pi One) until it was plugged into a Real HDMI to the TV. I wonder if anyone has started making a list of what boards work with “any old HDMI” and what boards are picky and only work with straight HDMI?
Post bring up it is working OK. It’s the typical Armbian xfce / Chromium choices. I’m typing this from Chromium. There’s no lag and no type ahead issues. Overall livable.
Most of the time the CPUs are running at 480 MHz, bursting to 1.15 GHz if I type a lot ;-) Temperature bounces around from about 48 C to 65 C if I “wiggle a window around” and make it do a bunch of graphics work.
I ran the benchmark set. It clearly and rapidly heat limits. This board NEEDS a heat sink. Here’s the results:
root@pine64:/SG2/ext/chiefio/bin# ./bench 4 sysbench --num-threads=4 --test=cpu --cpu-max-prime=20000 --max-requests=100000 run sysbench 0.4.12: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 4 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 84.8170s total number of events: 100000 total time taken by event execution: 339.1753 per-request statistics: min: 3.17ms avg: 3.39ms max: 66.34ms approx. 95 percentile: 3.67ms Threads fairness: events (avg/stddev): 25000.0000/85.18 execution time (avg/stddev): 84.7938/0.00 armbianmonitor -z Preparing benchmark. Be patient please... 7-Zip (A) 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs) RAM size: 979 MB, # CPU hardware threads: 4 RAM usage: 850 MB, # Benchmark threads: 4 Dict Compressing | Decompressing Speed Usage R/U Rating | Speed Usage R/U Rating KB/s % MIPS MIPS | KB/s % MIPS MIPS 22: 1460 281 505 1420 | 36526 378 872 3295 23: 1342 286 478 1367 | 34946 376 850 3198 24: 1296 288 484 1394 | 34076 376 840 3161 Monitoring output recorded while running the benchmark: Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC C.St. 16:46:03: 1008MHz 3.25 24% 2% 21% 0% 1% 0% 81°C 54°C 1/7 16:46:08: 480MHz 2.99 2% 0% 1% 0% 0% 0% 64°C 52°C 0/7 16:46:13: 1152MHz 2.75 4% 1% 3% 0% 0% 0% 61°C 52°C 0/7 16:46:18: 1152MHz 2.69 76% 1% 74% 0% 0% 0% 77°C 52°C 0/7 16:46:24: 1008MHz 2.80 93% 0% 93% 0% 0% 0% 84°C 52°C 1/7 16:46:30: 1008MHz 2.65 78% 1% 77% 0% 0% 0% 80°C 55°C 1/7 16:46:35: 1008MHz 2.76 78% 2% 74% 0% 0% 1% 80°C 54°C 1/7 16:46:42: 1152MHz 2.86 79% 1% 78% 0% 0% 0% 91°C 54°C 3/7 16:46:47: 912MHz 3.11 99% 0% 99% 0% 0% 0% 84°C 55°C 2/7 16:46:53: 1008MHz 3.02 60% 1% 58% 0% 0% 0% 81°C 55°C 1/7 16:46:58: 1008MHz 3.02 73% 2% 71% 0% 0% 0% 82°C 55°C 1/7 16:47:03: 1008MHz 3.10 79% 2% 77% 0% 0% 0% 82°C 55°C 1/7 16:47:08: 1008MHz 3.01 79% 2% 77% 0% 0% 0% 81°C 55°C 1/7 16:47:13: 1008MHz 3.25 82% 2% 79% 0% 0% 0% 81°C 55°C 1/7 Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC C.St. 16:47:20: 1008MHz 3.31 89% 1% 87% 0% 0% 0% 84°C 56°C 1/7 16:47:26: 1008MHz 3.36 84% 0% 83% 0% 0% 0% 80°C 55°C 1/7 16:47:31: 1008MHz 3.41 61% 2% 59% 0% 0% 0% 82°C 55°C 1/7 16:47:36: 1008MHz 3.30 74% 1% 73% 0% 0% 0% 81°C 56°C 1/7 16:47:41: 1008MHz 3.28 73% 1% 71% 0% 0% 0% 82°C 56°C 1/7 16:47:46: 1008MHz 3.50 73% 5% 67% 0% 0% 0% 81°C 55°C 1/7 16:47:51: 1008MHz 3.38 75% 2% 73% 0% 0% 0% 81°C 55°C 1/7 16:47:56: 1008MHz 3.35 80% 3% 76% 0% 0% 0% 83°C 56°C 1/7 16:48:02: 1008MHz 3.24 80% 7% 72% 0% 0% 0% 82°C 56°C 1/7 16:48:07: 1008MHz 3.54 88% 18% 67% 0% 0% 1% 84°C 56°C 1/7At 84 seconds, significantly worse than the R. Pi M3 (with heat sink).
The temperature rapidly rises over 80 C and then freq limits kick in. Mostly running about 1 GHz, but some under that at 912 MHz in the sample above (at 84 C! Right after peaking at 91 C !!!)
I’ll need to buy a heat sink for this puppy to find out what it can actually do. What is very clear is that compared to the Rock chips this Allwinner chip is a little heater with poor heat extraction from the very thin PC Board.
In it’s favor, at $17 to $23 bucks (varies with memory size) you can get a significantly competent board for nearly nothing. I got the 1 GB board since using the 512 MB Orange Pi One showed that you can work with 512 MB, but at least a Gig is better especially with FireFox being a memory hog. Even 1 GB has a little bit of stuff roll to swap space with many open tabs.
This board does power through the mini-usb, so no special powersupply needed. Also nice.
So, OK, not going to be my Daily Driver, but good in an emergency. Needs a good heat sink before I can find out what it really does. Very low cost, so good for lots of “small projects”, but built on a very large board (bigger than a R. Pi and the same as the RockPro64 in area (roughly the size of a 3″ x 5″ card).
Running 64 bit codes, so that’s good. With 4 x A53 cores and decent clock, and a well known GPU for higher speed calculations, it ought to be a very nice low cost compute node in a cluster – but not until the heat issue is fixed… Then the physical size is about 2 x as big as the smaller competitors (Orange Pi, Nano…) so if you want to make a very physically small stack, this isn’t the device to use. It does have a huge number of GPIO and similar pins and connectors, so ought to work will in lots of small device and robotics applications.
Overall, very good “value for money”, but do make sure to put a heat sink on it.
Well, that’s unfortunate… Went to play the video of the Ruth potato bed from the link Larry left under https://chiefio.wordpress.com/2018/11/26/global-cooling-thermosphere-solar-super-grand-minimum/#comment-104863
And on the Alpine A64 it plays nicely with most cores busy but not pegged… but there is NO SOUND. Even over real TV HDMI. Sigh. Why do so many folks leave sound last on their list of things to make work…
OK, so that board not suited to Media use with the default Ubuntu. Is it a hardware limit, or software or? Who knows. But it’s picky on HDMI stuff. Good thing I have other boards that do better with sound & video.
FWIW, it may be as simple as the “alsa” or other sound module not being loaded at boot time and a ‘modprobe’ of the requisite sound module can fix it. It’s just that you need to do something that’s the bother.,..
Well that was fun… NOT!
On shutdown of the Alpine64 I went to reflash that uSD card for the RockPro64. Basically everything thought it was a 10 MB size. Though on insertion it would mount the 12 GB etx4 partition to the desktop. WT?
Trying everything from gparted to fdisk gave the same results. “It is only 10 MB, give up!”… Eventually I installed and used “testdisk” on it. Testdisk also complained about the size, but choosing “analyze” it found the 12 GB partition. But still not the whole 16 GB.
Then it also said my partition table was type “none”. It took me a while to find that the usual MS-DOS partition table type was called “Intel/PC” at the top of their menu…
But how to get it to see the whole thing? I noticed it claimed I had 12288 which is 12 x 1024 cylinders. For 12 GB out of my 16 GB card… so what would happen if I told it it had 15 x 1024 cylinders? (that’s 16384). So I chose the option to let me manually set the cylinders heads, sectors and sector size, It conveniently gave me the H & S and Ssize values. Did that, and then told it to analyze again.
This time if found all the stuff. It did complain that it wasn’t a 17 GB / 16 GiB disk (so I likely ought to have done some other value like 16 x 1000) and had a lower cylinder count near 16,180 or some such) but then I saved my partition table and PRESTO! all was good.
Now this would have been nice enough for recovering the stuff on that SD card, and I’m glad to have learned a few new tricks. But all I wanted to do was dd a new image onto it. Which I did. It is now in the RockPro64 and I’m using it now ;-)
Sidebar on htop and stuff: I changed the window manager to lightdm and now when I log in I get LXDE, but also a different htop. One without the temperature and CPU speed. Now I’m wondering if xfce has a different one… or is this one with flags.?
I’d also intended to leave this login xfce and use another one for lxde (my usual login) but it looks like “they all go together when they go”. So “how to get different windows systems for different users” on the TBD pile.
I did login as my regular me to my regular home directory (on disk) and it’s all working great. Full desktop wallpaper and all.
One Final Note:
FireFox has now gone Bat Shit Crazy on the money grubbing advert stuff. At this point you must consider it to be a Trojan Data Snoop Advertising Tongue In Throat Software.
I’ve got sidebar advertizing (likely from WordPress – and now being mostly suppressed with my DNS / Proxy box (after configuring this browser to use it) BUT, there is also this annoying “window shade” thing that someone else had mentioned a while ago, but I didn’t realize what they were talking about.
So this 1/8 of your browser height or so image “droops” down over what you want to see. It has a tab you can use to lift it back up, that you end up doing a lot… I clicked on it just to see what it was (a sideways 1/2 a face) and was tossed into a page full of advertising for health insurance or something. OK, I can spend a chunk of time finding out the IPs of folks using this and adding them to my filter, or I can just get a more “Me Friendly” browser.
I don’t know if the originator of this abomination is WordPress or FireFox, but only the newer browser supports it, so one fix is a roll-back to an older browser. More likely I’ll just go exploring {Brave, Pale Moon, SeaMonkey, etc. etc.} to find one that respects me as the guy with Root Access….
There was more stuff I had to shut off in this browser too. Including a special needs assistance feature that looks like it also allows folks at other sites to monitor what you are doing to “help you” if you are disabled. (FF even says it’s a security issue in their control panel…) Plus it is set to auto-update and tell the provider all about your browser usage “to improve the product”.
So just realize if you go the this Latest, it’s not the Greatest….
Well, enough of that.
I’ve now got my usual environment (more or less) available for use on the RockPro64, and I’ll be “living on it” for a few days to see what is sand in the teeth and find out if anything tends to blow up.
Overall, it’s nice; but I’ve been reminded again of why I’m not keen on Ubuntu based releases… Even the Armbian Ubuntu is a bit, er, oppressive. (This is where the lack of diversity in OS choices starts to bite… It will improve over time, but for now this is what I’ve got).
Now back to my non-tech non-experimental regular programming ;-)
Hmmm…. after posting that note (which also forces me to log-in as user since wordpress knows I’m saying I’m me), the “windowshade” is gone…
I’m suspecting that may be a WordPress mis-feature… using some newer browser features. So now I’ve got a 3-way hunt to find out how to quash it.
BUT, there is also this annoying “window shade” thing that someone else had mentioned a while ago, but I didn’t realize what they were talking about.
Yep not sure what the trigger for it was, I got the impression is was triggered by passing your mouse cursor over one of the right hand wordpress adverts. Once started the only way I could make it go away was to restart the browser (which on my setup automatically clears cookies) I just quit checking your blog on firefox and started doing it in Brave browser and I never see it here.
Larry – one way to get rid of that shade is to right-click on it, select “inspect element”, and you’ll get a line of code highlighted. Delete that line, and the shade disappears. For a while, anyway. It says it’s a sticky ad.
Found out that “htop” has config options to show each CPU freq and the chip temp. F2 to get to the config panel, then click the “done” button at the bottom when done.
Also, just launched FFox in my “usual home directory” and all 6 CPUs are pegged at 100%. System is still responsive, but clearly something in FFox is open looping.
I’m going to play with some of the settings… I’ve seen this before when it was unhappy about the spell checking / dictionary being gone or some such.
Even with all cores pegged, the temp is staying at 57 C. It will not be possible to overheat the RockPro64 with the big heat sink on it, even without a fan.
Well, back after a bit of playing with FFox settings…
Hmmm… logged in as the default user made during install I don’t get the “all cores pegged” from firefox, but I do get the advert pull down thing and side ads. On my account, that FireFox complains that my ad block extension is no longer supported in the newer FFox and wants me to delete it… says it is deactivated.
I’m not particularly interested in deactivating it as it still works in other systems (same home directory mounted on all the various computers I use / test and all their OS levels and FFox levels…) But now I’m wondering if FFox has, but just deactivating them, made an openloop event. (They deactivated a couple of others too and complain that my dictionary is “no longer supported” – it’s a dictionary, fer Crissake, it’s not like it needs new words added weekly…)
So, OK, one “lesson learned” is that the very new FFox is more hostile to folks like me who want to not change things a lot and like their ad blocker extension…
So I guess when test driving the RockPro64 on Armbian / Ubuntu I’ll need to either log in as my alter ego, or use Chromium in my home directory.
Sidebar: Yet another reason for ALWAYS having ‘htop’ running in the corner of your screen. Let’s you keep tabs on runaway processes as well as watching for “unusual” processes that might be a hacking attempt. With the core freq and temp displays turned on it’s also a nice “state of the system cores” tracker too ;-) Running 42 C and with the two BIG cores at 600 MHz as I type, only the .little cores at full 1.4 GHz. So this tells me that you can get FINE browsing response out of a 4 core A53 board with 1.4 GHz or better. For “Daily Driver” simple web stuff, the two A72 BIG cores are just idle. No sense buying them to have them do nothing…
I do note that moving windows around or using the mouse wheel to roll the FFox page up and down DOES fire up the two BIG cores to 1.8 GHz, but the CPU bars don’t go over 30%, so no idea what makes the scheduler things it needs to kick them in, but the CPU loads shown show they are running as less than an A53 core of load… I suspect that’s just an artifact of the FFox kicking graphics activity and something in the OS thinking graphics means “Fire ALL the cores up!”…
So, for general purpose use, it looks like Quad Core A53 or better at 1.4 GHz or better is quite enough. While it’s nice to have the 2 x A72 cores at about 2 x that A53 speed, it looks like they mostly only get used on heavy compute tasks (Science, Math, Compiles) or heavy graphics loads. I’ll have to find a goo sound output method as my DVI monitor doesn’t work … then I can see what happens with videos. Or I suppose I could just run one and not worry about sound being dead…
Just clciked over to YouTube to run a random and was greeted by this happy news: My add blocking DNS worked ;-) It is showing all the videos to click, but the advert panel at the top of the page says:
I block everything at *.doubleclick.net ;-)
Well, running videos doesn’t load up the cores much, about 3 @ 25% or so, OTOH, they all run like in slow motion… Looks like the YouTube / Video support “needs work”…
It’s really bizarre in that it isn’t pixellated at all and not showing any signs of low data transport rate – just very high quality video going
vveeerrrryyyy sssslllllooooolllllyyyyy….
So, for watching videos, at least for now, it is some other more mature board with a more mature port of software that’s had not just the basic “made the OS boot” done, but the QA folks found video and sound dead so fixed it, too…
My guess is that the video driver is not the optimal for this board and while it’s good enough for general screen display, video modes are sending it into some odd behaviour land. But that’s just a guess.
So, for now, videos get watched on “some other system”… (I like the XU4 for videos, things in the R.Pi M3 class were a bit limited on resolution – 480p was about it for quality non-pixellated and it liked small window sizes…)
So it looks like maybe I need to see if there are any OTHER OS choices for this board, other than the default Armbian / Ubuntu, and see if they can run a YouTube… or does this board sit at the side of the desk waiting for software to catch up while I go back to using the XU4…
If I can’t watch videos on it, and I can’t use the FFox browser “as me” without open looping the cores, well, I’m not willing to move wholesale onto the board. I’ll still use it for “compute heavy things” (it would be a great SW Build system) but it’s out of the Daily Driver business until I can get an OS I like (that treats me well too) on it.
For someone doing a new install of an account from scratch (no legacy FFox issues) and who doesn’t care about videos, and likes Ubuntu w/SystemD; it’s a fine choice…
With that, I’m off to lunch, catching up on comments, and doing a search for alternative OS choices. I’ve been thinking it would be good to learn how to “roll a distribution of Devuan” using their kit (they have a ‘design your own’ kit ;-) so maybe this is time for it…
Well, I just tried out DietPi, Debian, and Ubuntu on the RockPro64. I was not impressed.
Debian had issues with not loading some RockPro required binary so the modules are likely not right. Ubuntu LXDE would not attempt to boot at all. DietPi would boot, but somewhere along the line it wouldn’t launch LXDE or XFCE… so only one terminal and no windows…
For the DietPi build it may be that I did an apt-get install LXDE then realized it requires me to use their clunky ncurses software selector / installer so it may be that a new, clean install, with the mandated 3 or 4 ( I lost track) reboots might eventually give me a windows system…
So as of now, it’s basically Armbian that gives me a reasonable environment and mostly works, though video is slow…
This isn’t that unusual on a new board with young software. It can also change in days or weeks as folks fix things. Usually inside a couple of months after a new board ships in some volume things start to work well.
Sometime tomorrow I’ll try the Gentoo build…
I was wondering if the complete failure to attempt a boot by a couple of OS types, including NetBSD, might be that my uSD card was “toast”… so re-installed Armbian on it (using it to type this…) and it worked fine.
But then another thought wandered by…
This is a high end board. Folks who buy it are likely to be pushing performance as much as they can. That would be including the developers. It has emmc ability.
How many of these images might be designed for the emmc boot and not uSD?
It is quite possible that the “complete failure to boot” is due to the different boot code used on the emmc vs uSD and that either being unclear in the download page, not mentioned at all, or my failure to read the README (or whatever) to know it.
In any case, since I didn’t order an emmc card, I can’t test that theory. At least on the Odroids, loading an emmc is exotic (i.e. uses strange and specialized commands). I have no idea how Pine / Rock handles it. So with that I’m going back to some of the sites where I down loaded images, and to the Pine / Rock site, and do a wee bit of learning about how they handle emmc vs uSD boot… and is that possibly what’s going on. I can’t imagine that many Good Names shipping complete “fails to even boot” images. So “something is wrong” – and Occam says it is most likely something I’m doing…
(There is a remote possibility this uSD card is going dodgy or the reader is, but it just happened to work fine on DietPi and the reload of Armbian… but I doubt it. ;-)
Well, nice idea but…
While some of the images are tagged as just one kind of boot, most say emmc / micro-SD which implies does both.
http://wiki.pine64.org/index.php/ROCKPro64_Software_Release
So we’re back at corrupted flash of the uSD, or the images just don’t work right….
FWIW, Armbian is one of my preferred images so I’m happy with it. This is more about measuring the degree of finish of the available SW than actually needing any of them.
Well, that’s a nice surprise!
I just did the “dd” of Slackware / xfce onto a uSD, and booted up. Works fine. It did seem to boot, then just shut down, when re-powered (power cycled) it booted again, this time to the widow for login. I assume that’s normal install “expand the SD” card, reboot kind of stuff.
I discovered that the FireFox is configured to NOT run if you launch it as root… Added the “me” account and all was good. I’ve now got FFox open with 28 tabs and memory is at 600 MB out of 2 GB. I’m happy ;-)
I mounted a 2 GB swap partition from a USB 3.0 drive, but at 600 MB for a full browser and OS, I’m thinking this is not going to need swap much ;-) It has FFox 60.3.0 ESR (Extended Support Release), yet seems VERY fast and “snappy” in use. Clicking around on a half dozen tabs memory jumped up to 750 MB, but has started dropping now that I’m typing agai. Down to 741 MB, so I think some kind of memory release on stale pages is happening. Now 736 MB.
Dragging a window panel has lag / jitter to it and one CPU heads up toward fully loaded. I think they are doing the graphics processing in Software not in the GPU (common in new boards). Opening the page with “Music while Paris burns” jumped memory to a bit over 1 GB. Trying a few videos, they display the teaser picture, but click play you get the spinning doughnut and then an error message. Looks like Video “needs work” still, but at least nothing crashes!
Slackware is a “slow to adopt new things” release that likes to keep things “The Unix Way”, so has the BSD style rc.d init system I’m happy with that. Never had SystemD, never will… (Hey, they didn’t see a reason to move to System V init back in the ’80s so why change now? ;-)
I need to learn how to add packages with it. I’m pretty sure they are source packages, but last time I used Slackware it was a single tarball of everything. You just “got it all”. This package has the xfce desktop and I’m OK with it. I like LXDE a bit better than XFCE, but not a lot. I expect I’ll try this release for a little while as my Daily Driver (with videos on the Mac… or tablet) while I poke around on how to change to LXDE.
I’m quite comfortable with this system at the moment. What’s not to like? Instant GUI desktop. Snappy fast browser. A very clean init system devoid of SystemD crap. Yeah, the GPU support needs to show up, but that’s going to be the dtb Device Tree Blob and it looks like nobody has one yet that’s exactly right. I found a uboot page where they were discussing it and it basically said “we’ve got enough for now and the rest can show up in v2” that I took to mean Version 2. That was from a month or two ago, so matches current state from what I can see. Meaning nobody will have good video yet.
In summary: Success with Slackware! And it meets all my major criteria only missing Youtube Videos.
Hmmm…. Popping the Jerusalem Post article from “Tips” (that hung the browser on the Mac as it swapped excessively to SD card) popped memory to 1.4 GB. Closing the “some videos” window it’s dropped back to 1 GB, so somewhere in this release of FFox (or perhaps in the one Slackware tuned up?) it IS doing garbage collection and releasing memory. But still, one page makes a 400 MB memory useage jump? That’s horrible for all those machines with about 1 GB or less.
Somebody needs to remind web page designers about “Page Weight” and communications speeds…
But at least I can see why so many 1 GB machines are ‘suddenly slow’ for browsing. With a couple of heavy page weight tabs open, everything is coming out of swap… Lots of slow I/Os there.
So, note to self: For desktop daily driver, have 2 GB memory or more and mount a fast Swap Partition of 2 to 4 GB if you do a lot of open tabs at once. At least in FireFox…
Still, the RockPro64 handled it all just fine, not even rolling to swap yet. Only the non-GPU video is an issue, and it works, but is just way slow. (The video of “Occasional Cortex” dancing on the Jerusalem Post page DID play without error messages, but in slow jerks… as sw Graphics pegged a single core… so not even multi-thread software graphics…) OK, the GPU use will come in time.
So I’ve learned a couple of things about best desktop size SBC, and that you ought to wait at least 6 months after first availability and maybe a year if you want to use it for high end graphics / video ;-)
For the rest of my stuff, it’s looking like a pretty good desktop machine.
Well, looks like arm64 Gentoo exists for R. Pi:
https://www.raspberrypi.org/forums/viewtopic.php?t=188448
I’m going to give it a go and see what it’s like on the Pi M3, then see if I can port it (or if there’s a similar release) to the Rock64 (ought to just run with the right uboot/modules ) and if not, as Gentoo is a source build, I can just compile it (about 4 hours) and put that userland over a known working uboot/kernel for the RockPro64 (and move the modules over…) though some care will be needed about library release levels perhaps…
Not particularly looking forward to learning the Gentoo package system and naming convention (that’s a bit different from everyone else…) but they do seem to have the best and earliest support for new and odd hardware.
Overall, today is a reasonably happy day. Slackware as a non-SystemD release is working and does source builds so it meets my interests / needs. Gentoo has a source build as well with OpenRC instead of SystemD and it, also, looks to be working (with some mix/match maybe). Armbian (potentially with a Devuan Uplift) works. So a reasonable set of choices are available.
Also the Uboot options will only get better as will the use of the GPU. I’d guess that about 6 to 9 months out we’ll have better graphics / video on the RockPro64.
It also is likely that in 6 mos. to a year support for arm64 chips will be mainline and common and folks won’t need to do things like roll their own.
I think tomorrow my PSU for the Rock64 shows up. If so, then I can do more testing of it. The software ought to be much more mature and my expectation is that it will make a nice desktop without the need improved drivers ore GPU support.
The work plan from now to next week is more Gentoo and trying the Rock64 as Daily Driver.
I’m downloading the Gentoo R.Pi image now, the updated one from the link referenced above. In the notes it has an interesting bit on speed. Claims video works without the low res / halting at high res and talks about hardware math:
https://github.com/sakaki-/gentoo-on-rpi3-64bit#pi-top-image-genpi64ptimgxz
So built with optimization level 2 (and you can go higher with a longer re-compilation time) is pretty good and then all that hardware floating point working! This could easily make the R.Pi M3 outperform “hotter” boards on things like video when the hotter board is doing software GPU processing and not using GPU math…
In a couple of hours I ought to have an update / report on it.
As this is an A53 build, it ought to run on the Rock64 too, with change of the boot loader and binary device tree modules… Though looking for an already running Stage3 tarball ought to be easier (if one exists).
Since the RockPro64 has 4 x A53 cores and 2 x A72 cores, it would be a reasonable model for doing a Gentoo build for that board. Major issues being getting the .dtb device tree stuff right and kernal modules; then whatever changes are needed for the A72 cores, like does “-mtune=cortex-a53” need to change, or what? They are both v8 cores, but the whole point of the tuning parameter is to let the compiler make special allowances for special hardware and those A72 cores have more “predictive” path abilities… As that is what makes them faster (in part) it would be nice to use it… I have no idea if there is something ‘special’ you need to do to make an operating system run well on a chip with heterogeneous cores.
Well, download completed, so time to do the install / reboot / testing stuff…
Well I’m impressed.
This is being posted from my R.Pi M3 in the Gentoo build.
I just ran a video full screen 720p and it was reasonable. The CPU cores were pegged, so doing things like a mouse wiggle would cause a bit of jitter in the video as processes swapped and interrupted, so OK, not going to have it multitask while running video, BUT:
The big thing is it WORKED including sound(!).
This is on the developer build of FireFox that is the included browser. It seems a bit slow in general (or maybe I’ve just gotten used to browsing on the XU4 / RockPro64 ;-) but not bad. Just minor hesitations at times. At startup of YouTube (when you click to play a video) it puts up a yellow nag at top of screen to tell you some script is slowing down your browser. I got to click it twice to go away before the video finally loaded. I’ll need to try picking “stop it” next time as see if it is the video launch being slow or the following:
It looks like when the “windowshade” loads you get data transferring from ssl.gstatic.com, so i’ll need to see if that is important to anything else and if not, add it to my DNS block list. It seems to run constantly… Likely browser performance would improve a lot if it were not sucking up performance…
Default keyboard layout is Great Britain, so I’ll need to change that eventually as the ” key gives a @ if you don’t ;-) but full directions are in the download page.
It’s about 8 GB “all up” but includes a full Genoo build environment / tree. Essentially it’s everything I’d though of assembling, already done. It has some minor buggy bits as arm64 in general is still being shaken out on Gentoo. For example, one time I clicked the “full screen” box in a video and FireFox crashed. Is that the OS, or the developer build of FF? Next time it worked fine, so …
FWIW, at 480p in a “theater” window the cores were less than 100% used, so very serviceable video is easy. Even full screen 720p was liveable with only minor “jumps” when lots of complexity happened in the image changes and the whole decompression map changed..
So for me, for a while, this is going to be my Pi “Daily Driver” as I check it out.
At present, I’m using Armbian/Devuan (Armbduan) on the XU4, Slackware on the RockPro64 and Gentoo arm64 on the R.Pi M3. It will likely take a few days on each to decide what will be the winner going forward. Default will stay Devuan for any board with a downloadable Devuan build available (until something shows as clearly superior) https://devuan.org/
FWIW, my one major thing that prevented me from just using the Pi M3 as my main Daily Driver was lack of video / sound usability. Just not a decent video possible on the other OS builds. This Gentoo build is using all the math hardware and looks to have “cracked it”, so hopefully the other folks doing builds can see what Sasaki has done and pick it up.
Yeah, as soon as I logged in to WordPress as me, the windowshade went away AND the “downloading data from ssl.gstatic.com” message. FireFox has also lost a bit of the sloth I was noticing before. Looks like figuring out who’s pushing the windowshade and killing it is a big win.
So for now I’m going to build my environment on the Pi, try it on the monitor that uses an adapter (supposedly it does sound out both the HDMI and audio jacks so I ought to be able to do video to that monitor and sound to it via the audio jack that it uses), and get it more customized to me. Then I’m going fishing about gstatic to see who / what it is and can I block it without issues.
The powersupply came today for the Rock64. I’m using it with the Chromium browser to post this.
With Chromium running, and 4 tabs open (this one, and two heavy with videos and stuff like the “Some Music” page, plus a running YouTube video in another tab) memory usage is at 1.07 Gig and nothing is in swap.
The Htop shows a 1.3 GHz clock rate (and I thought it was supposed to be higher than that… so maybe some config thing to tweek).
The Youtube works for both video and sound to the TV. At resolutions about about 240p you get lags and frame jitter (the image jumps from now to a few seconds later leaving out the motion between them…)
So far the software is acting relatively mature and without strange issues. This experience is kind of like running the R.Pi M3, but a little faster. No surprise as it’s clock is a little faster (than my old one… the newer PiM3 is 1.4 GHz iirc)
I suspect video rendering isn’t using all the GPU processing it could. The Pi M3 with Gentoo and full fancy math hardware in use ran faster videos at more resolution. (It just isn’t quite stable yet… so I’m thinking maybe putting Chromium on it would work well in the lower memory and not swap so much).
Overall, I like this board. It just works.
FWIW, I also bought a $1.75 or so heat sink for it. Running the cores at 75% to 100% with the video in the background as I type, temp is only 70C. This is inside a case, too.
In general I’m happy with it.. While I’m not going to use it to watch HD Music Videos, it is quite enough for the general information video checks I do on posted videos in the blog. I don’t really need 1080p for some talking head or pie charts ;-) Being able to run them at all is enough (and an improvement over Raspbian where sound was a garble…)
So IMHO an adequate desktop for modest use, low res videos and blogs / browsing. It runs cool and works in a stable way. There’s a lot to be said for that.
I may try some “variety OSs” on it later, but for now I’m happy as it sits with Armbian. I’ll likely try the Devuan “uplift” in a few days… I’m also going to be trying the USB 3.0 with a disk “soon”, but unless it fails in some way won’t say much about it.
For the money, it’s a nice alternative to the Pi M3, with 2 GB of memory and USB 3.0 increasing the things you can do with it.
Swapped over to the DVI / HDMI adapter monitor. Video works, no sound. No sound via the mini-phono plug either, so either some config needed or maybe just no sound on that rig. OK, videos from this board on the TV only… I can live with that…
Odd, BOOTING on the DVI / Adapter does NOT get working video. It boots into headless mode. Strange. So, OK, it does some kind of probe at boot, doesn’t get an answer it likes, so stops using HDMI. Got it. So this puppy goes on my TV Only… That’s OK as I usually have that on either for TV news or doing something on a computers. Happy to have this one be The One On the TV. Then every thing that can use the DVI/Adapter to HDMI will go there.
Interesting…. I’ve found an ebuild (build recipe sort of) on Gentoo for Pale Moon and even Seamonkey, thou Seamonkey is on ARM but not arm64 (yet…)
https://packages.gentoo.org/packages/www-client/seamonkey
I know Chromium is on it as I’ve seen a Chromium browser. though this says it’s limited to Intel:
https://packages.gentoo.org/packages/www-client/chromium
There’s an arm64 FireFox, but with ‘yellow’ so likely has some kind of issues in the build:
https://packages.gentoo.org/packages/www-client/firefox
and it is a 52.9 back level..
Interesting list:
https://packages.gentoo.org/categories/www-client
Looks like Vivaldi has a port, though limited to ARM (no arm64) and of course Intel… and the ARM build is coded “yellow”.
https://packages.gentoo.org/packages/www-client/vivaldi
In general, it looks like arm64 is “thin” and even arm has a lot of yellow status (whatever that means). For a general purpose OS on ARM or arm64, a well working reliably building browser might be hard to come by. It’s looking like Gentoo on ARM is best left for “experimental” and play space…
Looking at the Lubuntu uSD it claims an EFI file system (EUFI) and an aMd64 nor an aRm64… so now I get to go back and see if I blew it on the download of some images and didn’t get the right axx64 or if they wrong thing was packaged…
So some of those “didn’t boot at all” may not be correct…