Kris Posted June 2, 2017 Posted June 2, 2017 Title changed by moderator from "Performance and support ... how to select a good board, processor? Problem about different installation procedures by variety of platforms ex rpi-monitor ..." pine64:~$ uname -a Linux pine64 3.10.102-2-pine64-longsleep #66 SMP PREEMPT Sat Jul 16 10:53:13 CEST 2016 aarch64 GNU/Linux After reading the post here about your thoughts concerning AllWinners processor seems not the best choice qua performance and support. https://docs.armbian.com/ What kind of boards, processor is this community recommending? Thanks, I didn't found yet some kind of stars, recommendations here about boards. To be honest I'm little bit misguided, because of the supported CPUs, boards. On the other hand the post : “Need help on Pine A64, 64bit Quad Core 1.2GHz Single board computer” was for me as newcomer an eye opener. Just as this document of Tido https://docs.google.com/document/d/1LMbXPbt16C8TtmmPm45ZzU61O77HkQ5ZLJ-ALlhLOlI I have a lot of respect for you all, your time and effort. But what is the big difference between ARMbian and a debian installation? @TKaiser, I'm little bit confused in a way … TKaiser, just like a lot of others in this community, did so much effort and coding, but I've the impression that every platform has it's own installation procedure for rpi-monitor. By accident I found this guide one for board PINE A64, which is quite different to the one for the Banana A20 Pi. REF : https://forum.pine64.org/archive/index.php?thread-4462.html wget -q -O - http://kaiser-edv.de/tmp/4U4tkD/install-rpi-monitor-for-a64.sh | /bin/bash (I was not able to find your original post back, here???… in the hope to learn a little bit more. Except a small post here about the performancehttps://forum.armbian.com/index.php?/topic/491-need-help-on-pine-a64-64bit-quad-core-12ghz-single-board-computer/&page=3 – tkaiser reference https://pastebin.com/bSTYCQ5u ) REF : https://forum.armbian.com/index.php?/topic/155-testers-wanted-sunxi-adjustments-for-rpi-monitor/ for banana pi (router) A20, is for me not all clear but the post explains quite a lot. On the other hand … I have already few questions about the set-up for PINE A64, I don't see on the rpi-monitor that there is no PMU [Power Management Unit] available. Is it difficult to implement ... [ http://rpi-experiences.blogspot.be/2013/06/rpi-monitor-version-20-advance-usage.html ] ... I have read now about regular expressions ... but how do you go from command line to ... dynamic.6.regexp=\S+\s+\d+\s+(\d+).*\/$ config files. [ https://www.cyberciti.biz/faq/grep-regular-expressions/ ] But still makes no sense ... REVIEW : In meanwhile I found this information in paragraph : "Add other graphs from additional sources: other mount point" - REF : http://rpi-experiences.blogspot.be/2013/06/rpi-monitor-advance-usage-and.html COMMAND | perl -ne '/REGEXP/' and print "$1\n"' And despite I use a32Gb SD-card mounted, I just see 6Gb (also in command line). (a SD one like recommend at https://docs.armbian.com/User-Guide_Getting-Started/ : SD-card ) PICTURE on-line : https://drive.google.com/open?id=0B2WLaA0HlUBVSTQ1V1BsT2ljTm8 (annex) command line pine64:~$ sudo fdisk -l [sudo] password for debian: Disk /dev/mmcblk0: 29.7 GiB, 31914983424 bytes, 62333952 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x88dd9856 Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 40960 143359 102400 50M e W95 FAT16 (LBA) /dev/mmcblk0p2 143360 12787711 12644352 6G 83 Linux [ /etc/rpimonitor/template/sdcard.conf ] static.7.name=sdcard_root_total static.7.source=df / static.7.regexp=\S+\s+(\d+).*\/$ static.7.postprocess=$1/1024 static.8.name=sdcard_boot_total static.8.source=df /boot .. dynamic.6.name=sdcard_root_used dynamic.6.source=df / about SWAP: I have 0 as indications; NaN [Not A Number] indication for percentage ... on first thought, I think it's a regular expression problem??? command line : pine64:~$ cat /proc/meminfo MemTotal: 1003820 kB MemFree: 211060 kB Buffers: 19060 kB Cached: 623204 kB SwapCached: 0 kB ... [ /etc/rpimonitor/template/swap.conf ] dynamic.8.source=/proc/meminfo dynamic.8.regexp=SwapFree:\s+(\d+) dynamic.8.postprocess=$this->{'static'}->{'swap_total'} - ($1/1024) Maybe I look it too simple, because the variety of platforms ... Is it not possible to install all config files (one installation guide) and then just use the correct one, depending platform and number of bits 32/64.
Igor Posted June 24, 2017 Posted June 24, 2017 On 2. 6. 2017 at 9:14 AM, Kris said: Linux pine64 3.10.102-2-pine64-longsleep - this is not Armbian, which means scripts done for Armbian might not work there - we don't support something, we don't know how it's put together, it's a work from somebody else - information, which you are referring to is very old and possible outdated.
tkaiser Posted June 25, 2017 Posted June 25, 2017 On 2.6.2017 at 9:14 AM, Kris said: I was not able to find your original post back, here??? There was none since with Armbian it's just a simple 'armbianmonitor -r' to get RPi-Monitor installed. But currently only for one single platform the templates will be adjusted so you end up with default templates on all other platforms and have to exchange them yourself. On A64 platforms using legacy kernel (that applies to you) the most simply thing is to use this script: https://github.com/ayufan-pine64/linux-build/blob/master/package/root/usr/local/sbin/install_rpi_monitor.sh (it's bundled in most recent ayufan builds for Pine64 and Pinebook). All currently available RPi-Monitor templates here: https://github.com/armbian/build/tree/master/scripts/armbianmonitor/templates (even for shitty devices like Banana Pi M3 Armbian hopefully never will support). I never touched or even looked at those templates for memory or swap since useless anyway (it's fine having no 'free memory': http://www.linuxatemyram.com)
pfeerick Posted June 25, 2017 Posted June 25, 2017 Only adding this as I did look at it and 'fixed' the problem, which was indeed simply wrong pattern match, due to how ubuntu's free formats things different of recent times. However, I do agree with tkaiser, it isn't really needed, as linux is supposed to use 'free' memory for caching... unused memory isn't wasted! I just didn't like the broken stats! in /etc/rpimonitor/template Modified swap.conf is like this. Modified memory.conf is like this. I also added more stuff to my Allwinner_A64.conf file, which may or may not be the right filename, I might have renamed that in the process of cleaning stuff up. I added the GPU temps since the health monitor was doing that. Still need to go back and pull the PMIC temp and battery stuff in, and then update my script. It'll happen sometime soon.
tkaiser Posted June 25, 2017 Posted June 25, 2017 10 minutes ago, pfeerick said: I added the GPU temps since the health monitor was doing that. https://github.com/armbian/build/blob/master/scripts/armbianmonitor/templates/pine64_default.conf#L85-L101 (but useless anyway, this Mali400 bullshit is of no interest since there's no use case for Mali400 on this platform! But I guess it will take until 2018 until everyone over in Pine64 land will be cured from the stupid Mali hype so many are still suffering from) 1
pfeerick Posted June 25, 2017 Posted June 25, 2017 You forgot to mention that fact that the GPU won't be that far off the CPU temperature anyway, since they're on the same die. It may be interesting though if you do hardware assisted encode/decode stuff, whoever is daft enough to use the pine64 for that :-/
tkaiser Posted June 25, 2017 Posted June 25, 2017 11 minutes ago, pfeerick said: You forgot to mention that fact that the GPU won't be that far off the CPU temperature anyway, since they're on the same die What is way more important is to understand how the physical environment affects thermal readouts especially in the Pinebook. There PMIC and SoC are both attached with thermal pads to a metal plate. When the Pinebook charges, the PMIC gets very hot and transfers this heat over to the SoC, so SoC temperatures seem to increase for no reason and people are scared. In general it's the old story about data vs information. People love numbers (since easy to compare), love graphs (since nice looking) but don't like information (need to switch on the brain). So what does monitoring provides? Data but no information. You need to have some knowledge to make use of it, in this case about PMIC+SoC placement. This RPi-Monitor stuff is great for developing good settings (as we did last year for H3 and A64 devices, this year it was just a quick check if we can throw Allwinner's Pinebook settings away and replace with the way better Pine64 settings community developed last year) but once this is done it's not that useful anymore unless you want to experiement yourself (testing out different heatsinks or cooling solutions for an enclosure for example) BTW: position of the CPU cores matters wrt temperature sensor: https://forum.armbian.com/index.php?/topic/1614-running-h3-boards-with-minimal-consumption/&do=findComment&comment=12525 (A64 is more or less a H3 with exchanged CPU cores and crippled USB) 19 minutes ago, pfeerick said: It may be interesting though if you do hardware assisted encode/decode stuff, whoever is daft enough to use the pine64 for that This is not related to GPU/Mali400 (this Mali crap is useless with A64 anyway). Allwinner's video engine is doing this stuff, we can use HW accelerated video decoding on A64 since March 2016 (even if over in Pine64 land still some believe they need 'the Mali' for that), we were able to use hardware accelerated video encoding a few months later. Temperatures increase just by a few degree: https://forum.armbian.com/index.php?/topic/789-breaking-news-choosing-armbian-speeds-up-your-orange-pi-multiple-times/&do=findComment&comment=6005 (video engine in H3 and A64 is exactly the same, at the top of that thread you also find a nice example why Allwinner's defaults are so shitty and why it matters to replace them with community settings) 1
pfeerick Posted June 25, 2017 Posted June 25, 2017 My apologies on that last point... I fully deserved that... I keep thinking that the misleadingly named GPU is actually the GPU, instead of just the 3D accelerator. I'll stop there though, as this is getting away from the OT. I just wanted to bite that bullet publicly!
Recommended Posts