gounthar

Buying a fast board to operate it slow is an option? Really?
 
I would cap max frequency of the big cores from 2.0 GHz to 1.8 GHz or maybe 1.6GHz (/etc/default/cpufrequtils) and then check again. The upper DVFS operating points have to use a much higher voltage to get CPU cores working stable so the amount of heat the SoC dissipates at the top clockspeeds is much higher than slightly below.
 
I would prefer a 5% or 10% performance drop instead of running slow all the time.
 
And yeah, the fansink is a joke since not sufficient to provide appropriate cooling. With demanding workloads throttling will always occur (you can't run anything really heavy at 2.0 GHz with the fansink) and the sound is annoying.
 
BTW: To diagnose and optimize behaviour running 'armbianmonitor -m' in a shell is always a good idea.
 
In case the CPU cores run at high clockspeeds with ondemand even when idle this might be another occurence of 'sampling_rate' being inapppropriate with recent kernels.

I would never buy a S912 device. Pretty underwhelming 'performance' especially with single threaded applications that land on the wrong cores and the usual Amlogic cheating: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md#the-bigger-picture
 
And if you buy cheap TV boxes it shouldn't be surprising that components inside are also cheap. Same with SSDs BTW

Rock64 (but their eMMC is neither super fast nor would I trust too much into it). Based on your other post the obvious choice is still Rock64 + their SATA cable + a great SSD.

mSATA defines two sizes and both fit. Each JMS578 chip on the expansion board is just like an 'external USB disk' so all the information available talking about USB disks also applies to the situation here. If your Zero has SPI NOR flash and you manage to burn u-boot into it you can load everything else from USB. But this requires you doing some research and is not automated by nand-sata-install (what a stupid name these days).
 
If there's something I would put my swap on it would be the fastest storage available (especially wrt random IO). On those USB2 boards without superfast eMMC that's always an UAS attached SSD.
 
Compare here with there:
Close to 3,000 4K IOPS with a good SSD behind a good USB-to-SATA bridge (like JMS578) behind an Allwinner USB2 port A SanDisk Extreme A1 SD card behind a standard (bottlenecked) DDR50 SDIO controller only scores ~1000/~2500 4K IOPS. It would need a better SDIO interface mode for better performance but that's nothing any of those cheap Allwinner boards provides On boards with super fast eMMC this is also an option. Recent Samsung 5.1 eMMC provides +7000 4K IOPS (see ODROID-N1 numbers -- you have to divide numbers through block size to translate from KB/s to IOPS) If you avoid cheap crap SSDs it's 100% save to use them since unlike SD cards or USB pendrives you can query them about their health and replace them before they finally die. The magic word is SMART: https://forum.openmediavault.org/index.php/Thread/23724-Run-OS-and-database-on-SD-card-to-prevent-HDD-spin-up/?postID=180003#post180003

Nope, using hdparm for 'benchmarks' is just fooling yourself. A 'benchmark' that lasts only 3 seconds is a joke. With hdparm you generate numbers without meaning. It's great to generate data but there's no information. And focusing on sequential reads only is strange anyway (since this is most probably not what you will ever do with your application later?).
 
The 850 EVOs show excellect random write performance so why do you sacrifice an USB3 thumb drive to potentially slow your system down (is it swapping?)
 
BTW: With mainline kernel sequential writes and reads will exceed 37 MB/s (maybe even more after increasing DRAM clockspeed) but I ran into the problem that for whatever reasons the JMS578 controllers on the board weren't detected as UAS capable (which is bad since it affects both sequential and random IO performance especially with SSDs).

Well ... I have a msata connected to the NAS device ... and these are the numbers:
 
Now, with a real mSATA.
root@orangepizero:~# hdparm -Tt /dev/sda1 /dev/sda1: Timing cached reads: 684 MB in 2.00 seconds = 341.73 MB/sec Timing buffered disk reads: 92 MB in 3.02 seconds = 30.47 MB/sec As can be seen .. it is a little slower than the WD Blue hard disk with my custom cable, but so near that can be a comparable speed.
 
The disk is a V-NAND SSD 850 EVO 250GB mSATA from SAMSUNG (i.e. a good device).
 
Now, the two main reasons this setup is a good one:
 
1) No spin-up electricity consumption.  Although not so detailed checking (I don't have better measuring tools), but with a USB power tester, the machine maximum consumption was around 0.80 Amp from start-up, including the hdparm test.
 
2) Look at it (picture bellow) ... no SATA cables, extremely compact.
 
About my configuration:
 
