Search the Community

That was a great suggestion. I launched several 4k, 1080p and 640x480 videos in the Rockchip Gst Player, and yes, I see the same behavior in all of them (now that I am looking closely for it) The first frame is displayed statically for ~1/4 sec for the 4k video, and then the video plays smoothly. Interestingly enough, the 640x480 delay is noticeably shorter, but I still see it. I see the same thing when running MPV-GBM. I see the same thing when playing a file on a ramdisk. And, I just launched VLC on my Windows i7, set it up to loop, and i see the startup delay there, too. Based on this test, I'm assuming this is just something inherent in setting up video playback streams. And unless someone has any additional ideas, there is nothing in gstreamer or the Rock64 media kit that I can set to reduce it. So, I'll have to work around it by making sure that the first second of the video is static. Thanks for the suggestion. -Jeff

2x595 or MCP23017 - no problem to switch. Actually 595 as simple shift register can be driven by SPI directly, yet on RPi header (first 10 pins) there is I2C, so no big deal to use MCP23017 instead. Why I have chosen 595 initially? As it saves some pennies and footprint. And it it really simple to send command using "software SPI". And commands are to be sent rarely, no need for high speeds. Concept picture of the automated test device: No spacers are visible. Rock64 is a MasterSBC here, it is to be used to control 8 system under test - SBCs. Each of them connected using 10pin header (power + serial) plus custom SD card adapter. On top of the MasterSBC is a (shorter) SD mux board, micro SD sockets placed on both sides of the PCB are invisible, as I have no 3D model for them (MOLEX 47219-2001 one). Also 4 pin headers would be replaced by JST XH2.54 ones. Yes, instead of single SD shared between all SUTs, newest design has 8 SD cards, and MasterSBC can connect those to SUT or to itself for image uploading process. Of course if SDx card is beeing used by MasterSBC, then SUTx shall be powered of as it will not see and SD card "inserted", will not boot. Next to it, top one its serial mux + power distribution board, with 8 sockets of type Molex KK 254 AE 6410 04AKK 254. Both add-on boards works together. When it comes to use cases, one shall use SPI / i2C interface to program 16 bit configuration word. From msb to lsb: ME M2 M1 M0 SE S2 S1 S0 | P7 P6 P5 P4 P3 P2 P1 P0 Meaning of particular bits: - "Px" is power section control (8 independent ports) - "Mx" is a SD card multiplexer control (8 micro SD cards) - "Sx" is a serial interface multiplexer control Meaning of bits ME & SE: ME : 0 - SUTx disconnected from SDx, MasterSBC connected to SDx pointed by M2-0 ME : 1 - SUTx uses SDx SE : 0 - MasterSBC connected to SUTx serial pointed by S2-0, 7-seg led active SE : 1 - No serial link crossed, 7-seg led inactive So with this design all 8 SUTs can be power controlled at the same time, serial console be connected to one of he powered SUT while at the same time other SD card can be used to upload new image. Examples: Upload image to SD card 3, SUT 5 & 7 working, Master listens to Serial from SUT7 0 0 1 1 0 1 1 1 1 0 1 0 0 0 0 0 Upload image to SD#1 (thus) SUT#1 disconnected, all other SUT are working 0 0 1 1 1 0 0 0 1 1 1 1 1 1 0 1 Upload image to SD#1 all SUT are working (SUT1 do not see SD card, will not boot) 0 0 1 1 1 0 0 0 1 1 1 1 1 1 1 1 Comments appreciated. I am attaching also schematics for anyone wanted to take a look. (now with 595 which can be replaced for I2C connectivity). serial-mux.pdf sd-card-mux.pdf

And works for me. I have created set of regular & mini bionic images for pineh64 and rock64. The thing I am struggling with is that latest kernels do not boot :/ but this is different story not for this topic.

