lanefu

Hi all. 
Since I wanted a 3D intro for my Youtube Channel I started working with Blender again. Now the intro is finished I've got time to try to make a 3D Armbian Logo.
 

I'll show some of the progress here for those who are interested. And if anybody else wants to do the same, go  ahead. We can then compare the results.
I've only just begun. But I needed a break so I started writing this.
Here's how it begins... create a side view ... 


Then put those pictures in Blender, add a cube, position it right on both pictures, and start modeling....

All done with the NanoPi M4 on Armbian Bionic.

I'll slowly keep working on it. I can't promise it will look great, but nothing is lost if it doesn't... Someone once asked me to do this, I can't remember who it was. I think Chwe or jmcc or tido. Could also have been a ghost in my sleep.
Cheers, NicoD

ps: @Igor It would be nice if we could easily resize images in our posts. Maybe with a dropdown box and % would be easiest to do. I know this isn't a priority, just a suggestion. 
 

@lanefu will help around admin duties.

Yes, like @ManoftheSea pointed out above, we are aware that the three onboard ports have a 1gig bottleneck at the SoC. However, with a 1gbps mPCIE card in addition to one of the built-int ports, there is a theoretical 2gbps path. I was only testing the lan0 + lan1 etherchannel group with the sole purpose of trying to get any of the built-in ports to show up in an etherchannel/bond interface (unsuccessfully, so far).
 
@lanefu, I appreciate your experience and insight, and I'd say you're right-on with your assessment of "typical" traffic going to a home fileserver. You have a good point to level-set for anyone coming across this thread, and this most certainly wouldn't be a great option for a HTPC or home media server. From my perspective, however, the Espressobin has a [theoretical] 6gbps path to SATA, but it's a shame the network bottlenecks to 1gbps. In my hypothetical use-case, there would be several hosts simultaneously accessing data on this server. Each of those hosts would have a single 1gig NIC, so of course there would be no point in going above that speed for any single connection. However, as more and more hosts try to access this share a the same time, a handful of 1gig clients could easily exceed a single interface, so an etherchannel would make sense.
 
Also, my experience comes from a work environment where a single link is a potential single point of failure. We don't install anything without redundant links, and an etherchannel is a great way to allow for automated failover in the even of one link failing without having to run some additional heartbeat software. I realize that's probably not something your typical home user is concerned with, but IMO it would be cool to have.
 
