rooted

Finally, my very own :-)

that's not the same Ranger...
 
Going back to Slant Six - when I was a kid - my dad had a older Dodge Van (the one where you sat over the front wheels, and no protection if you had a front end hit...)
 
It had I suppose 150,000 miles, and it threw a rod...  dad welded up the side of the block in the driveway, ground down the broken rod end, and drove it for 3 more years as a slant five...
 
beast of a motor, even wounded...
 

I have the means to see power usage, as time and situation permits I will test this as well.
 
Thanks for the kind words.

You, @chwe the people
I do watch a lot of benchmarking on Youtube pure out of entertainment. I love Gamers Nexus on Youtube. I don't care a bit about x86 hardware. I'm not planning to buy anything new. But it seems to have an entertainment value that I like.
 
Indeed, a lot of people who are new to SBC's. So I try to keep it as simple as possible, and show how to set up everything for a new user, and what's the best OS available, gaming, video playback, energy consumption, ease of use, ... My viewers seem happy, I almost never get bad comments. I many times get the comment that I've saved them days of searching. So that's what I keep doing.
I try to test as much as possible, and only when I don't know anymore what more to test I make my videos.
Most other sbc reviewers on Youtube make their video after only a few hours of working with them. That's where I try to be different. That also means my videos are later than the more popular Youtubers.(ETAPrime can't even install a simple Linux distro on an sbc, and he's got +200 000 subscribers)
I now get boards for free, and I share my findings with the board makers. FriendlyElec and Radxa have done a lot with my data for the M4 and RockPi4B. I'm happy with that. Other makers don't seem to care as much.
I also don't make a video as long as a novice user can't use a board easily and well.
 
 
I've done a lot more of them with the RK3399. When settings haven't changed Blender has very little changes when done multiple times. (I'll do 3 now with the M4)
Ignore gimp, gtkperf and sysbench. That was just to show you're nothing with that.
I don't think the Rock Pi 4B had CONFIG_HZ=250 but HZ=1000. The NanoPi M4 now did 5minutes better than the RPi4B with HZ=250 at the same clockspeed. So my assumption that the RockPi4B was faster because of faster ram is untrue.  Still need to do more with the RockPi4B. I'm waiting for the Armbian images to mature.
Rock Pi 4B |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender |GIMP |GTKPerf |Sysbench 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 |GIMP |GTKPerf |Sysbench Armbian bionic hz1000 http://ix.io/1nLh 10.23kH/s 1335 2005 8352 1h13m50s 0m29s5 5.06s 26763 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 0m29s 5.12s 26733 Armbian stretch desktop http://ix.io/1odF 8.66kH/s 1350 1977 8400 1h14m12s 0m31s 5.24s 3.1s Armbian stretch dsk nightly //ix.io/1pM0 8.80kH/s 1359 1993 8500 1h15m04s 0m31s 5.32s 3.3s 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 0m57s 6.97s 1666 32-bit Lubuntu Xenial armhf http://ix.io/1oCb 989 1507 6339 2h20m51s 0m59s 49.77s 49.7s 32-bit  
 
Of course @tkaiser has a lot more knowledge than me, and I'd rather see someone like him making good videos to well inform people. As long as that doesn't happen, there's still a place for me on Youtube (TKaiser, the Derbauer of SBC's??)
I don't think he'll ever aprove using Blender, but I also use SBC-Bench. I don't think there's much to say against that. 
Blender does have a few advantages for me. It shows if a system is stable(crashed if not), it takes a long time so I can see the heat characteristics, it uses close to 100% of all cores(7zip doesn't, and this differs a lot from board to board, distro to distro). But small changes can effect the performance a lot.

@rooted I'm also interested in seeing how the H2 does against the N2. Also power consumption while maxed out interests me in both. Until now the NanoPC T3+ has the lead in horsepower per watt for me(I need to retest that with HZ=250 too). I think the N2 can beat it.
But time enough for that. Take good care of each other. May everything be well and safe for your son.
 
That's a nice filosofy to live by, but we don't have faith in our own hands. Health is something we can only be thankful for having it.


 

We create our own future, if you firmly believe that you will be all right-then everything will be fine.

Yes. Best wishes from my side as well.

Sent from my Pixel using Tapatalk

I wish you and your family the best that your son recovers soon. Just ignore all wishes from other users as long as you've more important issues.

Take good care of him. More important than an sbc. Greetings.

Test for yourselves, Hardkernel has 4 N2 on the bench ready for testing.
 
https://forum.odroid.com/viewtopic.php?p=246987#p246987
@tkaiser
I will build the kernel with 1000hz enabled soon and run sbc-bench again.

Blender results BMW render @ 1080p
Odroid N2 @ 1.9Ghz-1.8Ghz                             Bionic     50m28s
NanoPC T3+ @ 8x1.4Ghz               Armbian      Bionic 1h10m25s
The NanoPi M4 @ 1.5Ghz-2Ghz    Armbian       Bionic 1h13m28s
                              1.4Ghz-1.8Ghz FriendlyElec Bionic  1h28m13s
RockPi 4B @ 1.4Ghz-1.8Ghz                              Bionic 1h17m22s
Odroid C2 @ 1.75Ghz 1104Mhz ram                Bionic 2h10m21s
                      1.5Ghz   912Mhz ram                  Bionic 2h35m10s
Rock64 @ 1.5Ghz                                             Bionic 2h55m56s

The difference is huge. The N2 is in a league of it's own here.
You can only compare 64-bit with 64-bit OS's with Blender. And Stretch performs a bit worse than Bionic.
7zip is an ok test for cpu only. Blender is good to see the performance for most daily use(cpu+ram).

It accepts 7.5V ~ 20V according to the specs, powering with a battery pack shouldn't be an issue
 
This range makes it perfect for automotive use, such as a CarPC.

It accepts 7.5V ~ 20V according to the specs, powering with a battery pack shouldn't be an issue
 
This range makes it perfect for automotive use, such as a CarPC.

I'm not accusing you of forgery. This was an example of how many different factors (both often implicit and difficult to track) affect events. 
 
 
 
Maybe I'm not looking hard enough, N2 is WoL ?

I would run it NicoD but the device is headless currently, when I get around to installing the necessary packages to get the UI up I can render the scene and give you the statistics.

I'm running sbc-bench with the cores mildly overclocked, will post those results when finished.

N2 results
 
http://ix.io/1Brv
 
Take these results with a grain of salt since i paid no mind to starting load average.
 
Could someone give me a break down of the results compared to say a rk3399?
 
I have never used this benchmark and have no idea if the results are as they should be.

It's my N2, it's not using a fan.

Ambient temperature is 22.7° C

Thank you for that. It seems like I thought it would be. Quite a bit faster than the NanoPi M4 @ 1.5-2Ghz, but no giant step. Temperatures seem very good, I wonder if they're using a fan. 52°C for cpu miner at 100% is good.
In CPU-Miner it even beats the octa-core NanoPC T3+. This uses 100% of all cores. 
In 7-zip it does a bit worse than the NanoPC T3+. (Only decompression I use) But the T3+ has a higher percentage useage of the cores (795% of 800% - 543% of 600%). So actually they are about equal.
That means that the N2 actually is faster than the T3+. T3+ uses 99% of it's cores, the N2 90%. 
So the (10254 / 100)  * 90 =  9321.81 would the T3+ get with the same % useage as the N2.

Compression numbers are more useless, only 625% of 800% vs 543% of 600%. So you can not use the totals in 7-zip. I find decompression the most value of 7-zip.

Here a list with sbc's I've benchmarked. Note one benchmark says nothing. But you can get an idea with many.
 

 

N2 results
 
http://ix.io/1Brv
 
Take these results with a grain of salt since i paid no mind to starting load average.
 
Could someone give me a break down of the results compared to say a rk3399?
 
I have never used this benchmark and have no idea if the results are as they should be.

I'm running sbc-bench on the N2 right now, will share the results when finished.
 
I did have to alter the script in order for it to run, there is a process called (vdec-core) which is using 4% of a core and throwing off the load average.
 
(I do not have any external storage attached)

Totally agreed. It is very likely that a user's project depends on features that are only available in a certain kernel and not in others. That is particularly true when it means jumping from a kernel that is actively maintained by the vendor (like Hardkernel's 4.14 for the XU4) to a vanilla mainline.
 
