• Content Count

  • Joined

About tkaiser

  • Rank
    Embedded member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

22888 profile views
  2. The reason is that nobody at Armbian cares any more about such low level stuff. The string 'meson-g12b' (N2's board family) is missing from the case construct in so what you see is what is to be expected. All IRQ handling on cpu0 therefore being a nice bottleneck. Some people think irqbalanced would help but at least in the past it was common knowledge that for stuff like storage or networking static IRQ affinity is the way to go. BTW: You have massive filesystem corruption on the /var/log partition. As for your storage issues a simple web search for 'odroid n2 usb issues' might help.
  3. Well, that's why commit comments exist. The rockchip64 kernel has the following cpufreq OPP: 408000 600000 816000 1008000 1200000 1296000 So setting 600 MHz didn't do a lot other than causing confusion. A third of this thread's posts deal with cpufreq governor confusion wrongly assuming the SoC being on 600 MHz would be the root cause for the thermal anomalies R2S is plagued with. Anyway, this whole thread is bizarre. Why do users not simply verify the numbers some driver spits out? Why blindly trusting in numbers? Those users having the hardware right in front of them could've tested long ago whether the thermal readouts are BS or the hardware. Simply using their thumb and putting it on the heatsink.
  4. What? There's no difference between 408 MHz and 600 MHz since the DVFS OPP for both are pretty low. That's RK3328 powered Renegade idling at 408 MHz: root@renegade:/home/tk# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 12:47:02: 1296MHz 0.19 1% 1% 0% 0% 0% 0% 45.5°C 0/5 12:47:07: 408MHz 0.17 2% 1% 0% 0% 0% 0% 43.6°C 0/5 12:47:12: 408MHz 0.16 1% 0% 0% 0% 0% 0% 45.0°C 0/5 12:47:17: 408MHz 0.15 1% 0% 0% 0% 0% 0% 44.1°C 0/5 12:47:23: 408MHz 0.13 1% 0% 0% 0% 0% 0% 42.7°C 0/5 12:47:28: 408MHz 0.12 1% 0% 0% 0% 0% 0% 44.5°C 0/5 12:47:33: 1296MHz 0.11 1% 1% 0% 0% 0% 0% 46.4°C 0/5^C That's the exact same hardware with exact same load when setting minimum cpufreq to 600 MHz (no idea why @Igor did this change back in November though, the 600 MHz are not the result of the cpufreq governor doing anything but of the project's owner commiting some changes for whatever reason): root@renegade:/home/tk# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 13:42:02: 1296MHz 0.00 2% 0% 1% 0% 0% 0% 43.6°C 0/5 13:42:07: 600MHz 0.00 0% 0% 0% 0% 0% 0% 44.5°C 0/5 13:42:12: 1296MHz 0.00 2% 1% 0% 0% 0% 0% 44.5°C 0/5 13:42:17: 600MHz 0.00 0% 0% 0% 0% 0% 0% 43.2°C 0/5 13:42:23: 600MHz 0.00 1% 0% 0% 0% 0% 0% 43.6°C 0/5 13:42:28: 600MHz 0.00 1% 0% 0% 0% 0% 0% 43.6°C 0/5 13:42:33: 600MHz 0.00 0% 0% 0% 0% 0% 0% 45.0°C 0/5 13:42:38: 600MHz 0.00 0% 0% 0% 0% 0% 0% 44.1°C 0/5^C And now compare with @devman's results above using R2S without the yellow plastic oven which are still close to 15°C above Renegade/Rock64. So it's obviously not an RK3328 problem users are talking here about! Wrt ondemand governor. This governor has some tunables that need to be set accordingly depending on kernel version. But since nobody in Armbian gives a sh*t about such low level stuff, it's as it is. This most probably would need some attention: The last time I asked for testers I got zero useful responses:
  5. Are you kidding? Again: There's no problem with the RK3328, this is just another boring Quad-Core A53 in 28nm (just like the H6). So the question remains what's wrong with NanoPi R2S and not the RK SoCs. And I really don't understand why so many blindly trust in numbers. There's a thermal sensor inside the SoC, there's a reference voltage, there's some calibration needed, there's driver code. The idea that the numbers this driver spits out are somewhat or even closely related to the actual temperature of the SoC in question is just a hope! Care to remember what you yourself already reported?
  6. So there's something seriously wrong with this hardware or kernel code. 60°C is something noticeable by 'thumb test'. Does it hurt if you press your thumb on the heatsink while Armbian reports above 55°C SoC temperature? Have you done a test with an image using Rockchip's BSP kernel (4.4)? Just to compare which temperatures are reported there? @@lex Why do you think a reported clockspeed of 600 MHz in idle would be an indication of wrong governor? Igor defined 600 MHz for whatever reasons half a year ago as minimum clockspeed but there shouldn't be much of a difference between the 408 MHz before and 600 MHz now.
  7. This is a Renegade featuring the same 'powerful and hot running' RK3328 with large passive heatsink without enclosure: ____ _ | _ \ ___ _ __ ___ __ _ __ _ __| | ___ | |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \ | _ < __/ | | | __/ (_| | (_| | (_| | __/ |_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___| |___/ Welcome to Armbian buster with Linux 5.4.8-rockchip64 System load: 0.24 0.05 0.02 Up time: 41 days Memory usage: 12 % of 1986MB Zram usage: 7 % of 993Mb IP: CPU temp: 46°C Usage of /: 40% of 7.3G storage/: 16% of 7.3T Last login: Sun May 31 12:39:32 2020 from tk@renegade:~$ sudo -s [sudo] password for tk: root@renegade:/home/tk# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 07:31:13: 1296MHz 0.20 0% 0% 0% 0% 0% 0% 45.9°C 0/6 07:31:18: 408MHz 0.19 0% 0% 0% 0% 0% 0% 42.7°C 0/6 07:31:23: 408MHz 0.17 2% 1% 1% 0% 0% 0% 39.5°C 0/6 07:31:29: 408MHz 0.16 1% 0% 0% 0% 0% 0% 44.1°C 0/6 07:31:34: 408MHz 0.14 1% 0% 0% 0% 0% 0% 42.3°C 0/6 07:31:39: 408MHz 0.13 1% 0% 0% 0% 0% 0% 41.8°C 0/6 07:31:44: 408MHz 0.12 1% 0% 0% 0% 0% 0% 43.2°C 0/6 07:31:49: 1296MHz 0.33 2% 1% 0% 0% 0% 0% 47.3°C 0/6 07:31:55: 408MHz 0.30 1% 0% 0% 0% 0% 0% 41.8°C 0/6^C Rock64 is based on the very same RK3328 SoC, my board has just a laughable tiny heatsink on the SoC and all of the 8 sbc-bench results collected here were done without active cooling. Even with the most demanding cpuminer benchmark the SoC temperature was never reported as above 70°C and running cpuminer at 1.4GHz was possible without any throttling. This is NanoPi R2S using the very same RK3328 doing exactly nothing at all at around or above 70°C: If idle temperatures of NanoPi R2S without that little yellow plastic oven are above 50°C then there's clearly something wrong (maybe something trivial as a wrong supply voltage resulting in the thermal sensor reporting BS just as we saw on Orange Pi Zero). Utilizing FriendlyELEC's little yellow plastic oven of course will result in insane temperatures.
  8. Maybe you were drunk at the time and can't remember? Moving posts to threads that are inaccessible is the same as deletion (but maybe you're not able to get this). Apropos deletion. Asides that you have not the slightest idea what you babble here about (totally missing the context) You claim 'it is written in the internet or in one of TKs posts, ahh wait, he deleted everything here'. Care to elaborate what you mean? Here is the list of my 5432 posts so far: -- you almost singlehandedly stopped me from posting more in this forum since it makes absolutely no sense to post in a place where a dumbass with moderator privileges deletes posts (and either doesn't get what he does or simply lies). In case you want to censor again be aware that this post is already archived:
  9. Nope. Netdata is awesome. All I tried to explain is why 'armbianmonitor -r' was an attempt to generate insights about SBC behavior 3 years ago and why netdata is not sufficient for this purpose. Once you look at results the data collection approach completely changes system behavior --> useless for this use case. IMO you should take care of cpufreq scaling on this class of devices and if netdata should generate insights and not just fancy graphs you might want to explore EAS.
  10. Oh, "this forum"... This forum is pretty much irrelevant for what's important. I pushed contents into this forum for over 3 consecutive years trying to attract foreign readers/developers to these contents and get interested in Armbian to get broader adoption and relevance. My goal was to strengthen a small project (back in 2015) to become relevant since my needs are a stable OS distribution on ARM (I'm a server guy, I'm not interested in fancy shit but stable operation). Unfortunately to no avail. In theory both fancy shit and stable operation are possible at the same time but that's not how it works here. Armbian is still in playground mode. And it won't change anytime soon or at all. If the 'project lead' now even thinks about sabotaging Debian's packaging all is lost. There's no 'checks and balances' into place compared to serious software projects if one person simply can decide to do whatever crazy idea strikes his head. It's a problem of ignorance and you can't argue against it if the affected person simply doesn't give a shit. Look at Countless times developers tried to escalate those old and boring problems in a polite way. What happened? It got ignored. In the end this is a single person's project the way it's set up since while all contributing developers always tried to achieve a consensus and conform to (non-existent) rules Igor simply does what he thinks would be the best idea at the very moment. While complaining being overwhelmed he even invests time to make things worse (see the absolutely useless last efforts to change kernel versions for XU4 platform). I'm tired of cleaning up since I can spend my time on more important things. It's not about which OS base to choose but to understand that a project needs rules and defined goals at least if it want to leave playground area and become the basis for 'stable operation'. Unfortunately this is not possible with Armbian. After wasting several days of my life for discussions here with always the same result (Igor doing what he wants to do without communication or even feeling bound to a 'consensus' reached before) it's time to stop. @Tido move my post to the bin as usual!
  11. I've a background in graphic design so I'm pretty sure you don't want to hear the answer. Small hint: it reminds of the 'golden age' of DTP 30 years ago. This pretty much sums up what Armbian is.
  12. Well, why providing correct information if the main goal is just to print some fancy stuff on the screen? The whole motd (login greeting) stuff is broken since ever, in the past it delayed login by insane amounts of time, now it simply displays wrong information but as usual one person doesn't give a shit: (how to deal with years of ignorance? Better stay away from such a waste of time).
  13. Why do you use Gill Sans instead of Armbian's font?
  14. Only if you love monitoring mistake N°1: your monitoring is that heavy that it affects the way your system behaves. The purpose of RPi Monitor is to explore system behavior, e.g. adjust tunables to get sufficient ondemand governor behavior (which is broken on several platforms now but literally no one cares since all remaining devs are busy adding new devices and fancy features). If your monitoring is that heavy that your system will constantly clock at the upper speeds how would you be able to draw reasonable conclusions? Just like you should benchmark every benchmark you're using you should monitor your monitoring solution of choice (quite simple with armbianmonitor -m). Checking out netdata 3 years ago led to the above conclusions when testing on weak SBC. Also SBC stuff like CPU temperature and cpufreq scaling is missing. Netdata will show you CPU utilization only since it's meant for servers that will run on highest clockspeeds all the time. Which SBC is more busy: the one reporting 10% CPU utilization clocking at 1200 MHz or the one reporting 20% remaining at 480 MHz. Netadata's output is useless on systems with cpufreq scaling. It's only great for servers and for operators who know what they're doing. As such it should never be too easy to install it. For those people interested. You can play around with it on ODROID bench:;t=32257#p246987 (please keep in mind that the four instances are S922X installations and this SoC is as capable as Intel Atom designs. Far more capable than the average SBC Armbian supports)
  15. Why do you ignore the answers you get? I explained that Armbian is not supposed to run only on one device but on many. And some of them still run with kernel 3.4. As such do we use up to 4 zram devices. More zram devices than 1 is needed on old kernels and doesn't matter on newer kernels (tested various times, simply search for zram).