This setup has also a SanDisk Cruzer Fit USB 3.0 8G Disk (the short one on one of the USB ports --- the one is not shared with the mSATA device ---).  This is for the swap and other temporary stuff, so I don't need to degrade the OS SD card by constant rewriting there.  And a 3A power supply.
 
And it is important to add some screws on the mSATA storage card.  When you put it, the card remain at 45 degrees from the NAS device plane, so you must pull it down and keep there with "something" ... in this case, two Nylon screws with a nut between the mSATA and the NAS, and a short standoff bellow.
 
I still need to add a 5V fan and the case, and my setup is ready to go production (with my particular information system there).
 
 
 

In the meantime FriendlyELEC provides something similar that is also much worse unfortunately:

 
It's an Expansion Board for their NEOs with DC-DC converter and an enclosure. Looks nice but a few details are awful:
According to their wiki page the USB-to-SATA bridge used is a JMicron JM20329 (designed for USB2, therefore lacking UAS capabilities. Insane when you think about that Allwinner SoCs with mainline kernel can make use of UAS even on USB2 ports. A JMicron JMS567 or JMS578 would've been a way better choice) This enclosure would've be the perfect choice to make use of NEO's design. Due to the SoC placement the enclosure could dissipate the heat to the outside by putting a simple thermal pad between SoC and enclosure. Putting a heatsink on NEO and both into an enclosure looks like a joke. On their product page (here or look at the picture above) you see that they talk about H3. Nasty since the H3 based NEO has only Fast Ethernet so it's a pretty bad choice for a NAS. The only NEO suitable for this use case fitting in that enclosure would be H5 based NEO 2. But on the other hand: if you're already bottlenecked by ultra slow network the crappy USB-to-SATA bridge doesn't matter any more. FriendlyELEC provides an OMV OS image ('OpenMediaVault' claims to 'make NAS easy', everytime I tried it performance was horribly low since the necessary parameter tuning hasn't been done -- I hope FriendlyELEC looked into this). This OS image is based on kernel 3.4.39! Are you kidding me? Why not mainline kernel for this? There's not a single reason to use a smelly Android kernel with this use case (no display and no audio) and especially not that outdated/unpatched 3.4.39 when there's a community patched 3.4.113 also available. I'm sure this thing will sell even if it will perform badly. And of course it's better than any Raspberry Pi based NAS but it's really sad that FriendlyELEC starts to target a clueless audience. If there would be a better USB-to-SATA bridge inside this thing combined with NEO 2 running mainline kernel and a custom OMV build that sets parameters correctly would make a great low-end NAS. Unfortunately we're talking about something different here
 
Screenshot showing kernel version used on their OMV build:
 

Well, on the first pages of the mainly mis-used 'Orange Pi Zero went to the market' thread there were some idle consumption numbers and everything else depends on usage. See difference between idle and 'full load' numbers for H3 here (and keep in mind that Zero default settings are for IoT and therefore low consumption) and add consumption of connected peripherals.
 
My understanding is that powering the NAS Expansion board through the 4/1.7mm barrel plug should provide 3.3V/5V to a connected mSATA disk, 5V to the SATA power port and also the Zero where this voltage is also available at the power pins of the Type A receptacle (without the usual 500mA restriction of USB2 ports on 'real computers' but providing more -- still too lazy to check schematics whether there is some sort of current control or not). Using Xunlong's 5V/3A PSU should suffice to power board, a mSATA SSD and 2 2.5" disks (one connected to SATA + SATA power port, the other via USB).
 
BTW: 3.5" disks with own PSU need just a small/cheap mechanical converter if the SATA port is already used:
 

 
 
There's a SATA power connector on the board and adapter cables exist, eg. https://www.aliexpress.com/item/SATA-Line-for-orange-Pi-Free-shipping/32248261533.html
 
Please be aware that 4 vendors sell these cables but polarity of the 5V lines differs! See https://forum.armbian.com/index.php/topic/3387-nas-on-banana-pi-need-advice-on-power-supply/?p=24467 for details.
 
Edit: Since Xunlong designed the original Banana Pi and used the same SATA connector on the first A20 based Orange Pi i would assume polarity of the SATA power connector to be compatible to the SATA cable kit they sell. But this needs to be confirmed!

Okay, I took a multimeter to my NAS board.  There isn't conductivity between the host side power and the jack on the board.  There are two diodes in parallel that isolate the NAS board jack from the 5V the host provides.  The diodes are in the direction that the jack *could* supply power back to the host.  The two diodes are Schottky devices, so the voltage drop through them should be fairly low for the currents the Z can pull.  That might be different for an H5 based host.
 
@tkaiser, you probably have better data on that.  My general observation is that the Z uses around half the current of the PC2.
 
I'm going to try powering things on soon.

But not with this Expansion board since it seems (still no schematic available so also still no idea what the 2 USB type A jacks do exactly) SuperSpeed data pairs are not even routed to anywhere (I kept this as a test the whole time since until recently someone else constantly wrote around Zero and this Expansion board yelling 'USB3' without having the slightest idea what he was talking about).
 
Regarding USB front ports connected via cables just do a web search for 'usb front ports unreliable' for example. I had one customer where the admins responsible for the PCs (the minority there, 270 Macs vs 150 PC) put a sticky on every PC they deployed: "Don't use USB front ports, only use those on the back". And a friend of mine who started with SBC recently wrote me after he failed to even boot Armbian and I recommended Etcher (verifying image burning!) that he realized that he can not use an USB3 card reader on his PC's USB3 front ports without corrupted data on SD card while on the back everything was fine. But using an USB2 card reader the front ports seem to be reliable.
 
As usual: Expectations vs. reality. The average user has no clues about cable length, EMI, shielding but expects 5Gbps signaling working flawlessly even under worst case conditions (while it's not that easy, so let's not even think about this NAS Expansion board trying to make use of USB3 SuperSpeed )
 
Edit: Almost forgot: Unshielded USB3 signaling is also great to interfere with 2.4GHz Wi-Fi band: http://uk.pcmag.com/networking-reviews-ratings-comparisons/13179/opinion/wireless-witch-the-truth-about-usb-30-and-wi-fi-interference

Hello, all.  My second OpiZ came today and brought a friend--a NAS shield.  I posted about it over in the "OpiZ comes to market" thread, but it probably makes more sense to talk about the NAS side of things over here and leave that thread OpiZ related.
 
Just looking at the board gives me the same questions as logjamin about the DC power.  Clearly it makes sense to put a 5V jack on the NAS board as getting power over a micro-USB connector->GPIO header->JST connector->drive is suicidal for your data.  I am curious if the 5V jack on the NAS back feeds the OpiZ.  If so, that removes one of the annoyances of the Z--power over micro-USB.
 
The kit I got came with three each: short male/female standoff, long female/female standoff, wide head screw.  The problem is the flange around the head of the screw is so big that it bumps into the SATA connector right next to it--the other two holes have sufficient clearance.  If they had stuck with using a second M/F standoff like in the picture at the start of this thread, all would have been fine.  Trying to save a penny.....  I clipped a small part of the screw flange off so that it could safely clear the SATA connector.
 
I think I'm going to take the board back off and probe out the GPIO connector to see about the DC power issue.  Surely they wouldn't expect the Z and the NAS to have separate power feeds.  That leads to so many grounding problems, it's not funny.
 
@tkaiser, you've asked this in a couple of threads and no one answered you, so I'll take a swing at it.  Yes, you *could* put USB3 over a GPIO header.  Most PC motherboards with USB3 have a header on them for a set of front pannel USB3 jacks.  So, it is doable.  Now, the spacing of the pins and the arrangement of them is likely to be sensitive and need some though (steal the layout the PC motherboards use ).  So, a higher performing NAS hat could work that way.
 
Heck, I should go look into that in more detail....  It might be as easy as adding the extra SS signals on another row of that connector which could yield a backwards compatable setup--where the new NAS board works on older 1x13 hosts and a 2x13 host can work with the old 1x13 NAS board.  Hey, Steven, you listening?  I'll test them for you?  Of course, we'll need a SoC with USB3.....
 
Okay, that's enough rambling.  I'll go fiddle around with the board and see what I can find out.

'1080p video' is resolution but doesn't tell anthing regarding bitrates (depends on encoding/codec used). So you have to check how high bitrate requirements of your media files are. Please note: most people confuse codecs with file/container formats. If you have files lying around with names ending on .mp4 that still doesn't tell anything: https://en.wikipedia.org/wiki/MPEG-4_Part_14#Data_streams
 
The good news: bitrate requirements for most media formats are rather low so even Fast Ethernet should suffice (since this stuff is meant for streaming and the usual encoders are configured to not exceed a specific bitrate anyway -- in case 'the scene' needs higher bitrates than allowed the encoder partially decreases image quality to remain below the bitrate treshold).
 
Fast Ethernet means 8 MB/s at least. With current cpufreq settings in Armbian images actual values might be lower since cpufreq might remain at the lower 240 MHz most of the time. Switching to performance governor might help: http://linux-sunxi.org/Cpufreq#The_.22performance.22_governor
 
But even the 5 MB/s reported by @jimandroidpc should be sufficient for most media files (please remember that there are many Android TV boxes with only Fast Ethernet around and the bitrates that work reliably over crappy 2.4GHz Wi-Fi have to be even lower).
 
I won't comment on RAID used with SBC since I did it too often already. TL;DR: RAID has nothing to do with 'data safety', this is only about availability (business continuity) and people constantly fool themselves with RAID (if you're interested in my opinions a web search for 'tkaiser crap raid availability' or something like that should help).
 
Again: I really hope that Xunlong already prepared a new board with Gigabit Ethernet and Zero form factor since with current Zero the NAS Expansion board seems somewhat strange (the JSM578 is capable of SAT and therefore also SMART, supports TRIM/UNMAP and also UAS which is nice since Allwinner SoCs can make use of UAS even with USB 2.0 when running mainline kernel. Normally you find this feature only on USB3 capable devices). But JMS578's potential is wasted on a board with only Fast Ethernet and crappy Wi-Fi.

My addiction got the best of me and I picked up a RockPro 64 as well.  ;-)
 