Practical examples: A user that has OMV installed on his Odroid HC1 with disk encryption on 4.14 kernel, would lose HW crypto support if upgrading to 4.19 (I think @tkaiser already pointed this out). Or if they have an Emby server with HW transcoding in that machine, it will stop working with the move to 4.19. Or if he has a media player/gaming station for the kids on a XU4. Etcetera.
 
Well, I think everyone is clear on this point already, I just wanted to show my support for the idea of being very careful when making big kernel moves.

Irrelevant.  If someone doesn't recognize the main contributors without such a tag already they'll be too dense to figure it out even with that extra help.  It's a tracking tool, far more effective than guessing.  The entire point is, if the board number is reduced to both vendors and users who give a damn, then we can focus more completely on the task at hand, the quality and consistency of the thing. 
 
Board hierarchy  would go like this:
 
Is a community member willing to "own" it? y/n
Does the vendor support it on their side? y/n
Does the vendor help Armbian in some way (either with the board or generally)? y/n
 
Ignore them, I've seen an uptick in the Amlogic and Rockchip forums of community helping each other.  Necessity is the mother of all invention.  See if it is a legit build system problem, if not, politely say "sorry I can't really help, that looks like a use-case issue" or something similar, and move on.  Or simply ignore it.  The problem I'm seeing develop here is 150% typical for engineering/software/technical sales types:  They expect the user to know too much, and get grouchy when they don't.  Asking questions is almost never done in malice, don't act as though it's a criminal act.  Someone saying they got ignored on the forums is infinitely better than someone saying "I asked a question on the Armbian forums and that Tido guy called me an idiot and said I was wasting his time" (example only, but you get the point). Rules are good, but ignoring unless you have the time is more effective.  Making people fill out a questionnaire before posting a question is also bad, but until now I hadn't seen enough of a reason to complain about it.  Ignore them.  It's honestly quite simple.  They get noisy toss the rules at them, and we live peacefully.  Any of us answering questions is entirely voluntary, including Igor.  Treat it as such.
 
