sfx2000

Up to @tkaiser for results on sbc-bench... working on an addition - byte-unixbench and sorting out things... removing some gcc over optimizations, looking at threads... https://github.com/sfx2000/byte-unixbench It's a better bench than sysbench, and portable... Doing a -c 1 -1 and -c4 -i 1 keeps things short - however - letting it run thru pushes heat/throttles... UnixBench is interesting from a system perspective... RPI3 B Plus vs Tinker.... Tinker is 15 pounds of power in a 5 pound sack - RPi3 B+ is a CPU that can do better that it is with raspbian.... Tinkerboard - Cortex-A12/A17 - Armbian ------------------------------------------------------------------------ Benchmark Run: Sat Oct 20 2018 17:02:37 - 17:31:22 4 CPUs in system; running 1 parallel copy of tests System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 8709974.2 746.4 Double-Precision Whetstone 55.0 1031.4 187.5 Execl Throughput 43.0 1095.7 254.8 File Copy 1024 bufsize 2000 maxblocks 3960.0 91960.7 232.2 File Copy 256 bufsize 500 maxblocks 1655.0 26583.4 160.6 File Copy 4096 bufsize 8000 maxblocks 5800.0 246267.0 424.6 Pipe Throughput 12440.0 149851.8 120.5 Pipe-based Context Switching 4000.0 25850.9 64.6 Process Creation 126.0 2429.0 192.8 Shell Scripts (1 concurrent) 42.4 2061.9 486.3 Shell Scripts (8 concurrent) 6.0 432.0 720.1 System Call Overhead 15000.0 442992.8 295.3 ======== System Benchmarks Index Score 258.2 System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 13538575.0 1160.1 Double-Precision Whetstone 55.0 1982.4 360.4 Execl Throughput 43.0 1752.7 407.6 File Copy 1024 bufsize 2000 maxblocks 3960.0 87122.4 220.0 File Copy 256 bufsize 500 maxblocks 1655.0 22948.6 138.7 File Copy 4096 bufsize 8000 maxblocks 5800.0 281302.7 485.0 Pipe Throughput 12440.0 321233.1 258.2 Pipe-based Context Switching 4000.0 40012.9 100.0 Process Creation 126.0 3820.3 303.2 Shell Scripts (1 concurrent) 42.4 3399.0 801.7 Shell Scripts (8 concurrent) 6.0 433.6 722.7 System Call Overhead 15000.0 952658.0 635.1 ======== System Benchmarks Index Score 373.1 Rpi 3B+ - Cortex-A53 - VCOS/ThreadX - Raspian ------------------------------------------------------------------------ Benchmark Run: Sat Oct 20 2018 17:02:32 - 17:30:38 4 CPUs in system; running 1 parallel copy of tests System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 4324740.1 370.6 Double-Precision Whetstone 55.0 957.4 174.1 Execl Throughput 43.0 908.8 211.4 File Copy 1024 bufsize 2000 maxblocks 3960.0 140312.9 354.3 File Copy 256 bufsize 500 maxblocks 1655.0 40618.4 245.4 File Copy 4096 bufsize 8000 maxblocks 5800.0 353296.2 609.1 Pipe Throughput 12440.0 280908.2 225.8 Pipe-based Context Switching 4000.0 50734.2 126.8 Process Creation 126.0 2212.2 175.6 Shell Scripts (1 concurrent) 42.4 1780.5 419.9 Shell Scripts (8 concurrent) 6.0 575.7 959.5 System Call Overhead 15000.0 594784.0 396.5 ======== System Benchmarks Index Score 302.2 System Benchmarks Index Values BASELINE RESULT INDEX Dhrystone 2 using register variables 116700.0 17082008.4 1463.8 Double-Precision Whetstone 55.0 3803.4 691.5 Execl Throughput 43.0 2240.8 521.1 File Copy 1024 bufsize 2000 maxblocks 3960.0 228921.9 578.1 File Copy 256 bufsize 500 maxblocks 1655.0 62777.0 379.3 File Copy 4096 bufsize 8000 maxblocks 5800.0 578721.9 997.8 Pipe Throughput 12440.0 1112342.2 894.2 Pipe-based Context Switching 4000.0 98478.8 246.2 Process Creation 126.0 4789.7 380.1 Shell Scripts (1 concurrent) 42.4 4464.7 1053.0 Shell Scripts (8 concurrent) 6.0 589.0 981.7 System Call Overhead 15000.0 2289227.2 1526.2 ======== System Benchmarks Index Score 705.6

