tkaiser

  • Posts

    5445
  • Joined

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Everything posted by tkaiser

  1. Orange Pi R2 announced to be available back in April might be ready in November: https://www.cnx-software.com/2018/09/23/realtek-rtd1296-u-boot-linux-source-code-rtd1619-cortex-a55-soc/#comment-556261 I wonder whether the board is still at $79 as announced back in April... BPi people charge $93 for their BPi-W2 but there you need to acquire a Wi-Fi/BT combo card that fits into the M.2 Key E slot separately (and by reading through this mess here choosing Bpi's own RTL8822 card seems to be the best idea -- most probably this chip is part of RealTek's reference design) BTW: SinoVoip is about to throw out a few new and of course totally incompatible boards soon just to ensure software support situation will be the usual mess Watch them here already: http://www.banana-pi.org
  2. The important part there is at the bottom: the need to 'NEON-ize lz4 and/or lzo' which has not happened on ARM yet, that's why lz4 outperforms lzo on x86 (SIMD instructions used) while on ARM it's the opposite. Once some kernel developer will spend some time to add NEON instructions for the in-kernel code for either lzo or lz4 (or maybe even a slower algo) I'll immediately evaluate a detection routine for this based on kernel version since most probably this also then outperforming any other unoptimized algorithm that in theory should be more suited. Missing SIMD optimization on ARM are still a big problem, see for example https://www.cnx-software.com/2018/04/14/optimizing-jpeg-transformations-on-qualcomm-centriq-arm-servers-with-neon-instructions/
  3. Relevant swapping occurred. Still no idea why so I added monitoring of virtual memory settings few hours ago. I'll look into this within the next months but no high priority since there is detailed monitoring in sbc-bench we know exactly why numbers differ currently between Orange Pi One Plus (1 GB) and PineH64 (more than 1 GB).
  4. Nope and I don't think so. I wanted to try the same, did some research and ended up with an Amazon review from someone trying this with the Firefly RK3399 saying the Marvell 9235 adapter he had has some components on the bottom that make it impossible to use it on the board without shorting something. These things look like this: And then on NanoPC-T4 there are only mounting holes for 2280 while the SATA adapters are all 2242. So unless you get a PCIe extender somewhere the M.2 slot is 'SSD only'. Are you aware that FriendlyELEC will provide the below for NanoPi M4 soon (also solving the powering problem):
  5. Ok, this is pure madness here. Won't look into this thread for some time. @ag123 it's really nice that you're creative and able to develop theories about Linux being broken in general (breaking the system by swapping out important daemons -- I guess you also think kernel developers behave that moronic that they allow to swap out the kernel itself?). It also is nice that you ignore reality (@Moklev having reported a system freeze and not sshd being unresponsive). It also doesn't matter that much that you create out of one single report of 'freezes since some time' for reasons yet unknown a proof that there's something wrong with the new vm.swappiness default in Armbian and talk about 'related issues surfaced currently' (issues --> plural). I simply won't read these funny stories any more since they're preventing time better spent on something useful. Here are the download stats: https://dl.armbian.com/_download-stats/ Check when 5.60 has been released, count the number of downloads, count the reports of boards freezing/crashing in the forum and you know about 'issues surfaced currently'.
  6. Are you trolling? Which 'related issues'? I only know of one overheating Orange Pi Zero that for whatever reasons is/was unstable. Zero useful efforts taken to diagnose this single problem other than a huge waste of time right now.
  7. Let's stop here. I won't further waste my time with this 'report' (which is just a bunch of theories, assumptions and a weird methodology to back an idea). @Moklev: I was asking for armbianmonitor -u output but got only a redacted/censored variant (the line numbers are there for a reason). I was asking for what's the output of 'free -m' NOW. As in 'with your vm.swappiness=30 or 60 setting). Instead you rebooted (why?! You can adjust vm.swappiness all the time, no reboot needed). Providing 'free -m' output directly after a reboot is pointless as you see ZERO swapping happened. And providing a log containing information from 14.36.28 until 14.53.31 is pointless too. Ok Yesterday you started monitoring. Now you report having switched from vm.swappiness=30 to 100. But you're able to report that with 100 settings your board froze and even RPi Monitor web page not being accessible. So you tested within the last 29 hours already twice with 100 settings and were able to report your board crashing (since you talk about '3-12 h' -- if these 3-12h is some anecdotical story from days ago I'm not interested in. It's only relevant what happens now with some monitoring installed able to provide insights). I'm interested in resolving real problems if there are any. What happens here is developing weird theories and trying to back them. Unless I get data I won't look any further into this. If you had RPi-Monitor running the graphs are available even after a reboot so you can share them focussing on the last hour prior to latest crash (Cpufreq, temperature, load). Also if 'ssh unreachable, yellow ethernet led fixed on, pihole/motioneye/rpi monitor web pagesunreachable' is the symptom then you report your board having freezes or crashed (and not sshd not being responsive any more).
  8. So what? Armbian supports too many boards for us to handle. Nothing new. The interesting question still is: how do we provide something that could be called 'stable'? It's simply unacceptable that a simple 'apt upgrade' bricks boards or removes basic functionality (which is not the case here now as I understand -- still wondering why there's a comment reading 'network sometimes doesn't work properly' -- but at the beginning of this year we had a bunch of such totally unnecessary issues caused by untested updates rushed out). If it's not possible to prevent such issues (and clearly separating playground area from stable area) the only alternative is to freeze u-boot/kernel updates by default and add to documentation that users when they want to upgrade u-boot and kernel they're responsible for cloning their installation before -- good luck! -- so they can revert to a working version if something breaks.
  9. So where did your comment 'usb hotpluging and network sometimes doesn't work properly' originates from then? I'm not sure whether you get my point: I want Armbian to be a stable distribution. I do not rely unnecessarily on either Debian or Ubuntu with all their 'outdated as hell' software packages if there wouldn't be that great promise of 'being stable'. If I pull in updates I expect that afterwards my device still works. With the userland this is pretty much the case (upstream Debian or Ubuntu) but wrt kernel/u-boot (the Armbian provided stuff) it seems this is impossible. Why did you write 'network sometimes doesn't work properly' in your commit message and especially why did you allow a kernel update for ODROID-C2 that is then supposed to break basic functionality? As already said: I'm fine with USB hotplug issues since USB devices connected at boot are fine for 'stable' use cases. But if there are network issues to be expected I really don't get it why then such a kernel update will be rolled out and not skipped this time? It's about the process! If an update is to be expected to break functionality then why enrolling it? Is it possible to move from playground mode to stable mode? What's the dev branch for when testing obviously also happens in the next branch?
  10. WTF? Can we please stop developing weird theories but focus on what's happening (which requires a diagnostic attempt collecting some data)? Without swap it could be possible that the sshd gets quit by the oom-killer (very very very unlikely though because the memory footprint of sshd is pretty low) but if it would be possible that swapping in Linux results in daemons not responding any more or not fast enough we all would've stopped using Linux a long time ago. And can you please try to understand that we're not talking about 'swap on crappy storage' (HDD) any more but about zram: that's just decompressing swapped out pages back into another memory area which is lightning fast compared to the old attempts with swap on HDD.
  11. But I've been wrong. The background activity was swap/zram in reality.
  12. Seriously: I don't get this policy. But I think any more discussion is useless and Armbian can just not be considered a stable distribution. Or at least people who are interested in stable operation need to freeze kernel and u-boot updates since otherwise updating the software means ending up with a bricked board or some necessary functionality not working any more (and based on Armbian's origin I consider fully functioning network to be the most basic requirement of all -- but I might be wrong and Armbian in the meantime focuses on display stuff trying to compete with Android) I thought once there was a next branch available for ODROID-C2 this could be considered 'stable' (since there's still the 'dev' branch for development and testing). But it seems I've been wrong and we have no definition of 'stable' if it's possible that updates are provided that destroy functionality that has been working flawlessly before. So by accident 'default' seems to be the only stable branch in Armbian for the simple reason no kernel development happens there.
  13. Huh? Can we please stay focused here on an Armbian release upgrade and potential show-stoppers? You brought up the claim that vm.swapiness settings cause crashes without any evidence whatsoever. Let's focus now on collecting some data related to this and keep temperature babbling outside. We all know that certain boards report wrong temperatures anyway (OPi Zero rev 1.4 for example) and the only area where this gets interesting is whether those wrongly reported temperatures cause an emergency shutdown (the kernel's cpufreq framework defines that at a specific critical temperature a shutdown is initiated). So obviously with wrong thermal readouts as we experience on some sunxi boards/platforms we get a 'denial of service' behavior under load. Using the wrong hardware for specific purposes is not the focus of this thread (e.g. using a board with just 512 MB for desktop linux -- that's not a 'use case', that's just plain weird)
  14. Sorry, this thing is doing nothing and especially not swapping. And I'm really not interested in what a MicroServer somewhere on this earth is doing. It's only about Armbian and the claim vm.swappiness=100 would crash your board. So as already said, it would be great if you can provide output from the two commands I asked for now. Since after switching back to vm.swappiness=100 your board is supposed to crash then afterwards it gets interesting to have a look at the two logs (submitted via pastebin.com or some similar online pasteboard service).
  15. So can you please provide output from both 'free -m' and 'armbianmonitor -u' now? Once you switch back to vm.swappiness=100 the VM monitoring script should be adjusted to while true ; do echo -e "\n$(date)" >>/root/free.log free -m >>/root/free.log sync sleep 60 done (same with iostat -- also switching from 600 seconds to 60. And then the 'sync' call above is very important since with default Armbian settings we have a 600 second commit interval so last monitoring entries won't be written to disk without this sync call happening)
  16. https://en.wikipedia.org/wiki/Swappiness https://forum.armbian.com/topic/7819-sbc-bench/?do=findComment&comment=62802 ( Less swap activity with vm.swappiness=1 compared to vm.swappiness=0. So again, this is something that needs further investigation. We can not trust in stuff 'Everyone on the Internet' is telling (like lz4 being better than lzo since at least with ARM it's the other way around).
  17. Is this https://forum.openmediavault.org/index.php/Thread/24299 a known issue with 5.60? In https://github.com/armbian/testings it's written that 'USB hot plugging' doesn't work which is something I'm fine with. But what does 'networking sometimes doesn't work' means exactly? @Igor since I've seen you submitted the test report. What does that mean wrt networking? Isn't the next branch meant as a 'stable' branch where basic functionality has to work flawlessly? Did networking work prior to 5.60 release?
  18. Quick summary: unfortunately all the time throttling happened so results are not comparable other than expected with vm.swappiness=1 less swap activity happened compared to vm.swappiness=0 (while 'everyone on the Internet' will tell you the opposite): vm.swappiness=0 Compression: 2302,2234,2283 Decompression: 5486,5483,5490 Total: 3894,3858,3887 Write: 1168700 Read: 1337688 vm.swappiness=1 Compression: 2338,2260,2261 Decompression: 5506,5480,5512 Total: 3922,3870,3887 Write: 1138240 Read: 941548 vm.swappiness=60 Compression: 2266,2199,2204 Decompression: 5512,5495,5461 Total: 3889,3847,3832 Write: 1385560 Read: 1584220 vm.swappiness=100 Compression: 2261,2190,2200 Decompression: 5421,5485,5436 Total: 3841,3837,3818 Write: 1400808 Read: 1601404 Still no idea why with with Orange Pi Plus and 1 GB RAM massive swapping occurs while the same benchmark on NanoPi Fire3 also with 1 GB results in low swapping attempts (different kernels, maybe different contents of /proc/sys/vm/*)
  19. Haha, but now I know. I was an idiot before since it's simply zram/swap as can be easily seen by comparing iostat output from before and after: before: zram1 0.93 3.69 0.01 1176 4 zram2 0.93 3.69 0.01 1176 4 zram3 0.93 3.69 0.01 1176 4 zram4 0.93 3.69 0.01 1176 4 after: zram1 588.13 1101.08 1251.45 1408792 1601184 zram2 586.62 1094.84 1251.62 1400808 1601404 zram3 582.01 1087.59 1240.44 1391524 1587092 zram4 587.14 1098.00 1250.54 1404848 1600016 That's 5.3GB read and 6.1GB written on the zram devices. I still have no idea why this benchmark on some boards (most probably kernels) runs with 1 GB without swapping but not on others like here: RAM size: 994 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 NanoPi Fire3 also with just 1 GB RAM finishes with only minimal swapping: RAM size: 990 MB, # CPU hardware threads: 8 RAM usage: 901 MB, # Benchmark threads: 8 Maybe vm.swappiness is the culprit. Can you repeat the bench another three times doing the following prior to each run: sysctl -w vm.swappiness=0 sysctl -w vm.swappiness=1 sysctl -w vm.swappiness=60
  20. Anyone catching the irony to keep Micro USB for powering? Guess it all depends on your target audience...
  21. Please take a look at: http://wiki.friendlyarm.com/wiki/index.php/Main_Page#NanoPC.2FPi_Series I would say the majority of boards is based on Samsung SoCs and there S5P6818 and (AFAIK pin compatible) S5P4418 (quad-A9) are the majority. They have several form factors and the majority of numbers at least has some meaning (3 being S5P6818 while 2 is S5P4418 with 'PC', 'NanoPi M' and 'Fire' -- now adding RK3399 to the mix as 4). With Allwinner boards so far the numbers they use have a different meaning. I was only thinking about what could be in between a NEO Plus 2 and a NEO4 and since the software stack is already there and 3 would fit I thought about a S5P6818 variant. We shouldn't forget that FriendlyELEC deals not only with hobbyists like us but their boards get integrated into commercial devices so these customers might like to use same form factor and cooling attempts (SoC on same PCB side) but simply switch between SoCs based on use case. Anyway: just wanted to point out that NEO4 is nothing entirely new with this form factor but there is at least some consistency (H5 based NEO Plus 2) and since FriendlyELEC is quite smart and cares about software support and compatibility maybe this will be the start of another 'series' that has not that much in common with the headless Allwinner NEO family. At least I would like to see a S5P6818 board with better passive heat dissipation (heatsinks on both Fire3 and NanoPC are too small IMO). Well, back to NEO4... while thinking about S5P6818 and its limitations (especially IO) I again thought about what could be possible with PCIe here on this RK3399 tiny board. For example a dual Gigabit Ethernet HAT using an Intel 82576 or similar chips so we would get an ultra tiny router thingy with 3 fast Gigabit Ethernet adapters. I've seen @hjc is experimenting with several USB3 based Gigabit Ethernet chips connected to NanoPi M4 but switching to PCIe might improve latency here? I mean we have PCIe standardized connectors on other RK3399 boards already. But M.2 on NanoPC-T4 won't work with anything else than a SSD without a bulky PCIe Extender, with RockPro64 or Rock960 EE board there's a full PCIe slot so everything is large. Currently those proprietary pin header PCIe implementations on NEO4 and NanoPi M4 combined with interesting HATs look quite appealing to me.
  22. That's due to package 'linux-stretch-root-next-bananapim64' remaining at 5.59. I don't understand this since years. The mechanism is broken, confuses users and generates unnecessary support requests. Why not fixing it or at least always update this package too with version bumps?
  23. Well, it allows for a couple more use cases so why not. Adding the HDMI connector costs a lot of PCB space on such a tiny board but most probably increasing the BOM by just a few cents. Running headless Linux thingies is not the only use case in this world @mindee said they got camera support working already in Linux so most probably this also applies to HW accelerated video decoding and then this little thing could be useful for a lot of scenarios.
  24. Same form factor and connector positions like NEO Plus 2, also same position of CPU on the bottom PCB side to ease heat dissipation with massive heatsink. Wonder whether we see an octa-core NEO3 with S5P6818 soon...
  25. Thanks for the reminder. I totally forgot that running databases is amongst valid use cases. Based on my testings so far neither databases nor ZFS play very well with zram so the only reasonable vm.swappiness value with both use cases is IMO 0 (which means disable swap entirely starting with kernel 3.5 as far as I know, prior to that behavior at 0 was the same as 1 today) and using an appropriate amount of physical RAM for the use case or tune the application (calling ZFS an application too since default behavior to eat all available RAM except 1 GB for its own filesystem cache can be easily configured) I added this to the release log right now. Yesterday throughout the whole day I did some more testing even with those recommendations back from the days when we all did something horribly stupid: swapping to HDDs. I tested with vm.swappiness=10 and vm.vfs_cache_pressure=50 and got exactly same results as with both tunables set to 100 for the simple reason that the kernel limited the page cache in almost the same way with my workload (huge compile job). No differences in behavior, just slightly slower with reduced vm.swappiness. So it depends on the use case, how situation with page cache looks like vs. application memory. But all numbers and explanations we find deal with swap on slow storage and/or are from 15 years ago. But today we're talking about something entirely different: no swap on ultra slow storage but compressing/decompressing memory on demand. Back in the old days with high swappiness of course you run into trouble once pages have to swapped back in from disk (switching to Chromium and waiting 20-40 seconds). But we're now talking about something entirely different. 'Aggressively swapping' with zram only is not high disk IO with slow storage any more but 'making better use of available memory' by compressing as much as least used pages as possible (again: what we have in Linux is way more primitive compared to e.g. Darwin/XNU). And what really turns me down is this: That's a oversimplified presentation of what's happening around swapping in Linux. And people now only focus on one single tunable they don't even understand for the sole reason they think it would be a percentage value (something that's not that complex as VM reality and something they're used to and feel they could handle) and feel it could be too 'aggressive' based on all the wrong babbling on the Internet about what vm.swappiness seems to be. What everyone here is forgetting: with latest release we switched with vm.swappiness from '0' (no swap) to 'some number greater than 0' (swapping allowed). Of course this will affect installations and it might trigger bugs that got undetected for the simple reason that Armbian did not swap at all for the last years. So please can we now focus on what's important again and don't waste our time with feelings, believes and (mostly) wrong assumptions (not talking about you here).