That was my plan in any case.  I need one for my personal projects anyway.
 

As most of us were in the beginnings..
 
I don't guarantee but I think it's not that easy to fry something with a wrong devicetree.. It's a way easier with connecting random crap to the pin-header.
 
Since you want to get closer to group 1 let's give an example:
 
That's the original DT for the RockPi4b (4.4.x kernel) spoiler cause it just messes up to show the whole one for everyone (https://github.com/radxa/kernel/blob/release-4.4-rockpi4/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts):
 
the first few lines after comment tell us which other DT files are included here e.g. (rk3399.dtsi):
#include <dt-bindings/pwm/pwm.h> #include <dt-bindings/input/input.h> #include "rk3399.dtsi" #include "rk3399-linux.dtsi" #include "rk3399-opp.dtsi" basically just another 'layer' of describing hardware, since a lot of stuff is shared with all rk3399 based boards this stuff is usually described once there and the nodes are used again and again for every board.
 
The nodes after it describe the hardware and how it is connected (also partly software e.g. there are multiple UARTs available, a node has to tell the kernel which one should be used to output the debug console).
 
Now let's look at such a node:
fiq_debugger: fiq-debugger { compatible = "rockchip,fiq-debugger"; rockchip,serial-id = <2>; rockchip,signal-irq = <182>; rockchip,wake-irq = <0>; rockchip,irq-mode-enable = <1>; /* If enable uart uses irq instead of fiq */ rockchip,baudrate = <1500000>; /* Only 115200 and 1500000 */ pinctrl-names = "default"; pinctrl-0 = <&uart2c_xfer>; }; the compatible part is the first one which is interesting cause it gives you some hints where you get further information. (https://github.com/radxa/kernel/blob/release-4.4-rockpi4/Documentation/devicetree/bindings/serial/rockchip_fiq_debugger.txt)
From there you get most of the information out what this node does and how it can be configured.. E.g. for the fiq node, it could be worth to set baudrate to 115200 cause this is the common baudrate for all SBCs (except rockchips which often favor higher baudrates for whatever reasons ). So obviously when you connect an USB-UART you've to set it to 1500000 not the default 115200 (keep in mind, if it's patched in the kernel, it should also be patched in u-boot, otherwise things get messy).
 