I just purchased a 4GB Rock64. I've tried both the Ubuntu (Armbian Bionic Desktop 4.4.y) and Debian (Armbian Stretch Desktop 4.4.y) distros. I'm finding that the Debian distro is very sluggish compared to the Ubuntu distro. The desktop is sluggish in responding to mouse clicks and in Chromium, a basic web page takes about 3 seconds to display compared to about 1 second with Ubuntu. Is this the same performance difference that other people are finding with these distros on the Rock64? Is there some configuration tweak I need to make to improve Debian performance? Is there another distro that I should check out that would give me better performance?

For example Rock64 takes 0,9A at processor peak. Measured by myself. I will later check other SBCs I have, including Odroid XU4. Anyway the 4mm track I placed on PCB shall be enough to provide 7.5W to each of all 4 SUTs. Or max 30W in total, which better describes reality. But to not overload external power supply, I suggest to use such a board in a way to not start all SUTs at the same time, but boot them one by one, with let's say 2s delay. Then after ~15sec all SUT will be running, but power usage will be on reasonable level. Yes, but spacers will secure insulation. Using EDA for several years already. Long time ago I have started with Orcad, then moved to Protel 99, and now KiCad fan.

Topic: Stability of gst based player using RK3328 Media Script My earlier post today regarding Buster made me recall that I have a stability problem with my gst video player, and maybe one of you can help. My gst-based video application plays one video file that is actually a concatenation of 4 other videos of the same format. A GPIO input selects which of the 4 videos to be played, and the program loops that video until a different selection is made. The seek command in the concatenated video is much faster than loading a new video each time. This is largely based on the examples in the gstreamer/gst-docs files at Github. It all worked, but the program occasionally freezes, anywhere from 20 to 700 minutes into a test. I ran with GST_DEBUG=2 (WARN), and I found a bunch of warnings and errors, including many warning and error messages at startup (some of these may be audio related – I did not have speakers hooked up) frequent frame drops - <mppvideodec0> can't process this frame timestamp issues - <mppvideodec0> decreasing timestamp But, I was never able to see a specific error associated with the program lockup My first guess was that there was a data streaming problem somewhere, so I forced a CPU speed increase from 408 MHz to 1200MHz. No difference. So, I did a clean build using the latest Bionic (to make sure that it was not a random package that I installed that was the problem) and still see the errors. This occurs with several different videos, from 640x480 up to 4k, and using both h264 and h265 encoding. Configuration: Rock64, 4GB board OS: Latest Bionic, downloaded from: www.armbian.com/rock64/ Armbian_5.90_Rock64_Ubuntu_bionic_default_4.4.182_desktop.img (see my other post about my attempt to move to Buster) VIdeo: Big Bunny 1080p, 30fps, h264 from http://bbb3d.renderfarming.net/download.html I installed the Media Script, downloaded from this thread, dated Jan 13, 2019 I installed gstreamer1.0-tools gstreamer1.0-plugins-base-apps libgstreamer1.0-dev X11VNC I stripped the program down to get rid of everything I could (removing config files, keyboard watch, GPIO watch, debug statements, etc) and made a simple player that just loops after 30 seconds. The code is attached, as is the log file based on a GST_DEBUG=2 setting. Anyone have any thoughts? I’d love some advice, or a pointer to a person or group that I could get in contact with. Thanks! -Jeff simple_player_log_bunny_20190720.log simple_player.c