OK, back to the cellar...

Impossible to answer if you don't tell your use case.
 
 
https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
 
If the RK3288 claims to run at 1.8 GHz it's less than 1730 MHz in reality and until recently all Linux OS images for RK3328 were limited to 1.3 GHz. We changed this just recently in Armbian (nightlies) and enabled the '1.4 GHz OPP' (1380 MHz in reality) by default while with ayufan images you need to enable higher cpufreq OPP yourself.
 
So usually it's 1726 vs. 1286 MHz which doesn't matter that much since
as you pointed out the RK3288 uses high-end ARM cores while the RK3328 relies on slow A53 single-threaded peak performance of the RK3288 at '1.8 GHz' is ~1550 7-zip MIPS while RK3328 scores ~1000 at '1.4 GHz' sustained CPU performance with the RK3288 without huge heatsink (or fan) will pretty fast drop down to RK3328 levels or below. The RK3288 generates way more heat it's always about 'use case first' -- for a 'Desktop Linux' totally different performance metrics are important compared to the 'NAS use case' or when the board should serve as a VPN endpoint.

install checkinstall
Should build a .deb package for you
 
However following the proper procedures by the dev guys is probably the best bet
 

Your OPi Zero seems to run alltime at 1200Mhz.
 
Please check via armbianmonitor -m 
normally it should switch down (idle) to 240Mhz:
 