Gah - watched the video - and a lot of problems across the board (pardon the pun). Different kernels, built with different versions of GCC, userland (for example, Raspbian userland is all ARMv6 with exception of the kernel for the A7/A53 boards).... (I wouldn't have included the any of the Pi's in the set of boards being evaluated because of the userland - <soapbox> nothing against Pi's in general, one must appreciate that 35M+ boards means they're doing something right, and they've spawned an entire HW/SW ecosystem around their platform, that's ok - and that ecosystem has in turn made affordable ARM boards available for hobbyists, makers, and developers - before Pi, if one wanted to do development around ARM, boards were expensive, and SW support was very limited to the vendor BSP - these days, it's a lot more open - not perfect, but much better than it was</soapbox>) Rock64 vs Odroid XU4 - Quad A53 vs A7/A15 big.LITTLE - the big.LITTLE is a challenge for the scheduler, and depending on the BSP from the OEM, it's easy to get wrong, where threads can land on the lesser preferred core, this is an issue even on Android, where much work has been done outside of the mainline kernels (ARM and Qualcomm, I know they've done a lot of research there, but much of that has not been pushed back to mainline). In my experience, with supported boards (for me this is Tinker and NanoPi NEO), Armbian is generally faster than the vendor's images - and that's doing Byte-Unixbench, which is discounted because it is compiler sensitive - that being said, it's still a useful tool when comparing apples to apples (e.g. tweaking settings on the same OS/Platform, but comparing Platform A to Platform B, one has to take the results with a grain of salt) I haven't found a lot of evidence of cheating by any of the SBC vendors - it's really hard to do with FOSS, compared to Android, where cheating has occurred with certain OEM's and specific benchmark APK's - Android has enough hooks to enable this kind of cheating in any event. sbc-bench, in my humble opinion, is a good benchmark for supported boards - as long as the boards being compared are all on the same version of Armbian - and this is made clear in the script comments (please review the script on github, and @tkaiser has been pushing updates, so if one has cloned the repo, it's worthwhile to do a git pull to get the latest revision. To answer your question about the different versions of Cortex... Small Cores - A7, A53 are the low power cores focused on efficiency Big Cores - A15, A12(A17), A72 - big cores... Think of it like Atom (Small Core) vs Core i3/i5/i7 (Big Core) - even at the same clock, the big core is going to get more work done, but perhaps at the cost of heat, so thermal solution needs to be considered.

Yeah - but for OP - it's perhaps a challenge to contribute Keep NAND sane and untouched - makes it possible to continue to use the TV box as an Android - and 7.x isn't a bad place to be there for the intended apps... Worst case - one can always run termux in the android space - which isn't bad actually - I do that with my little chromebook, and it's debian like enough...

Ignore the NAND Once he gets serial up and running, he can play around with FEL, and take things from there. Totally possible, IMHO, to just run everything Armbian off the SDCard, and leave Android as the secondary option if the card is removed.

Gah - they did go with naked NAND - unexpected, but not surprised - Android AOSP can live with this... but getting to something beyond the ASOP is going to be a challenge - something tells me that this is an android box, straight up, and that's what it is going to run... At least with the NAND it's good flash - SpecTek is Micron... RAM - Lot of RAM chips there - which makes uBoot a bit interesting - 2Gbit*8 is 2GB... is Samsung running a special sale on them these days? WiFi - XR819 - boring to some, weird to others - nothing exciting.... BTW note the really neat Inverted-F antenna - STB boards do leave a bit of room to be inventive there - although this isn't too terribly clever - but it is cheap, and gives decent enough gain there - maybe unity even. FWIW, Wifi front end is a bit of a mess, so some loss there - more that most... Looking at the board power - LDO's actually look ok - cheap and good enough - I wouldn't expect more at this price point... UART - 3.3 is likely good there - follow the pins, and consider this is one of many boards, so everything should align there/// Thermal Solution - with more recent H3's, and community understanding with Android - it's likely good - older H3 boards and distros - Allwinner got a bit of a bad reputation... but is cost is an issue, they could have done like Beelink with the X2, and put a big check of iron there - but who knows, extruded heatsinks like this are probably cheap enough these days in Shenzen. Anyways - like I mentioned earlier - this is a hyper optimized board for cost, and sensitive to the current supply chain (note the RAM, they wouldn't do this unless it was cost-efficient) BTW - @chwe - it's an H3 - H2+ is H3 with the GPU/VPU disabled if I trust what I read - I'm not a native Chinese speaker... Anyways - it's up to others whether to support this board in Armbian - it's going to be specific work, and time/resources are tight.

Yes and no - It's not H3 actually - one can have L1 even on H3 or any chipset - it's more the ARM TEE and requirements there - and with Android, this means full-on GMS compliance, which means that the OEM/ODM has to have written agreements with Google, and do all the compliance/conformance testing around those requirements. Widevine L3 limits output to sub-HD, and sounds like Netflix from Google Play likely won't work (there are ways around this with a patched apk there) - this is not unexpected with AOSP, even with Play Store hacked in... L1 is full on compliance with Widevine, all keys are good, and everything runs inside the ARM Trust Environment - most NA/EU mobile phones have that, but cheap TV boxes, and AOSP handsets likely don't. Many AOSP TV boxes will have test keys installed, but TEE and the APK's know this - grrr... DRM, and I understand why content distributors want this, but still... Anyways - Widevine is an android thing - and android support does mean that the box is still useful if mainline support is lacking... 16GB - most likely eMMC, IMHO... if one is going to put 16GB on the board, might as well be eMMC. One could have 'naked' NAND and run it as a MTD device I suppose, but mmcblk is less work, and more flexibility with supply chain, besides, eMMC prices are probably better, and eMMC has knockon benefits later on with OS level support... Anyways - good res pics of the board, along with RAM, WiFi, eMMC, that's a good start - high resolution of just the board - top and bottom, goes a long way - there's only so many ways to do a H3 board, and now that the chip in question is pretty old, most of the options have been refined to a narrow set of choices... Good example of board pix - http://linux-sunxi.org/HYH-TBH3

That's a BPi - not a tinker...

Does it have Google Play? Would also be interesting perhaps if it has Widevine Support (this is a DRM scheme that can cause problems with AOSP and haxxored play store support - if Netflix runs from the playstore it might have valid keys there

Sounds good... When/If pics happen - top/bottom of the board, thermal solution, take a close look at WiFi (should be a system on module, if you can note the vendor/model there), and mass storage... also look for UART pads, as this is key - if you can get into uBoot, that's a good thing... I suspect that whatever they're doing, it's going to be super cost optimized... at the sub-$30USD price, including an IR Remote, HDMI cable, AC adapter, and of course the shipping box -- Sunveil must have done lot of work to reduce any additional BOM costs to keep some profit on the product. In past experience with AllWinnner Android boxes, ADB is there, and fairly open, at least on Android 4.x - this one runs Android 7* (Nougat) so all bets are off - just note that there might be some security items with the BSP that you can take advantage of to get root for spelunking of the OS in general... First shot would be -- If Google's PlayStore is enabled within the stock Android on that box, one might consider getting "Termux" (it's free) and dig around a bit - it's sandboxed, but one can still get some decent info about the environment it runs in... * bit surprised with Nougat support, but hey, it's current enough... Anyways - to check the kernel/etc - go into Kodi, and there, you should be able to confirm the android and kernel versions... Best case - might be a good alternative for the OrangePI Plus 2E...

H3 boxes are interesting... Last time I looked at Beelink X2 - it's was pretty smart on the layout - thermals were a challenge. If you are going to do a teardown - board pics are nice, but also the housing and thermals...

ALG and Cryptp Blocks can be a bit complicated... Based on your numbers - what moves more bits? ARM does... SOFTWARE Doing aes-256-cbc for 3s on 16 size blocks: 3708058 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 1104719 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 292752 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 74300 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 9329 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 16384 size blocks: 4662 aes-256-cbc's in 3.00s ALG Doing aes-256-cbc for 3s on 16 size blocks: 129499 aes-256-cbc's in 2.95s Doing aes-256-cbc for 3s on 64 size blocks: 115145 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 78540 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 34189 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 5404 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 16384 size blocks: 2756 aes-256-cbc's in 3.00s That being said, ALG is likely lower CPU usage overall, but running on ARM in your case is the right choice....

What do these explicitly do? Which ones can be disabled? Which ones can interfere with other system mods? sudo systemctl list-unit-files | grep armb* armbian-firstrun-config.service enabled armbian-firstrun.service disabled armbian-hardware-monitor.service enabled armbian-hardware-optimize.service enabled armbian-ramlog.service enabled armbian-resize-filesystem.service disabled armbian-zram-config.service enabled I've notices that ramlog can be disabled two ways - in the config, or disable the service, others related to if zram-config is installed or not - HW monitor actually doesn't seem to impact things on 5.60+ when running local, other than we see less /var/log stuff (which is ok) - the zram-config-service can get in the way of testing, but generally harmless otherwise. Just curious as to why?

On ubuntu 18.04, there was a push for update on aptly... Build script rolled it back.

This is actually still an issue with noisy power supplies (cheap cell phone chargers and the like) - it's not an Armbian issue... if anything, it's a HW issue on the front-end - a good clean PSU that is intended for SBC's should be ok. Devices that have MicroUSB and OTG capability can get stuck there in uBoot as the noise can be interpreted as a key stroke with some boards and some PSU's - the Nano Pi NEO is good example of this... and this happens before uBoot even can sort things out.

Hint - it's a feature mention within the armbian-zram-config script set - it calls armbian-ramlog Look at /etc/default/armbian-ramlog - you can change "enabled" to false, and then things start follow expected rules... and you can mount /var/log where ever you want... remember you need to be root or sudo to do this, and reboot after the change.

You might be right there on the 5V line... Anyways, with any PSU, going into the GPIO's - just be careful - inputs there assume that all is good... lest one gets the opportunity to see some magic smoke - but at these levels, likely a dead board if one doesn't get it right.

Weren't these 'things' also part of the mirai (and derivate botnets)? Folks were always concerned a bit on the end devices, but that cloud is a pretty sweet target for folks....

Going past PMIC into powering the Tinker on GPIO - all bets are off... PMIC is only going to cover on the input side - which is rather limited as we can all agree on... I run Tinker headless, so can't say much about HDMI/peripherals there...

Completely agree... Etcher does a great job - and the verification ensures that one has a good write to the card... When in doubt - one can use the SDCard Formatter Util (Win/Mac) to "refresh" the card prior to writing... https://www.sdcard.org/downloads/formatter_4/ If it fails, then check either the card, or the reader...

Keep in mind that it's supplying volts/amps to a PMIC on the Tinker... on a non-PMIC device, might be a concern there. PMIC's are smart to some degree. Volts might be on lower side, but as long as current is good - everything should be fine, as the PMIC regulates things to the rest of the board... Other than that - looks like a decent enough PSU, good gauge over to the uUSB connector (which is always a concern) - seems similar to RPi's "official" adapter which has solved many problems with their gen3 boards... both 3B and 3B+ - and those are pretty power hungry - not as much as tinker I'll say...

Anyways - if one is writing to /var/log, and still running into problems with space - even on a small mem footprint - need to explore why so much logging... Case in point... this is my jumpbox into my lan - and we're writing /var/tmp to flash, and it's not that big of a deal at first glance... $ sudo du -h /var/log 4.0K /var/log/samba 4.0K /var/log/sysstat 32K /var/log/lightdm 180K /var/log/apt 2.8M /var/log This is 6-months worth of use on that box... the 2.8M is a bit misleading, as it's active all the time, and writes to flash have a cost there there, as each write to flash is also an erase cycle, and on poor quality cards, this can lead to early failure - and small cards are more at risk than larger cards... I'll defend the decision to some degree - @tkaiser's script has to assume many things - size of the flash, quality of the flash...

Reason why /var/log is filling up is because if you review df -h, you'll find that /var/log is mapped to zram... Logrotate might not hit the time limits in the fs time as each time with current zram-config in armbian, it's mapped to an ephemeral state over in zram - ask @tkaiser why this is what it is - his script that does this... my guess his intend with /var/log is to reduce read/write on flash there, and that's fair enough... Things in /tmp are ok to be free and mapped to tmpfs - things in /var, even /var/tmp are expected to remain constant across boots, but that's just my opinion. My opinion and two bucks will buy you a cup of coffee at the local *bucks... zram is a good thing actually - and tmpfs plays into that, as tmpfs is ram...

Going back to the whole BMC issue.... Was odd that Servethehome.com brought up BMC's and the DRAC thing just before the Bloomberg article popped up... First was their BMC discussion... https://www.servethehome.com/explaining-the-baseboard-management-controller-or-bmc-in-servers/ And then the iDRAC disclosures... https://www.servethehome.com/idracula-vulnerability-impacts-millions-of-legacy-dell-emc-servers/ https://www.servethehome.com/broader-implications-of-idracula-vulnerability-a-perspective/ Were they tipped off? Timing here is interesting... SuperMicro took the hit - bloomberg.com is a financial site at the end of the day, and SuperMicro along with the two scalers (Amazon and Apple) were mentioned. A few weeks back - somebody wanted to expose HP ILO to the internet for remote management... and I strongly warned them against it. BMC"s are a raging tire fire with regards to security. so many providers do keep them on a more secured management LAN outside of production. Anyways - look at the vendor provided BSP's - only the Shadow knows what code is there... better bet is here perhaps, rather than the board/chip BSP's... This sub-thread came from discussion on the AR100 on the AllWinner H3 chip - to actually use it, one has to enable the ARM trust stuff, otherwise not...

THat one was odd... and a very small group that was exposed - around 500k users Compare that to the total number of gmail users, it's a small number actually If anythings, it shows the overall success (or not) of G+

Thanks for sharing... Looking in from the outside - I see strong alignment across different groups and teams that I follow... Armbian might not have a recognized "formal team" - but I do see more than that - with strong contributors, deep insight, and for what it's worth - a shipping product - which is a big deal. As my most recent foray into startups - the shipping product is a big deal, seriously, it is... Let's put together a biz plan, and Armbian can be that BSP for OEM's to work with... and that would benefit both the OEM's and the Users, and building a relationship with chipset vendors would take it forward.