I did a test build using Armbian Buster on my Rock64 TLDR: It failed Hardware: Rock64 4 GB OS downloaded from: https://www.armbian.com/rock64/#kernels-archive: Armbian_5.91_Rock64_Debian_buster_default_4.4.184_desktop.7z Media script: downloaded from this thread, dated Jan 13, 2019 I imaged the SD card, booted, setup a user and password, and connected to wifi. That's it. I then ran the media script, using the first 4 options (system, dev, mpv, gstreamer) and the Armsoc version. The script seemed to run OK, but ended in a message that said there were errors during installation. I've attached the install.log. There are no FAIL, ERROR or WARN messages. The only issue I found was this sequence: Could not open file /var/lib/apt/lists/apt.armbian.com_dists_buster_main_binary-armhf_Packages.lz4 - open (2: No such file or directory) E: Could not open file /var/lib/apt/lists/apt.armbian.com_dists_buster_main_binary-arm64_Packages.lz4 - open (2: No such file or directory) E: Could not open file /var/lib/apt/lists/security.debian.org_dists_buster_updates_main_binary-armhf_Packages.lz4 - open (2: No such file or directory) E: Could not open file /var/lib/apt/lists/security.debian.org_dists_buster_updates_main_binary-arm64_Packages.lz4 - open (2: No such file or directory) I then rebooted and it failed to boot, showing : [FAILED] Failed to start Light Display Manager Per the bootstrap.log, I ran "systemctl status lightdm.service" (the output is also attached) I'm not sure what the error messages mean, or what "Unit plymouth-quit.service not found" implies. So, obviously something in the media script did something to mess up the desktop. Perhaps an old Bionic library incompatible with Buster? So, I was eager to try the new build to see if it got rid of some stability problems I'm having with my gst based player. But it looks like I'm going to have to go back to my Bionic build, unless someone has any idea on how to repair the Light Display Manager and get me booted. Thanks, -Jeff sysctl_log.txt install.log

I wonder if this dependency shows up only if EXTERNAL=YES is selected? Side note, while I am building something I see following error: [ o.k. ] Applying distribution specific tweaks for [ bionic ] /home/op/armbian-build/lib/distributions.sh: line 380: /home/op/armbian-build/.tmp/rootfs-default-rock64-bionic-no/etc/netplan/armbian-default.yaml: No such file or directory [ o.k. ] Applying common tweaks