That's just a short introduction and you've to read a lot of stuff until all this stuff makes sense. Maybe I write something about the buildsystem tomorrow.

Like most things there needs to be a balance, and where there is a balance, few of anyone is truly pleased with the outcome because it means compromise.  The compromise is reduced with more active participation all around. 
 
Now, who is participating?  
 
-Vendors: Almost every vendor has some software team, or they pay for one.  They could spend more time making sure their hardware is well supported here directly, or indirectly upstream (Libre Computer does well here, if only Amlogic wasn't playing games with their firmware)
 
-Advanced Users: OMV-like special distros, products with special hardware where our build system would be advantageous, etc.
 
-Users: buy the board, try our software, ask for/provide help from/to others.  Very important for a project, a bit lacking here.  Of course the bulk of users come from the RPi train and, because they don't care to improve the hardware support, can talk to users all day.
 
Targeting a group in this requires time of its own, but honestly we need the feet on the ground.  It's a paradox, @tkaiser disagrees with the terminology of support, I agree to a point, but also, @tkaiser is adamant about refusing to add shitty boards because of support issues.  I think we are all in this boat, I love seeing what Armbian runs on, hate getting insane questions or dealing with SD card issues, but also don't want to say (or really see someone have the ultimate authority to say) "no, you get no help because we hate your board".  A prime example is the Tinker Board, which somehow has failed to create the support issue even I thought it would despite a respectable download number. 
 
For other issues that have been a gnawing problem:
 
Decouple the kernel updates from the image type.  That way if we move our "next" images to 4.19 from 4.14 is doesn't cause a meltdown.  I'm going to guess this is on the "very complicated" side, but I think boards should maintain kernel number with only patch level increases unless the user specifically chooses to change.  The tag "default, next, dev" would be the build recipe only, ideally.  We require the diagnostic output that gives you the kernel anyway.  (Tinker has to have 2 dtbs because of adding overlays, and mismatch between vender kernel dtb name and mainline). Odroid C2 can never have a kernel update for "default" because there is absolutely no way to properly migrate from 3.16 to 4.19+ .  Etc.

That is a lot of traffic but you don't have to host the downloads, that's why I said necessarily. You can use sourceforge to host all the files, and you currently use torrents which is smart.
 
Thank you for sharing the information, it is interesting to see.
 

 
I didn't realize there was so much traffic but file hosting can be had for free being Armbian is open source. I was strictly speaking of the website when I said 100/month.
 
I think hosting fees is very relevant since that money can be used elsewhere, especially since it seems like it must be expensive currently.
 

Well, it's one of only two with 4 fast cores, the other being XU4.  The RK3399 doesn't even have that going for it.  It honestly is in the top 3 performers in any case, every time I use any other board I get a rude awakening about how bad a desktop experience can be. RK3399 is somewhat better but is still poorly supported kernel wise by comparison.