One final note along the lines of @lanefu's post, I should mention that in all my tests so far with dual 1gig links to the Espressobin, I am hitting a CPU bottleneck before ever getting close to 2gbps network speed. Obviously I don't have an etherchannel working yet (and I really don't know how that will affect CPU utilization for network throughput), but with one of the built-in ports on VLAN A, and the mPCIE port on VLAN B, using four other test boxes (2 on VLAN B, 2 on VLAN A), all doing reads, writes, or simultaneous reads and writes, I have been unable to achieve much over 100MB/sec total before the Espressobin cores both peg at 100%. I've done a few tests with NFS exports, and a few with NBD exports, but all my tests so far have been limited by the CPU on the server. I'll continue to test and tweak my setup, but at this point, I'm not sure this is the right platform for a high speed NAS server.
 
All that said, I'm still trying to figure out how to add one of the built-in ports to a bond interface... Any suggestions would be greatly appreciated!
 
Edit: Just to clarify, 1gbps (gigabits per second) is about 125MB/sec, minus overhead. 2gbps would be about 250MB/sec, give or take.
 

Firs of all I admire everyone's quest for speed.   Finding every bit of performance available in these boards is a lot of fun.....  But allow me to provide a a brief sermon on link aggregation to manage expectations for those who many not have much experience.
 
So I've gone down the NIC bonding rabbit hole many times on many pieces of equipment.   I even have LACP trunks going to my garage on principle.    It's really really hard to get a performance payoff on bonded gig links.    Single TCP streams are still only sent down 1 link at a time.     So things like iperf testing, most basic file IO tests etc, won't even send traffic on more than 1 link.   The smarter hashing algorithms will load balance the links to a degree typically based on MAC or IP:port for service.   Aka servers with dozens and dozens of clients work well because the bandwidth accross the 2 links can be distributed.  Even protocols like NFS 4.1 and SMB3.0 that have concepts of parallism still don't perform well with just 2 endpoints.    Typically it's been backup servers that are being absolutely pounded at the same time by many nodes at night, or VM hosts that I've ever gotten over 1 gig of traffic on LACP.
 
The best performance I've been able to get using multiple gig links is by properly impementing iscsi with several initiators on a node and multipathing.   Since iSCSI is multipathing SCSI IO calls and not tcp it's able to deal wit the out of order stuff and you can really hammer your links.
 
Best performance bet probably is using 10G and maybe you'll hit a few gigsabits on that.   IMHO I'd just focus on shaving latency down on your services and keep your networking stack simple.    If performance is really an issue... i'd probaly just brute force with a junky intel box.. or by a more purpose built board.
 
PS in defense of the 1 gig SGMII lane using for the topaz switch to the CPU.... that's still 1GIG of full duplex traffic.. aka.. that's 1GIG of potential packet forwarding/filtering between WAN and LAN on the topaz.   In theory it's more potent than my edge router lite....  i'll have to test one day.
 
 

Working on an embedded SBC home automation application with a very small form factor. Size and reliability is at a premium. Just want to have a smart device at the door that will help notify and find me when someone presses the doorbell button, or detects motion at the entrance or curbside mailbox. Two way audio and outbound alerts are progressing nicely but complexity increases significantly when integrating video into the solution.
 
For example, two widely used video trans-coding applications, ffmpeg and gstreamer, may or may not have hardware assisted image signal processing on the SBC. Is any form of image signal processing within scope when a board is supported by Armbian? How is hardware assisted image signal processing qualified within Armbian? I'm trying to set my expectations.
 
BTW. I had the opportunity to follow the Armbian cross-compile recipe and build environment last weekend. I was blown away with how seamless and truly useful the Armbian suite made the entire effort. Thank you to the entire team.
 

So I built some fresh Armbian images with dev kernels, and setup ubuntu mate and ran them on my tritium h5, and my le potato... and like I've got slack running in chromium n stuff, and desktop switching is pretty decent... and that's without acceleration.. just good 'ole brute force.
 
Basically my mind is blown that its usable and I'm going to retire my c2d dell desktop that's on my KVM and finally use an ARM SBC as a desktop!
 
 

Thanks for sharing, dude. That is super cool!

Sent from my SM-G950U using Tapatalk

Hi @lanefu.
I took some pictures of all my tech gear I take with me on trips.

The most important thing is my solar panels(I've got 2). It's a RavPower 24W 5V solar panel with 3 usb ports. Each USB can load up to 2.4A, and a total of 4.8A over all 3 the ports. In a nice sunny day it's quickly at it's maximum power.
Then the RavPower power banks(also 2). These are beasts of 26 800 mAh. With this I can work for 15 hours with my Odroid C2 + 7" display. It does take a bit more than a day to fully charge it with my solar panels. I always use one, while charging the other.

For video editing and rendering I used the Odroid C2(on the right) with a 7" display. This because it's the only one that's fast, and doesn't need active cooling. When it's cold and wet you don't want to sit in a tent with a fan blowing.
The Odroid also has it's own 3.5" HDMI display to watch video that I've filmed on it. So it's also a handheld. The C2 I'll replace with a RK3399 board. I still need to make a new metal case for everything. I also got a 13.3" 1080p display with speakers for the new "laptop"
The one on the left is my Raspberry Pi 2B with a 3.5" gpio display. This has a usb audio adapter, and a Sony lavalier microphone. This uses only 0.25A idle with the display included. So I can leave that on the whole day. It's totally protected with rubber on the sides, and a plexi glas in front of the display. So I can throw it arround and nothing happens. The same for my 7" display. Plexiglass, and then a rubber layer between the glas and the display.
 

For entertainment I've got the Raspberry Pi 3B+ also with a 3.5" hdmi display, and a PS3 controller. That fills up the rainy days when I ain't got anything better to do. Or when my Odroid C2 is bussy rendering new videos.

I often travel with my bycicle, and go wild camping everywhere in Europe. With this I film everything, I edit it in the evening. And when I go to a camping I upload everything to Youtube. 
Many people would not want to travel like this. But for me it's my heaven.

I couldn't do all that with my laptop. The thing is heavyer, a lot more power consumption, battery only lasts about 1,5hours, ... So SBC's are the greatest pieces of tech ever for me.
I used to carry around a lot of thick books while traveling. I'm happier with all this.
I love to watch a movie with a beer while the sun goes down on a beautiful spot. I can't wait to leave again.

In daily life I also use them, I don't have a smart phone. So these replace that.

I made a quick video on my last trip about it all. Also about my new 13.3" display.
But I didn't do any video editing on that trip since it was not a long trip(less than 2 weeks)

I hope that fulfills your curiosity.
I use my SBC's for a lot more than that alone. But it's because of this I fell in love with sbc's.
I was a giant tech nerd when I was young. I started working as a programmer when I turned just 15, but lost my job at 19(bankruptcy of the company I worked for) and didn't have a school degree. So I then lost all interest in computers for almost 15 years. SBC's have brought me back that joy of the early days. I just love them....
Greetings.

 

@nicod I saw it on the other thread. It’s worthy of its own post. That rig captures the essence of what makes hacking on SBCs so great.
 
Lane
 
 
Sent from my iPad using Tapatalk

I remember reading the history of the Lima project a while ago, and it basically comes down to that ARM doesn't WANT an open-source implementation of the graphics drivers, as they make a not-insignificant amount of money licensing theirs.

Goes back to what I was saying about DKIM/SPF/DMARC as this establishes the trust and credibility for being an SMTP sender... Requires a bit of DNS work to update the records, but once done, generally works.... then just keep on top of certificates, which isn't much overhead there once they're set up.
 
One can use postfix, qmail, or sendmail even (don't consider sendmail - it's powerful, but it's a curve all it's own).
 
postfix works well as a smarthost for outbound, and works equally well for inbound as an full blown MTA
 
BTW - I used to be the MMS admin for the 7th largest Wireless Telecom with over 7m users in the US - and MMS has the SMTP gateway...
 
 

350 had plenty of problems, it's biggest strength was how cheap it was. The Mopar 318/340/360 was/is a far better engine series.
@Tido@chwe next time say $6. :-P

The thing I see with the V3s is the fact that it appears to be in the same price arena as the H3, and without full vdec/venc/camera support it doesn't have a single benefit over the H3 or a decent micro (esp32, etc)

Sent from my Pixel using Tapatalk

I've got a very special use case that I don't think anybody else uses it for. I use them (among many other things) to edit and render videos on location(while traveling, while visiting interesting stuff...)
I must do this with power banks charged with solar panels. So for that reason ARM is the best choice(power efficient). I've got my "render bread box" for a long time with the C2(fastest while best passive cooled) for editing and rendering. The RPi2B with small display to record sound(because it's most power efficient). And I also just love sbc's...

I'm now putting together something better with a 13" 5V display and probably with the RockPi4B for this summer. The case will need to be the cooling for it. I've got more solar panels, so I can power more.
And I hope in the future to be able to make a new more powerful handheld sbc with the Pine H64.(if it's ever released, I've seen TL Lim on FOSDEM and he said it would be out first half of Februari) Video Pine64@FOSDEM

Since I couldn't get the right info for my use case(because nobody else uses it like this) I filmed some tests when I bought the Tinker Board and put it on Youtube. That video got a few thousand views. So I just kept making videos about new boards.
I try to do this a good as I can. That's why I love it when somebody comes with information I didn't know about what you often do.

Many people get their info on Youtube, it is mostly another public then we meet here in the Armbian forum, that uses SBC's for other tasks(gaming, desktop use). So that's what I show.
 
I'll follow it. Thanks for the info.
 
But that's what people want. They want to see them lined up in an order. So it's the reviewer his choice what order he shows to the viewers/readers. That's why I try to find the better tools for the job, but none of those I've used are even near to perfect.(as I've shown in my videos) So I try to minimise the variables as much as possible by using the same distro, no throttlin, the same software version, the same settings, only ARMV7->V7 - V8->V8 ... But it's never possible to do this well. Most Youtubers don't even care about that, and show very weird results of sysbench or so.
I'll keep using 7zip, CPUMiner and blender for now because even with their faults. They still manage to make the most sensible line up. And I'll keep saying it only shows how well it does that task only. And there's a lot more to SBC's than how powerful the CPU is.
Well the last 2 days we've managed to keep you bussy here. And I enjoyed it, and I bet many readers will have too. So it's only a tiny step to stay and end the self-censorship.
Have a great day. Read you soon.

Blender test. Checking the relevance of SETTINGS instead of focusing on irrelevant hardware details like DDR3 vs. DDR4:
RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=1000: 1:15:31 RockPro64, Ubuntu Bionic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:06:59 RockPro64, Ubuntu Cosmic with LXDE, 2.0/1.5GHz, CONFIG_HZ=250: 1:01:11  
That's 8:30 minutes difference due to switching from CONFIG_HZ=1000 to CONFIG_HZ=250. Check %sys vs. %user below (iostat 60 output). And why is Cosmic faster than Bionic if it's exactly same Blender version? Since Cosmic (18.10) uses GCC 8.2 while Bionic (18.04) uses GCC 7.3 to build the packages. So by switching from default SoC vendor kernel settings to something better and by letting modern compilers do their job we get almost 25% performance 'for free'.
 

He also hung a lantern on it, so to speak:. "silly kitchen sink benchmarking". He's illustrating how numbers can be used to selectively represent reality.

Sent from my Pixel using Tapatalk

Just a notice that I edited my last post above, to include a link to a very interesting discussion at CNXSoft, that clarifies the PCIe matter. A kind of a summary, with some additional insights by @tkaiser in this article:
https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Preview_of_ODROID-N2.md

There is a difficulty here, because we do not host the kernel sources.  Updates to kernel sources often break the configs/patchsets.  If you wish to continue an EOS board it would be recommended to clone the kernel, u-boot, and Armbian buildscript at the point of eos. 
 
  I agree money isn't the best discussion, I also see, however, a constant demand for professional-level support with no hint or interest of contribution of even time.  That is just as ugly, but hard to point to as easily.  
 
There is a reasonable technical answer with some supporting information:
 
- We have no requirement to support any board.  If it is not in our personal interest or benefit it simply won't happen.  I think some of the "regular devs" feel pressure and get frustrated that they can't satisfy the whims of the general public.
- We have too small of a team to deal with demands and general Linux questions.
- the code is all public and opensource, anyone can contribute/fork to do whatever they like board support wise.
 
My personal action in this has been that I don't answer any general questions I don't have an immediate answer for.  If no one else does either I can't help that.  I think it works out in the end.

Well that one went into personal insults of each other which is for sure not what both of you want... Let's try to figure out where and why this went wrong.  Starting from here:
 
Well the answer was more or less there:
 
understandable, it's frustrating. when 'your board' gets dropped.. But you must also understand that we can't support every board for years, especially if it's not sold anymore.. It's work to adjust the related patches everytime, to test it before we provide a new image and the support over forum. This thread was meant as a 'board support - general discussion / project aims' not a how to I get *random board supported*. For such a topic you should open your own thread.. E.g. here: https://forum.armbian.com/forum/25-peer-to-peer-technical-support/ (Armbian support ended or never existed - 3rd party boards and external hardware). Hint (since the SoC is still supported you basically need an ubuntu image, a device tree (or fex file in case you deal with the old kernel which I don't recommend) for your board, a defconfig for uboot, the buildscirpt and some time to build your images and see if and what's working (so you get also a clue what it means to support a board... and we support a few more than one)..
Such questions show up constantly.. This can be frustrating.. Sometimes you get then a less polite answer.. that's human.. your first post maybe wasn't a rant.. the follow up here clearly were.. From there you can answer (as @Igor did) or as I do quite often... Just ignore it.. I'm mostly not in a mood to answer to stuff which just annoys me, why should I? As others, I donate my time for free and it's not worth to deal with annoying stuff. There's enough funny stuff to do on a project like Armbian. Even helping other people to get familiar with the buildscript can be fun, but clearly not if someone drops partly into the wrong thread, complaining multiple time why his question isn't the most important one we should answer to.. and then complaining about bullying... In case you still want to bring back your board working:
 
Here's one where I implemented a whole new SoC family into armbian:
 
And in this thread I tried to basically show *my workflow* to patch a kernel and u-boot to bring in a feature into an existing board:
 
with those two, and enough time, you should be able to bring back your board into the buildscript.. And if there are still open questions, you can open a thread in P2P and maybe someone is willing to give you some guidance who knows.. I hope we can keep this thread now as for what it was for, in case not I'll either close it for a cool down phase or just delete the off-topic part, depending if I've a good day or not..

but it sounds like we have to look around the corner, something is coming
 
EFI Support
We are moving towards having standardize boot by supporting EFI.  However, the bootloading process is using the EFI facilities and you will now have a EFI-based GRUB GUI that lets you control boot parameters where as it was hard coded before.
https://libre.computer/
 

It's simple to implement this on image for one machine, while implementing this on all armbian supported boards looks more complicated. For users perspective, things as such
bring more on the table. But I do agree we shell pay attention.

This is irreversible. Any objections?

Proposed actions:
 
1. Renaming section "Technical support" to "Bug tracker" (leave restrictions as is)
2. Merging "Common issues" with "Peer to peer" and place under "Community forums" section
3. Creating new section "First aid" 
    - move "SD card and power supply"
    - create "Board doesn't boot"    
    
    or move "SD card and power supply" one level up and rename to "Board doesn't boot"    
 
Alternatively:
4. Make "armbianmonitor -u" field mandatory for "Bug tracker" section except "board doesn't boot"
5. Move NXP and Armada A388/A3700 under "Other supported boards"

That's a separate issue, but it lies in the reality vs. what we would like to see be true.  The simple reality is you can't force people into line without draconian policy/rules/etc that will choke off the community in general.
 
Now, if it were possible, I would say, along some reorganization lines as Igor posted, that we have a "select your board" drop down requirements for the Support subforum, and if we can go even further, sort them appropriately by that tag.  Then it gets easier, we only have spammers posting in whatever the first board on that list is.  ;-)
 
 
Well, the forum is the part people see above ground, a lot of its issues relate to the roots, so it's bound to get complicated.  For example, WIP/CSC's having downloadable images on armbian.com results in user questions, which increases our support traffic for boards we obviously don't find interesting enough to support directly.
 
Ignoring them is somewhat effective, but like I said above, making a single part of the forum a "gated community" with curated/controlled input should make it so stuff like that can be ignored with a documented reason, without necessarily causing any collateral damage.  And of course keeping boards to a minimum or at least defining what the core boards are should help as well. 
 
My thoughts on this fall more into the perception and the actual scale of the project.  The act of imposing regulation and setting a bar is viewed as pretentious or exclusionary by the human psyche in general.  That's not necessarily a bad thing, however it's being introduced into a space that was previously open to admittedly "too free" of discussion.  Is it possible to sort posts automatically by tag and then by age?  At that point, a fully filled out questionnaire (with a check so that http://Idontfillout.form won't be accepted ;-) ) would receive a tag that puts it at the top of the non-pinned pile, and above anything that skipped a step.  That simple feedback of basically demoting the content instead of downright blocking it should passively take care of the issue, and if someone gets noisy a mod can point out their stuff is under all the properly filled threads because it wasn't done correctly.  I'd guess there'd have to be some sort of qualifier based on age for when that sorting stops, otherwise the first improperly filled out post would be on page 12 or some nonsense.
 
 

Hi Pietro,
 
If your software is so good, that people are willing to pay money "if they rather use it than steal it", well done.
If you offer it to others who do not have the money but use it, test it and give you feedback and even help you to make it better - win - win.
This is how https://www.invoiceninja.com/  built a great company - listen to the podcast on https://twit.tv/shows/floss-weekly/episodes/506?autostart=false
 
so long

WOW  on a OPi Plus2 H5 the time - which was displayed - was gone down from 15 to 4 Minutes with 5.73 for transfering armbian to eMMC