root@opi-zero(192.168.6.99):~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 20:20:17: 1008MHz 0.06 0% 0% 0% 0% 0% 0% 70.4°C 2/8 20:20:23: 240MHz 0.05 1% 0% 0% 0% 0% 0% 69.1°C 1/8 20:20:28: 240MHz 0.05 1% 1% 0% 0% 0% 0% 70.3°C 2/8 Maybe it doesnt switch down at the armbian 5.38 with kernel 4.14
 
check  /etc/default/cpufrequtils  for the following content:
 
# WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=240000 MAX_SPEED=1200000 GOVERNOR=ondemand but when it doenst switch down to 240Mhz then try the following command and recheck via armbianmonitor -m  
echo 200000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate A slower cpu could run cooler.

And it seems that you didnt use the WiFi - so you can disable it with the follwoing command in the /etc/rc.local (before the exit 0) :
ifconfig wlan0 down rmmod xradio_wlan rmmod mac80211 rmmod cfg80211 actual I am running a armbian debian nightly version:
 
Welcome to ARMBIAN 5.54.180727 testing Debian GNU/Linux 9 (stretch) 4.17.10-sunxi System load: 0.08 0.02 0.01 Up time: 4 days CPU temp: 70°C I did similiar configurations also on my OPi Zero Plus (non Plus2 but H5) - which also did before sometimes freeze and overheat.

Did someone manage to use OV5640 camera at nPi Fire3 ?

For those of you running a large SBC cluster - what is your solution for powering your boards.
 
I currently have a cluster of 18 boards that I am powering with several multiport usb chargers. My setup does work well but I am looking for alternative solutions. I'm thinking of expanding my cluster to 50 or more boards and I don't like the prospect of purchasing so many of these multiport chargers as they're a little bit expensive. And I also don't know about the long term reliability of my current setup as I have only been going for about 2 months now.
 