Speaking of the needed hardware. As I understand you need a multiplexer that will connect a real SD card to some connected SBCs under test (let's call them SUT) and the controller itself. Why real SD? As I do believe there is no point to emulate it. So the HW shall be something like hat on top of one of cheapest SBC, like Rock64 (that I will call MasterSBC), that multiplex: - SD card to USB-to-SD adapter connected to MasterSBC, for writing new image to it or one of SUT for read/write - Serial port of selected SUT to MasterSBC, - Select SUT by applying also power to it, trivial circuit with MOSFET will do the job, controlled by HC4515 chip (4 to 16 decoder) (I suggest to power SUTs via 40pin header) Of course with such mux only one SUT will be possible to control at the time. With this setup, MasterSBC will use native USB to access SD card, using 4 GPIO to select SUT and serial port for monitoring what SUT is doing. Capacity? 15 connected SUTs All easy scriptable with basic python commands. In my free time, I can design such a hat and publish schematics & gerber files here.

Hi, Shall work with any combination of SBS/kernel/OS. Like rock64/default/bionic or pineh64/dev/stretch and others To trigger this variant when selecting image type "server" a new dialog will pop up to specify development image (former config) or minimal. Alternatively simply put following options in command line: BUILD_MINIMAL=yes together with BUILD_DESKTOP=no. Observe BUILD_DESKTOP must be set and takes priority, i.e. BUILD_MINIMAL=yes BUILD_DESKTOP=yes will be interpreted as BUILD_MINIMAL=no BUILD_DESKTOP=yes. When no BUILD_DESKTOP option is given in command line, appropriate dialog box will pop up thus BUILD_MINIMAL may be overwritten. Now the changes are put as PR to the mini branch of armbian/build git repository. https://github.com/armbian/build/pull/1463 Final images for minimal and development variants: root@armbian:~/armbian-build# ls -l output/images/*.img -rw-rw-r-- 1 root root 1107296256 Jul 20 12:12 output/images/Armbian_5.91_Rock64_Ubuntu_bionic_default_4.4.184.img -rw-rw-r-- 1 root root 591396864 Jul 20 12:33 output/images/Armbian_5.91_Rock64_Ubuntu_bionic_default_4.4.184_minimal.img root@armbian:~/armbian-build# I was using following command line for testing (note IGNORE_UPDATES=yes FORCE_CHECKOUT=no shall - to my understanding - only be applicable for testing purposes): ./compile.sh CLEAN_LEVEL=none IGNORE_UPDATES=yes FORCE_CHECKOUT=no EXTERNAL=NO BOARD=rock64 BRANCH=default RELEASE=bionic KERNEL_ONLY=no KERNEL_CONFIGURE=no BUILD_MINIMAL=[yes|no] BUILD_DESKTOP=no

Sounds great for me Could you please tell whene and how its use/testable? Do we need two ./compile.sh lines/starts or only one? Is the seperate branch automatically selected when using BUILD_MINIMAL="yes"? Does it work only for the rock64 or on any sbc?

Booting 5.2 bionic on Rock64 v2 was fine first boot then subsequently future starts crash loops a few times but eventually gets to login. Please let me know what I can do/supply to help. Happy to iterate on it.

Hi. The Armbian site for Rock64 has the Buster release. https://www.armbian.com/rock64/#kernels-archive The release notification includes: "Video and 3D acceleration addon" with a hyperlink to this forum topic. Does that mean that I only have to apt-get install gstreamer1.0, apps, tools and utilities to get my gst program to run? Or do I need to dissect he media script to figure out what to install?

I'll give 5.2 a spin on my Rock64 4gb this weekend. Thanks very much.

So using the old sysfs (/sys/class/gpio/) interface, you "export" a gpio by spitting the gpio number into /sys/class/gpio/export. The GPIO number depends on the board and relevant documentation. Having once found that I need GPIO number 76, I'm migrating code to the new "gpio character device" interface (/dev/gpiochipn) on my Rock64. However, "gpioinfo" shows that hardly any gpios have useful labels, and Google searches always turn up Raspberry Pi results. So, can I just calculate the new gpio identify? Old gpio is 76, all /dev/gpiochips have 32 lines, 76/32 = 2 rem 12, so old gpio 76 is now /dev/gpiochip2 line 12? Edit: I tried this, and it was correct. Is this anywhere documented to be correct in all/most/many/some cases?

I'll for sure forget some of them. It all started with the Raspberry Pi2B(4 years ago now) ... and then ... Odroid C2 (For 3 years my favorite. Clocked at 1.75Ghz, with 128Ghz eMMC and ram OC it's amazingly fast. Low power consumption, good video playback(low display resolution), great gaming on it. Still use it as my SBC laptop, but the VIM3'll replace it Raspberry Pi3B (Not better than the pervious model. Dissapointed by it) Raspberry Pi Zero (+ 2 x Zero W) (was handy, had build a Pi0Camera with it and an audio recorder, got in dissuse) Orange Pi+2 (hated it, I still believed the 1.6Ghz bs, afterwards started to love it for what it is) Tinker Board (x2) (Worst buy ever, too expensive for what it's. First broke, I was so stupid to buy another one without using it much) Khadas VIM2 Max (Too slow for what it is. Otherwise a good designed board when used for what it's good) Odroid XU4 (Loved it. It was my 2nd desktop with a HDMI-hub so I could switch to it when my PC was bussy. Amazing performance and great games. But a lot of issue's too) Rock64 (a lot of issue's, nice on paper but doesn't deliver it's promises) Banana Pi M2 Zero (nice little board, runs too hot to be useful, but had a lot of fun with it) NanoPC T3+ (Love it a lot. Amazing for Blender renders, at a low power consumption. But single core performance is too low, should be default overclocked to 1.6Ghz in my opinion. It can handle it and cooling solution is sufficient) Raspberry Pi 3B+ (What a garbage board. DDR2 with a ok SoC is a bad combination. Bad power delivery, not very useable) NanoPi M4 (My favorite until the VIM3 came, all-round a great board. Too bad there's a lack of Linux drivers for great gaming on it) Rock Pi 4B (First impression was great. But that went away after a while. Many software issues. I hate that I can't reach my eMMC with the big heatsink on) NanoPi DUO2 (Still need to review it, but my first impression wasn't too good. Bad thermals, no hardware video encoding for the camera. This should be fixed by now, maybe a next video someday...) Orange Pi 3 (Ok SoC, badly designed board) Pine H64 model b (Ok SoC better designed board, it's their second try tho) Odroid N2 (Great board, amazing performance and no fan needed. But runs at 12V so I can't run it on my power banks. I use it headless with VNC to do render jobs together with the NanoPC T3+) Nitrogen8M Mini (I don't know yet, no HDMI and all proprietary connectors for everything. It is an industrial board for KIOSK's, but I'd like to see HDMI to set it up easily. It does have great audio assets, amplifier, audio in-out) Khadas VIM3 (My newest favorite. What a performance for such low consumption at 5V. I've got the Basic, so much want the Pro... It's perfect to take with me to do heavy video render tasks. I love it...) Raspberry Pi4B (My biggest surprise ever. Not thinking too much of it. But it's a lot more than I thought. Performs amazing. But still has its faults. I think that's it. In chronological order I bought them. The first 2 were great boards that I still use a lot. But then I bought a lot of them that never delivered what they promissed. Only the XU4 and NanoPC T3+ were great. I started to get them for free to review starting with the NanoPi M4, and those were again very good. Only bought the Odroid N2 after that. Good I review SBC's, I'm saving myself a lot of money now I've spend enough in the past on them. Cheers

Hi. I have a Odroid XU4 with Ubuntu Bionic latest release (5.60), powered with this UPS: APC SmartUPS 750 VA. Apcupsd doesn't work. The problem seems related to the missing /dev/usb/hiddev0. After searching on Google, I found that apcupsd requires this feature enabled in the kernel. CONFIG_USB_HIDDEV=Y I build my own kernel enabling it, but no change. Here the output of the command # dmesg | grep Smart [ 4.125553] usb 1-1.2: Product: Smart-UPS 750 FW:651.13.I USB FW:7.3 [ 4.205622] hid-generic 0003:051D:0002.0001: hidraw0: USB HID v1.10 Device [American Power Conversion Smart-UPS 750 FW:651 On the Rock64 board it works without problem. Here the output of the command # dmesg | grep Smart [ 2.175796] usb 3-1: Product: Smart-UPS 750 FW:651.13.I USB FW:7.3 [ 3.719981] hid-generic 0003:051D:0002.0001: hiddev0,hidraw0: USB HID v1.10 Device [American Power Conversion Smart-UPS 750 FW:651.13.I USB FW:7.3] on usb-ff5d0000.usb-1/input0 As you can see, on the Rock64 board there is hiddev0 hid-generic 0003:051D:0002.0001: hiddev0,hidraw0 and /dev/usb/hiddev0 exists. In the Odroid forum, I found only this post about CONFIG_USB_HIDDEV https://forum.odroid.com/viewtopic.php?f=93&t=28978 Thanks in advance.

Humble apologies to Martin and Tido. I ask for advice and don't take it. There is a reason, age, if I patch things and it works, sure as hell in a few weeks when I want to make a change I'll have forgotten or lost the links to the changes. I have wired in the PCF8574, it works with no changes to the system. Crazy, when all those pins are sticking out of the Rock64, defeatist maybe but it is working, I understand what is going on and I can tidy things up now. If Armbian ever fixes the GPIO I would pull out the 8574 and go direct. It's tidier.

Rock64. Running mosquitto. Running my python script for home automation, measures temps, does a bit of control and uses an SIM900 for SMS outside access with no IP address issues. I've run this for ages with an Rpi doing mosquitto and an ESP8266 doing the SMS part. I tried using the RPi for everything but it can't keep up with the 19200b SIM900. The Rock64 does it beautifully. So, all works beautifully but for pulsing the SIM900 to power it up. I have R64.GPIO which works only if I sudo into idle or python. Otherwise I get the dreaded "cannot export GPIO". So close, so far. My eyes and the lcd are dim from searching for an answer. Trying to add me to gpio results in no gpio found. Surely there's a one line answer to this ?

I must admit to enjoying freecell. Everything is looking like a fudge. I've looked at all the links and all basically say "this does not work properly". I returned a Tinker Board soon after they came out, I assumed that with the name ASUS on it that it might work, but no. The Rock64 tried the same job, screwed on the back of a TV for watching bike racing via Eurosport. That failed too, not reliable. A bog standard second hand Dell running Mint works faultlessly. Eurosport seems to lack enough servers for race day internet and the little boards ( inc RPi ) can't buffer it sufficiently. I do have an LCD running on the i2c bus, as a last desperate move I could add an PCF8574 expander board and use that to pulse the start SIM900 signal. In fact this is probably the best idea, it's using a service that is properly implemented. Watch this space. Just as a matter of interest, this is what is running perfectly right now: mosquitto - brokering many ESP8266 boards 20x4 LCD on i2c - status display so monitor can be turned off. SIM900 - send/receive text messages with no changing ip address problems Android phones/tables works well with mosquitto.

Not quite for the moment but it's looking hopeful. It's very frustrating but I'm retired and this keeps my brain going. Everything has been developed on a Mint PC ( apart from this one control signal ). Move it to an RPi and it drops incoming serial chars. Move it to the Rock64 and it works like the PC then I hit this GPIO problem. Do your libraries still hit the sudo GPIO problem ?

Thanks for a quick reply Martin. You have replied to someone who has spent half a lifetime programming embedded systems since before MSDOS. Linux is new to me, I jumped to Mint when W10 got totally intolerable. ( before MSDOS - that would be 6809 FLEX ) I have many pythons in bin/ I'm using idle-3.5 so do I copy from python python3.5 or python3.5m ? where <same_group_as_user> is the same group as the user you wish to grant gpios: user is me "brian" and there is a group "brian" So - chown root:brian /usr/bin/python-suid ?? Then I'd call "python3-suid MQTTsms2.py" sort of thing. Will this work in idle3 ? Sorry for all the questions, it's working so well I don't want to screw it up at this stage. Rock64 is hard work, I've had so many failures.

https://www.armbian.com/rock64/ Scroll down. All works as AP just fine.

I did builds for RockPro64 and RockPi4B. The latest will need fix for DTB filename. I've also done preliminary trial for OPi-RK3399 and NanoPCT4, this latest also needs tweak of DTB filename. EDIT : For NanoPCT4, it doesn't boot with new DTB, searching for rootfs and get mmc errors, I'm using old 5.1.y DTB for now and will investigate latter. EDIT2: Rock64 is fine without any glitch.

@lanefu Sorry, I forgot to share my benchmark file. I did find out that 7-zip multicore results are not to be trusted on SBC's with different cluster performance. The VIM3 has a very big difference so it only uses 500% of 600%. The N2 has a smaller difference in performance between A73/A53 so uses 550% in 7-zip multicore scores. (also lack of memory is a problem) CPU Miner is good, 7zip single core benchmarks are good. And for me Blender is important too. Reasons why benchmarks can be misleading ---------------------------------------- throttling 32-bit/64-bit Difference in cores A53/A7/A15/A72 distro (ubuntu/debian...) distro version kernel version driver versions compiler version software version/outdated repositories desktop Mate/Xfce/LXDE/... display resolution/headless background processes cpu clockspeed ram clockspeed/latency ram useage/swap/zram process sheduler optimizations for the system/distro crypto engine for encryption Undervoltage config settings Wifi dongle CONFIG_HZ=250 - 1000 or any other 7-zip works a bit better on 32-bit vs 64-bit, it doesn't use all cores at 100% in multi-core scores. The percentage differs with different distro's and boards. So it's not completely exact. 7-zip has problems with big-LITTLE architecture for multi-core benchmark. Better to test the clusters seperately. Blender works a lot better on 64-bit than on 32-bit. It uses 100% of the cores. CPU Miner only works on 64-bit. Works better in Ubuntu Bionic than in Debian Stretch. Blender : BMW render @ 1080p 7-zip : Numbers are average of 3 of decompressing only All tests are done with a fan when necessary so no throttling occurs. 64-bit SBC's Khadas VIM3 |SBC bench result |CPU Miner |7-zip s/c A53 |7-zip b/c A73 |7-zip multi avg. of 3 |Blender Ubuntu 18.04.02 http://ix.io/1MFD 13.10kH/s 1577 2311 10578 42m51s Armbian@1.9S.C./1.7B.C. http://ix.io/1NRJ 48m45s Odroid N2 |SBC bench result |CPU Miner |7-zip s/c A53 |7-zip b/c A73 |7-zip multi avg. of 3 |Blender Ubuntu Bionic http://ix.io/1Brv 11.35kH/s 1564 1879 9988 50m28s NanoPC T3+ |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Armbian Bionic http://ix.io/1iRJ 10.99kH/s 1290 10254 1h10m25s Arbmian Stretch http://ix.io/1qiF 8.55kH/s 1275 10149 1h13m55s Rock Pi 4B |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Ubuntu http://ix.io/1uVr 9.50kH/s 1242 1818 7802 1h17m22s NanoPi M4 |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Armbian bionic hz1000 http://ix.io/1nLh 10.23kH/s 1335 2005 8352 1h13m50s CONFIG_HZ=250 http://ix.io/1BLW 10.45kH/s 1335 2007 8320 1h08m28s Armbionic@1.4/1.8 hz250 1253 1828 7821 1h12m52s Armbian bionic nightly http://ix.io/1pDo 10.24kH/s 1329 1990 8292 1h13m28s Armbian stretch desktop http://ix.io/1odF 8.66kH/s 1350 1977 8400 1h14m12s Armbian stretch dsk nightly //ix.io/1pM0 8.80kH/s 1359 1993 8500 1h15m04s Armbian stretch core no fan //ix.io/1pKU 8.80-8.65kH/s 1353 1989 8461 Armbian stretch core //ix.io/1pL9 8.76kH/s 1354 1988 8456 Armbian stretch core nightly //ix.io/1pLf 8.82kH/s 1357 1994 8494 Lubuntu Bionic arm64 http://ix.io/1oGJ 9.24kH/s CPU Miner 1056 1551 6943 1h28m13s Lubuntu Bionic armhf http://ix.io/1pJ1 1111 1769 7705 2h02m54s Lubuntu Xenial armhf http://ix.io/1oCb 989 1507 6339 2h20m51s Khadas Vim2 Max |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Ubuntu Xenial http://ix.io/1qkA 6.86kH/s 823 1134 6682 1h14m39s 7-zip only 600% of 800% used Odroid C2 |SBC bench result |CPU Miner |7-zip big core |7-zip multi avg. of 3 |Blender Armbian Stretch Core http://ix.io/1pZu 4.65kH/s 1390 5342 Armbian Stretch Core Nightly //ix.io/1pZJ 4.66kH/s 1391 5340 Armbian Stretch Desktop http://ix.io/1q1C 4.65kH/s 1394 5363 Armbian Stretch Desktop NGHT //ix.io/1p02 4.59kH/s 1394 5356 2h38m18s Meveric Stetch No-OC 1337 5223 2h40m00s Meveric Stretch Only RAM OC 1361 5292 Meveric Stretch OC 1548 6049 2h14m17s Ubuntu Mate Bionic http://ix.io/1q2S clocked to 100Mhz 2h35m10s Ubuntu Mate Bionic OC Doesn't work/Clocked to 100Mhz 1607 5960 2h10m21s Rock64 |SBC bench result |CPU Miner |7-zip small core |7-zip multi avg. of 3 |Blender Armbian Stretch 1.5Ghz http://ix.io/1nCj 4.06kH/s 1406 5407 3h00n32s OLD Armbian Stretch 1.3Ghz //ix.io/1iHB 3.80kH/s 1211 4904 Armbian Bionic 1.5Ghz core //ix.io/1qbK 5.00kH/s 1384 5379 Armbian Bionic 1.5Ghz dsk //ix.io/1qcb 4.94kH/s 1379 5326 2h55m56s 32-bit SBC's Odroid XU4 |SBC bench result |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Debian Jessie http://ix.io/1q6X 950 1653 8823 1h12m19s Ubuntu Bionic http://ix.io/1qbL 1219 2094 9395 1h44m19s Asus Tinker board |SBC bench result |7-zip big core|7-zip multi avg. of 3 |Blender Tinker OS 9.5 Stretch http://ix.io/1pRN 1983 7536 2h55m00s Raspberry Pi 3B+ |SBC bench result |7-zip small core |7-zip multi avg. of 3 |Blender Raspbian Default no fan http://ix.io/1q10 1471 5027 Raspbian Default http://ix.io/1q1Q 1411 5371 5h47m31s Raspbian OC http://ix.io/1q5J 1591 6141 Ubuntu Mate Xenial http://ix.io/1q65 7-zip didn't work Software versions ----------------- GIMP Blender GTKPerf SysBench SBC-bench M4 : Lubuntu Xenial armhf 2.8.18 2.79b 0.40 0.4.12 0.6.1 Lubuntu Bionic armhf : 2.8.22 2.79b 0.40 1.0.11 LuaJIT 2.1.0-beta3 0.6.1 Armbian Stretch desktop 9.5 : 2.8.18 2.79b 0.40 0.4.12 0.6.1 Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 LuaJIT 2.1.0-beta3 0.6.1 Tinker : TinkerOS 9.5 Stretch : 2.8.18 2.79b 0.40 0.4.12 0.6.1 Odroid C2 : Armbian Stretch 9.5 : 2.8.18 2.79b 0.40 0.4.12 0.6.1 : Ubuntu Mate Bionic : 2.8.22 2.79b 0.40 1.0.11 LuqJIT 2.1.0-beta3 0.6.1 Doesn't work clocks to 100Mhz Meveric Stretch 9.5 : 2.8.18 2.79b 0.40 0.4.12 Doesn't work Rock64 : Armbian Stretch 9.5: 2.8.18 2.79b 0.40 0.4.12 0.6.1 : Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 0.6.2 RPi 3b+ : Raspbian Stretch 9.5 : 2.8.18 2.78a 0.40 0.4.12 0.6.1 Ubuntu Mate Xenial : 2.8.16 0.40 0.4.12 0.6.1 Odroid XU4 : Debian Jessie : 2.8.14 2.72b 0.40 0.4.12 0.6.1 7-zip doesn't work : Ubuntu Bionic : 2.8.22 2.79b 0.40 1.0.11 0.6.2 NanoPC T3+ : Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 0.4.6 Armbian Stretch : 2.79b 0.40 0.4.12 0.6.2 Khadas Vim2 Max : Ubuntu Xenial : 2.8.16 2.76b 0.40 0.4.12 0.6.2 CPU Clocks ---------- Khadas VIM3 : Ubuntu Bionic : 2x1.8Ghz(A53) + 4x2.2Ghz(A73) 64-bit Odroid N2 : Ubuntu Bionic : 2x1.9Ghz(A53) + 4x1.8Ghz(A73) 64-bit NanoPi M4 : Armbian Bionic/Stretch : 2x2Ghz + 4X1.5Ghz 64-bit Lubuntu armhf/ARM64 : 2x1.8Ghz + 4X1.4Ghz armhf 32-bit / ARM64 64-bit Tinker Board : TinkerOS Stretch : 4x1.8Ghz 32-bit Odroid C2 : Armbian Stretch : 4x1.5Ghz 64-bit Ubuntu Mate Bionic : 4x1.5Ghz RAM 912Mhz 64-bit Ubuntu Mate Bionic OC : 4x1.75Ghz + RAM 1104Mhz 64-bit Rock64 : Armbian Stretch : 4x1.5Ghz 64-bit Armbian Bionic : 4x1.5Ghz 64-bit RPi 3B+ : Raspbian Stretch : 4x1.4Ghz no fan 4x1.2Ghz above 60°C 32-bit Raspbian Stretch OC : 4x1.570Ghz over_voltage=4 core_freq=500 sd_freq=510 32-bit Ubuntu Xenial : 4x1.4Ghz 32-bit Odroid XU4 : Debian Stretch : 4x1.4Ghz + 4x1.9Ghz 32-bit : Ubuntu Mate Bionic : 4x1.5Ghz + 4x2Ghz Underclocks when above 75°C 32-bit NanoPC T3+ : Armbian Bionic : 8x1.4Ghz 64-bit Some benchmark tools can give an estimate of the performance. But they are never an exact reflection.