I would love to hear about and see other people's SBC cluster powering solutions.
 
EDIT: I'm open to all options but some kind of rackmount solution would be best. A lot of the rackmount stuff is very spendy - and I honestly don't mind that if it can power a lot of units. But I am mostly curious about skipping the powering alternatives that don't use the USB port at all. It just seems the best solution when powering many devices simultaneously.

'in theory' you  could do it on an asus tinkerboard with th 4.4 kernel. I got it working months ago, problem is that it breaks to much stuff and the kernel had so many issues that I kept the project 'on hold'.. From what I know, @JMCC tested it once with the ISP driver and it shouldn't perform that bad. Full HD recording should be possible...
But there's a bit too much 'should' and 'could' so if you need a solution which works now and well tested it's obviously a bad idea. For sure there's some stuff to get it working. And you might compile the one or the other kernel on your own to test it. The isp driver should also work for RK3399 boards with a mipi csi but everything is untested there. 

Just a quick snippet below. The 'video surveillance' use case is the only one where we still use Raspberries. The encoding job is done on the proprietary VideoCore IV VPU, raspivid gets the raw h.264 stream, sends it through the network with netcat (lowest latency) and on some Armbian box the streams are received via netcat and then both recorded to disk and 'transcoded' via VLC so that they can be viewed by any RTP capable client (VLC for example):
# sender raspivid -b 4000000 -t 3600000 -fps 30 -w 960 -h 540 -br 55 -co 25 -sh 25 -o - | nc -k -l 2222 # receiver (needs /bin/zsh) setopt MULTIOS nc 192.168.2.108 2222 >/sata/camera/test-3.h264 | cvlc -vvv stream:///dev/stdin --sout '#rtp{sdp=rtsp://:8554/camera1/}' :demux=h264 The slowest devices Armbian supports (Allwinner A20 boards) can cope with up to 8 or 9 streams at the same time.

I'd use this to get the HDMI output of your DSLR encoded (720p only)
 
https://blog.danman.eu/new-version-of-lenkeng-hdmi-over-ip-extender-lkv373a/
 
Then a raspberry pi or pi0 to do the hw h264 re-encoding

Why do you think so? Most probably it's just a fake card with Kingston printed on the surface and copied flash metadata from a Toshiba card. Kingston was pretty popular amongst fraudsters some time ago: https://www.bunniestudios.com/blog/?page_id=1022
 
Also how should such an app help detecting fake flash that simply reads out some (faked) metadata, looks up in a database and then displays $something? Fake cards use faked metadata. It's pointless to trust in this metadata at all (see my above link).
 
My personal take on avoiding faked flash:
Only buy A1 rated cards any more (since for the 'SBC use case' buying anything else is just a mistake) Immediately after purchase check them with either F3 or h2testw. This test will not identify modern fakes who do not fake capacity any more but use real capacity but are made out of inferior components compared to genuine cards After flashing an Armbian image with Etcher the first thing to test is 'iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2' Why? Since fake cards suck wrt especially random IO performance. The result of such an iozone test might look like this:
root@rock64:~# iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa. Run began: Thu Jul 19 12:36:21 2018 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random kB reclen write rewrite read reread read write 102400 4 1272 1303 7799 7865 6380 140 102400 16384 9837 9640 15924 14124 15921 8077  
The 4k number for random writes (here 140) must exceed 2000 since A1 specs require at least 500 IOPS with 4k block size, iozone reports KB/s and with 4K that means we need to multiply 500 IOPS with 4K to get at least 2000 KB/s displayed. So if iozone reports anything below 2000 here I immediately ask the seller for return/refund since the card sold is not compliant to A1 performance class. Of course it's important to buy SD cards only from sellers who have a 'no questions asked' return/refund policy.

Yes - here's an example:  https://i.imgur.com/ynC6IiP.jpg.  Very simple, and perfect for fitting on a tiny perfboard 

Updated images. https://www.armbian.com/nanopi-fire3
 
Thanks!

I totally agree, it is a really, really nice and powerful little board!  Temperature is a challenge with it, so I mounted a 25x25x10mm fan using thermal tape, and added a small circuit to drive it via the pwm1 line (transistor-controlled from the 5v input rail):
 

 
The fan scales up and down smoothly based on the CPU temperature (e.g., see https://github.com/5kft/nanopi-fire3-fancontrol/blob/master/fancontrol).  Using this with cpuburn-a53 on all eight cores at 1.4GHz it doesn't get above ~85C, and idles at ~35C (fan is running slow and silent at that temperature).  Very fun stuff!