tkaiser
-
Posts
5462 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tkaiser
-
-
6 minutes ago, emk2203 said:
The fact that they promise mainline kernel, starting from 4.19, actually made me buy it. All ARM devices are sketchy in this regard.
Well, depends solely on the SoC used. I just did some benchmarks with 4.19 on one of my RK3399 devices yesterday: https://forum.armbian.com/topic/8161-swap-on-sbc/?do=findComment&comment=61637
Wrt features I'm not that much interested in (anything that requires adding a display to the boards) I wouldn't count on every feature available with mainline Linux (or Linux at all) regardless of SoC. But honestly I don't know enough about these areas and even managed to spread BS already.
-
1 hour ago, botfap said:
Lzo was faster and less cpu intensive overall despite lz4 being better on paper (and from the opinions of almost every internet warrior)
Ok, so another time the same observation. Maybe we should switch back to lzo then already. I feared my test always using the same task is somewhat flawed. At least it's configurable as SWAP_ALGORITHM in /etc/default/armbian-zram-config. But starting with the best default is for sure a good thing prior to next major release when this stuff gets rolled out.
1 hour ago, botfap said:Do you know which variant of lzo is being used by Armbian?
Nope. I simply used default kernel settings (and only tested with Rockchip 4.4, mainline 4.14 on NanoPi Fire3 and 4.19 on RK3399). How to configure the specific algorithm?
Edit: another interesting observation: https://bugs.chromium.org/p/chromium/issues/detail?id=584437#c15 I really wonder whether the compression algorithms on ARM use NEON optimizations or not (the performance boost can be huge)
-
On 9/11/2018 at 7:03 AM, tkaiser said:
Well, the first thing I would try to improve is replacing the thermal pad with something with a lot better heat conductivity
I did just that:
The thick thermal pad has been removed and replaced with a 15x15mm copper shim (0.8mm height). The grey stuff around the SoC are leftovers from another thermal pad (came with RockPro64) just to prevent shorting things with the heatsink.
I tried to use sbc-bench in thermal testing mode. NanoPi Fire is in upright position (so convection might help a little bit) in a room with 24°C ambient temperature.
sbc-bench.sh -T 80 ; sbc-bench.sh -t 60Problem N° 1: with stock thermal pad I would have to wait endlessly for the SoC to cool down below 60°C (that what 'sbc-bench.sh -t 60' is supposed to do). The board once hot remained at 62°C to 63°C. I had to temporarely switch cpufreq governor to let the CPU cores clock down from 1400 to 400 MHz to get an idle temperature below 60°C again.
Then numbers were as follows:
1400 MHz: 146.17 sec 1300 MHz: 148.42 sec 1200 MHz: 0 sec 1100 MHz: 0 sec 1000 MHz: 0 sec 900 MHz: 0 sec 800 MHz: 0 sec 700 MHz: 0 sec 600 MHz: 0 sec 500 MHz: 0 sec 400 MHz: 5.80 sec(the 6 seconds on 400 MHz are not result of throttling but me manually switching back to performance cpufreq governor once the real benchmark run started). Full output where you can see how long it took to cool down from 80°C to 60°C: https://pastebin.com/raw/1DDt8yGk
Now with copper shim instead of thermal pad.
Problem N° 2: now it's impossible for the 'pre-heat' run to get above 80°C. I would have to wait endlessly for this so I stopped and ran 'sbc-bench.sh -T 78 ; sbc-bench.sh -t 60' instead to only wait until temperature exceeds 78°C. Full output: https://pastebin.com/raw/a0vmQJ0b
No throttling happened and temperature remained below 80°C. Again it's obvious that thermal pads simply suck when it's about efficient heat dissipation. But I've to admit that I've no idea whether the contact area now with my copper shim is sufficient or thermal pads are the recommended way since with my copper shim now only the very small die area and the copper shim have contact while the area around not.
@mindee can you please shed some light?
Edit: haha, today I realized that I ran with just 4 CPU cores active yesterday when I made my tests due to 'maxcpus=4' set in /boot/armbianEnv.txt (to test for swap efficiency of various approaches). Doesn't change anything wrt thermal conductivity but of course now with all 8 CPU cores active NanoPi Fire3 starts to throttle severely when running heavy stuff but at least with copper shim clockspeeds are much higher compared to thermal pad.
-
4 hours ago, gounthar said:
I may run some tests to help...
Well, if Libre Computer is interested in getting Armbian on their boards at least some developers need samples. And wrt testing: It's a RK3399 thing so almost everything is already known.
Only interesting: how fast is memory access (are different DRAM initialization BLOBs used or not?), how fast is the eMMC and how well works heat dissipation. So iozone and sbc-bench and done.
To me Renegade Elite looks more like an ARM device for a couple of professional use cases (mainly dealing with cameras and imaging) running Android. But it seems enthousiasts are not scared away by costs and want to run Linux for whatever reasons...
Almost forgot: Of course compatibility testing with various USB-C PSUs might be interesting as well. @gounthar which USB-C chargers do you own? 'Good' ones from this list?
-
Little update: In the meantime I also tested with the really fast Samsung 16GB eMMC 5.1 on NanoPC-T4 (again crippled down to a quad-core A53 at 800 MHz). The board runs off the NVMe SSD, I mounted the eMMC as an ext4 partition, put there ARM's ComputeLibrary install and the swapfile on and fired up the test again. First post above is updated.
With 4 GB RAM and no swap 100:39 minutes, with swapping on the fast NVMe SSD 118:47 and just 133:34 on the eMMC:
w/o nvme lzo lz4 emmc usb2 usb3 hdd sd card real 100m39 118m47 125m26 127m46 133m34 146m49 154m51 481m19 1151m21That's impressive. But this Samsung eMMC 5.1 on NanoPC-T4 (and also on ODROID-N1) is most probably the fastest eMMC we get on SBC today (see benchmark numbers). And still zram is faster and we get 'more RAM' for free (since swap on flash media contributes to the medium wearing out of course)
-
On 9/10/2018 at 12:32 AM, tkaiser said:
Next test: RK3399 with unlocked performance (all 6 CPU cores active at usual clockspeeds: 1.5/2.0GHz)
w/o nvme lzo/2 lzo/6 lz4/2 lz4/6 real 31m55 40m32 41m56 41m38 43m57 44m26 user 184m16 194m58 200m37 202m20 195m17 197m51 sys 6m04 16m17 25m02 23m14 40m59 42m15All those tests I did before were done with Rockchip's 4.4 kernel.
Since stuff in the kernel improves over time now let's test with brand new 4.19.0-rc1. I just did a quick build (with default device tree that limits maximum cpufreq to 1.8 GHz on the big and 1.4 GHz on the little cores) and only tested performance without swapping and zram based swap with the available algorithms (more recent kernels provide more compression algorithms to choose from):
w/o lzo lz4 zstd lz4hc real 29m11 35m58 36m59 48m38 58m55 user 167m59 177m24 175m22 182m02 173m57 sys 5m32 21m10 22m59 69m35 123m46Results:
- More recent kernel --> better results. Even with lower clockspeeds (1.8/1.4 GHz vs. 2.0/1.5 GHz) the test with kernel 4.19 runs 8% faster. So at same clockspeed this would result even in ~10% better performance
- Performance drop with zram/lzo compared to no swap with 4.4 was 31%. With 4.19 it's just 23%. So efficiency/performance of the zram implementation itself also improved a lot
- Again lzo is slightly faster than lz4, both zstd and lz4hc are no good candidates for this use case (but zstd is a great candidate for Armbian's new ramlog approach since it provides higher compression -- more on this later)
In other words: with mainline kernel it makes even more sense to swap to a compressed block device in RAM since performance further increased. With this specific use case (large compile job) the performance drop when running out of memory and the kernel starting to swap to zram is below the 25% margin which is just awesome
-
On 6/1/2018 at 8:04 PM, shaun27 said:
double check that the thermal pad they provided didn't move when you were installing the heatsink
Well, the first thing I would try to improve is replacing the thermal pad with something with a lot better heat conductivity, see https://forum.armbian.com/topic/8125-quick-review-of-nanopi-k1-plus/?do=findComment&comment=61417
-
19 hours ago, sakibnaz said:
Do you know how the performance of 3328 Boards like Rock64 for USB 3.0 Data?
It's all there, just use the search functionality this forum provides:
- https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=51350
- Allwinner H6 (preliminary -- things might improve): https://forum.armbian.com/topic/7118-trying-to-compile-pine-h64/?do=findComment&comment=59603
-
On 9/9/2018 at 11:30 AM, gounthar said:
only one choice for eMMC, which is the 128GB
Honestly: if I have a RK3399 device and want 128 GB storage I choose something different. I ordered a cheap DRAM less NVMe SSD for 40€ (VAT/shipping included), inserted it into the M.2 slot, transferred the rootfs as easy as always with nand-sata-install and now my NanoPC-T4 runs directly off the NVMe SSD.
I've no doubt that the eMMC performs nicely. But I doubt it's as fast as an NVMe SSD and what I like the most with SSDs: the good ones tell you when they start to wear out:
root@nanopct4:/home/tk# smartctl -x /dev/nvme0n1 smartctl 6.6 2016-05-31 r4324 [aarch64-linux-4.4.153-rk3399] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Number: TS128GMTE110S Serial Number: AC2153AAE531202E0165 Firmware Version: R0515A0 PCI Vendor/Subsystem ID: 0x126f IEEE OUI Identifier: 0x000000 Controller ID: 1 Number of Namespaces: 1 Namespace 1 Size/Capacity: 128,035,676,160 [128 GB] Namespace 1 Formatted LBA Size: 512 Local Time is: Mon Sep 10 18:38:24 2018 UTC Firmware Updates (0x14): 2 Slots, no Reset required Optional Admin Commands (0x0006): Format Frmw_DL Optional NVM Commands (0x005f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat *Other* Maximum Data Transfer Size: 64 Pages Warning Comp. Temp. Threshold: 70 Celsius Critical Comp. Temp. Threshold: 80 Celsius Supported Power States St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat 0 + 9.00W - - 0 0 0 0 0 0 Supported LBA Sizes (NSID 0x1) Id Fmt Data Metadt Rel_Perf 0 + 512 0 0 === START OF SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED SMART/Health Information (NVMe Log 0x02, NSID 0x1) Critical Warning: 0x00 Temperature: 28 Celsius Available Spare: 100% Available Spare Threshold: 10% Percentage Used: 0% Data Units Read: 110,342 [56.4 GB] Data Units Written: 289,050 [147 GB] Host Read Commands: 11,897,227 Host Write Commands: 22,892,268 Controller Busy Time: 126 Power Cycles: 10 Power On Hours: 1 Unsafe Shutdowns: 4 Media and Data Integrity Errors: 0 Error Information Log Entries: 0 Warning Comp. Temperature Time: 0 Critical Comp. Temperature Time: 0The 'Percentage Used' line is the important one. As long as this is below 90 everything's fine. An eMMC will die suddenly without any prior warning...
-
5 hours ago, Tido said:
systemctl disable NetworkManager.service
Not a good idea as Zador already explained: https://forum.armbian.com/topic/6104-network-manager-woes/?do=findComment&comment=46901 -- people not able to cope with NM should better entirely remove it.
2 hours ago, gleam said:So I once will have DHCP never again. Never, never!
Interesting way to 'spend' your own time. One of the first things I always do at new customers is to stop configuring statically assigned addresses on each server machine to centrally configured static IP addresses via DHCP. If name resolution is set up correctly not even this would be necessary since names are consistent and addresses don't matter anyway...
-
5 hours ago, mindee said:
very helpful for someone who want to know about the NVME SSD real performance on RK3399 boards
In fact I bought cheap since I got the NVMe SSD for less than 40 bucks on sale. My small TS128GMTE110S has soldered only 2 flash chips on it, if the maximum would be present (8) then it would be much much faster since all modern SSD controllers make heavy use of paralellisms (the more flash chips the faster).
I did a quick iozone test with kernel 4.4 and results look not that great compared to an EVO 960 for example.
Transcend TS128GMTE110S ext4 random random kB reclen write rewrite read reread read write 102400 4 81473 115499 145683 147298 40272 82992 102400 16 179264 249123 293189 293318 111869 246077 102400 512 578704 579090 829601 832798 658995 567873 102400 1024 585086 577757 928864 935910 789642 565868 102400 16384 527840 531048 1045632 1056965 1031390 546275 2048000 16384 544678 549905 1064665 1064439 1039331 545381But that's not relevant since the protocol makes the difference. NVMe has been invented in this century and not the last as all the other storage protocols we use today. And this makes a real difference since NVMe has been developed with accessing flash storage efficiently in mind. All the other protocols we might use (including SATA) were designed decades ago for way slower storage and all do bottleneck access to fast flash.
With swap on the NVMe SSD the maximum %iowait percentage according to iostat monitoring was 0.37%. That's 70 times less compared to up to 25.07% with USB3!
-
Next test: RK3399 with unlocked performance (all 6 CPU cores active at usual clockspeeds: 1.5/2.0GHz)
w/o nvme lzo/2 lzo/6 lz4/2 lz4/6 real 31m55 40m32 41m56 41m38 43m57 44m26 user 184m16 194m58 200m37 202m20 195m17 197m51 sys 6m04 16m17 25m02 23m14 40m59 42m15Full test output:
Without Swap: real 31m55.360s user 184m16.317s sys 6m3.999s avg-cpu: %user %nice %system %iowait %steal %idle 96.78 0.00 3.11 0.00 0.00 0.11 96.56 0.00 3.30 0.00 0.00 0.14 11.57 0.00 0.42 0.00 0.00 88.01 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 0.56 0.09 36.40 80 32758 mmcblk1 1.53 6.29 95.42 5664 85876 mmcblk1 0.14 0.26 29.38 232 26440 lzo 2 streams: real 41m56.261s user 200m36.964s sys 25m2.247s avg-cpu: %user %nice %system %iowait %steal %idle 79.01 0.00 20.70 0.04 0.00 0.25 83.46 0.00 16.40 0.00 0.00 0.14 61.40 0.00 17.19 0.01 0.00 21.40 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn zram1 10000.57 15515.19 24487.10 13963672 22038392 zram2 9994.63 15491.28 24487.23 13942156 22038508 zram1 10381.19 17556.42 23968.32 15800952 21571732 zram2 10378.70 17546.46 23968.32 15791988 21571732 zram1 9469.21 16759.32 21117.53 15083392 19005776 zram2 9455.55 16704.60 21117.59 15034136 19005828 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 83.01 8366.31 33.08 7529680 29776 mmcblk1 38.71 2303.10 58.27 2072816 52444 mmcblk1 46.68 2686.10 50.05 2417489 45048 lzo 6 streams: real 41m38.302s user 202m20.016s sys 23m14.408s avg-cpu: %user %nice %system %iowait %steal %idle 83.18 0.00 16.71 0.00 0.00 0.11 82.59 0.00 17.29 0.01 0.00 0.11 59.98 0.00 16.90 0.01 0.00 23.11 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn zram1 3039.69 4346.14 7812.62 3911524 7031360 zram2 3040.84 4350.74 7812.63 3915668 7031364 zram3 3038.73 4342.47 7812.44 3908220 7031196 zram4 3039.70 4346.43 7812.39 3911784 7031148 zram5 3038.88 4342.94 7812.59 3908648 7031328 zram6 3040.02 4347.62 7812.47 3912860 7031220 zram1 3416.83 5791.84 7875.48 5212656 7087936 zram2 3417.75 5795.52 7875.49 5215968 7087944 zram3 3419.16 5801.10 7875.53 5220992 7087980 zram4 3417.88 5795.81 7875.70 5216232 7088132 zram5 3418.87 5799.86 7875.61 5219872 7088048 zram6 3419.90 5804.16 7875.44 5223740 7087896 zram1 3060.02 5409.21 6830.87 4868344 6147848 zram2 3059.34 5406.76 6830.61 4866136 6147616 zram3 3059.39 5406.96 6830.61 4866316 6147616 zram4 3060.38 5410.83 6830.70 4869800 6147696 zram5 3060.49 5411.10 6830.87 4870040 6147848 zram6 3059.70 5407.84 6830.96 4867112 6147932 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 52.03 3429.48 32.36 3086532 29120 mmcblk1 37.18 2246.65 58.60 2021988 52740 mmcblk1 47.53 2735.41 52.83 2461900 47544 lz4 2 streams: real 43m57.637s user 195m17.556s sys 40m59.904s avg-cpu: %user %nice %system %iowait %steal %idle 77.08 0.00 22.16 0.03 0.00 0.73 75.15 0.00 23.91 0.02 0.00 0.92 65.67 0.00 25.35 0.03 0.00 8.94 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn zram1 8801.74 12553.56 22653.41 11298200 20388072 zram2 8800.08 12547.31 22653.00 11292580 20387704 zram1 11100.47 18802.53 25599.34 16922840 23040176 zram2 11099.44 18798.44 25599.32 16919156 23040156 zram1 10362.92 18539.87 22911.82 16685884 20620640 zram2 10355.76 18511.28 22911.76 16660152 20620584 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 66.22 4788.56 31.21 4309700 28092 mmcblk1 57.70 3918.69 57.91 3526936 52124 mmcblk1 66.55 3865.90 57.75 3479308 51976 lz4 6 streams: real 44m26.940s user 197m51.586s sys 42m15.525s avg-cpu: %user %nice %system %iowait %steal %idle 77.44 0.00 22.18 0.02 0.00 0.35 75.06 0.00 24.54 0.01 0.00 0.38 68.29 0.00 26.81 0.02 0.00 4.88 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn zram1 2866.07 4112.82 7351.47 3701580 6616400 zram2 2866.50 4114.47 7351.54 3703064 6616464 zram3 2866.32 4113.75 7351.52 3702416 6616444 zram4 2868.42 4122.26 7351.44 3710072 6616372 zram5 2865.52 4110.65 7351.45 3699624 6616380 zram6 2867.04 4116.73 7351.44 3705100 6616368 zram1 3610.06 6068.57 8371.69 5461832 7534688 zram2 3608.80 6063.51 8371.70 5457276 7534700 zram3 3608.88 6063.82 8371.70 5457560 7534700 zram4 3612.11 6076.78 8371.65 5469228 7534652 zram5 3608.69 6062.87 8371.88 5456704 7534856 zram6 3609.15 6064.71 8371.88 5458364 7534856 zram1 3628.46 6460.98 8052.86 5814944 7247656 zram2 3626.32 6452.34 8052.93 5807168 7247720 zram3 3626.74 6454.27 8052.68 5808912 7247492 zram4 3627.31 6456.32 8052.91 5810752 7247700 zram5 3627.74 6458.25 8052.71 5812488 7247520 zram6 3629.89 6466.64 8052.92 5820044 7247708 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 64.98 4413.62 30.87 3972300 27780 mmcblk1 56.31 3752.78 59.29 3377580 53364 mmcblk1 67.02 4039.19 58.18 3635312 52360 NVMe SSD: real 40m32.985s user 194m58.775s sys 16m17.506s avg-cpu: %user %nice %system %iowait %steal %idle 87.55 0.00 11.60 0.62 0.00 0.23 85.85 0.00 11.29 2.42 0.00 0.45 85.85 0.00 11.29 2.42 0.00 0.45 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn nvme0n1 10178.30 12957.70 27755.50 11662060 24980224 nvme0n1 12027.94 22808.95 25302.80 20528052 22772516 nvme0n1 12027.94 22808.95 25302.80 20528052 22772516 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 44.03 2983.29 31.68 2684992 28508 mmcblk1 22.29 930.41 17.25 837372 15524 mmcblk1 22.29 930.41 17.25 837372 15524For obvious reasons I did not test the crappy variants again (HDD, SD card, USB attached anything). So we're only looking at performance without swap, swap on NVMe SSD and zram.
RK3399 when allowed to run at full speed finishes the same compile job in less than 32 minutes. Swap on NVMe SSD increases time by almost 30% now. I now also compared whether the count of zram devices makes a difference (still on RK's 4.4 kernel). Still lzo outperforms lz4 (which is irritating since everyone tells you lz4 would be an improvement over lzo) but there is no clear answer about count of zram devices (in fact the kernel uses 1-n streams to access each device so with modern kernels even a single zram device should suffice since kernel takes care of distributing the load accross all the CPU cores)
-
This is some more research based on prior efforts.
The goal is to make more efficient use of available RAM. If the system runs low on memory only two options are possible: either the kernel invokes the oom-killer to quit tasks to free memory (oom --> out of memory) or starting to swap.
Swap is a problem if it happens on slow media. 'Slow' media usually describes the situation on SBC. 'Average' SD cards (not A1 rated) are slow as hell when it's about random IO performance. So swapping is usually something that should be avoided. But... technology improves over time.
In Linux we're able to swap not only to physical storage but since a few years also to compressed memory. If you want to get the details simply do a web search for zram or check Wikipedia first..
Test setup is a NanoPC-T4 equipped with 4 GB RAM (RK3399 based so a big.LITTLE design with 2xA72 and 4xA53). I crippled the board down to being a quad-core A53 running at 800 MHz where I can easily switch between 4GB RAM and lower numbers: Adding 'mem=1110M maxcpus=4' to kernel cmdline results in the A72 cores being inactive, the kernel only using 1 GB DRAM and for whatever reasons cpufreq scaling not working so the RK3399 statically being clocked at 808 MHz. All tests done with RK's 4.4 (4.4.152).
This test setup is meant as 'worst case possible'. A quad-core A53 at 800 MHz is more or less equivalent to a quad-core A7 running at ~1000-1100 MHz. So we're trying to test with the lower limit.
I used a compile job that requires up to 2.6 GB RAM to be built (based on this blog post). The task is to build ARM's Compute Library which involves swapping on systems with less than 3 GB memory. Let's have a look:
In the following I tried a couple of different scenarios: Swap on physical media and also two different zram algorithms:
- w/o: no swapping happened since board booted with full 4GB RAM active
- nvme: Transcend TS128GMTE110S SSD in M.2 slot, link is established at x4 Gen2
- emmc: the 16GB ultra fast Samsung eMMC 5.1 on NanoPC-T4
- usb2: Samsung EVO840 SSD in JMS567 disk enclosure, attached to USB2 port (UAS works)
- usb3: Samsung EVO840 SSD in JMS567 disk enclosure, attached to USB3 port (UAS works)
- hdd: Samsung HM500JI 2.5" HDD in JMS567 disk enclosure, attached to USB2 port (UAS works)
- sd card: 'average' SanDisk 8 GB SD card (not A1 rated so horribly low random IO performance)
- lzo: zram with lzo as compression algorithm
-
lz4: zram with lz4 as compression algorithm
And the numbers are:
w/o nvme lzo lz4 emmc usb2 usb3 hdd sd card real 100m39 118m47 125m26 127m46 133m34 146m49 154m51 481m19 1151m21 user 389m48 415m38 405m39 402m52 415m38 415m29 407m18 346m28 342m49 sys 11m05 29m37 36m14 60m01 34m35 66m59 65m44 23m05 216m25You need to look at the 1st row: that's the time the whole job took. For more details consult the 'time' manual page.
In other words: When limiting the RK3399 on NanoPC-T4 to just the four A53 cores running at 800 MHz the compile job takes 100 minutes with 4 GB RAM. As soon as we limit the available RAM to 1 GB swapping has to occur so it gets interesting how efficient the various approaches are:
- NVMe SSD is the fastest option. Performance drop only 18%. That's due to NVMe being a modern storage protocol suited for modern (multi-core) CPUs. Problem: there's no PCIe and therefore no NVMe on the majority of SBC
- Zram with both lzo and lz4 algorithms performs more or less the same (interestingly lzo slightly faster)
- Slightly slower: the fast Samsung eMMC 5.1
- Surprisingly the EVO840 SSD connected via USB2 performs better than connected via USB3 (some thoughts on this)
- Using a HDD for swap is BS (and was BS already the last 4 decades but we had no alternative until SSDs appeared). The compile job needs almost 5 times longer to complete since all HDD suck at random IO
- Using an average SD card for swap is just horrible. The job that finished within 100 minutes with 4 GB DRAM available took over 19 HOURS with swap on an average SD card (please note that today usual A1 rated SD cards are magnitudes faster and easily outperform HDDs)
Summarizing: NVMe SSDs are no general option (since only available on some RK3399 boards). Swap on HDD or SD card is insane. Swap on USB connected SSDs performs ok-ish (~1.5 times slower) so the best option is to use compressed DRAM. We get a performance drop of just 25% at no additional cost. That's amazing.
The above numbers were 'worst case'. That's why I crippled the RK3399 to a slow performing quad-core A53. You get the idea how 'worse' zram might be on the slowest SBCs Armbian runs on (I know that there are still the boring Allwinner A20 boards around -- yep, they're too slow for this).
When I did all this boring test stuff I always recorded the environment using 'iostat 1800' (reports every 30 minutes what really happened and shows in detail how much data has been transferred and on which the CPU cores spent time). Quite interesting to compare %user, %sys and especially %iowait percentages:
Without swap: real 100m39.355s user 389m48.308s sys 11m5.366s avg-cpu: %user %nice %system %iowait %steal %idle 97.14 0.00 2.81 0.00 0.00 0.05 98.11 0.00 1.89 0.00 0.00 0.00 96.49 0.00 3.51 0.00 0.00 0.00 33.63 0.00 1.17 0.00 0.00 65.20 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 0.39 6.19 15.34 11136 27604 mmcblk1 0.12 0.01 7.08 24 12748 mmcblk1 0.29 0.04 29.12 76 52408 mmcblk1 0.15 0.16 17.47 280 31444 128 GB NVMe SSD (Transcend TS128GMTE110S) real 118m47.028s user 415m38.041s sys 29m37.947s avg-cpu: %user %nice %system %iowait %steal %idle 90.17 0.00 9.83 0.00 0.00 0.00 89.09 0.00 10.65 0.24 0.00 0.02 89.06 0.00 10.87 0.06 0.00 0.01 79.83 0.00 13.75 0.37 0.00 6.05 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn nvme0n1 3531.51 4049.97 10076.08 7290020 18137140 nvme0n1 4389.70 6759.53 10799.27 12167156 19438688 nvme0n1 4196.89 7548.11 9239.46 13586596 16631036 nvme0n1 5397.18 7772.77 13815.96 13990984 24868736 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 8.60 494.36 15.36 889860 27656 mmcblk1 5.43 300.62 5.71 541120 10276 mmcblk1 7.35 332.49 29.08 598480 52336 mmcblk1 11.18 587.00 20.49 1056608 36876 Samsung eMMC 5.1 real 133m34.405s user 415m38.955s sys 34m35.487s avg-cpu: %user %nice %system %iowait %steal %idle 86.06 0.00 9.33 4.02 0.00 0.59 82.91 0.00 11.93 4.61 0.00 0.54 78.06 0.00 13.79 7.60 0.00 0.55 79.67 0.00 12.85 6.67 0.00 0.81 23.34 0.00 4.78 5.33 0.00 66.55 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 885.85 3661.18 7399.21 6590168 13318660 mmcblk1 1525.72 5780.62 7345.17 10405124 13221300 mmcblk1 2074.55 7532.86 6865.80 13559216 12358516 mmcblk1 1465.59 5757.48 7218.02 10363516 12992516 mmcblk1 768.81 2683.68 3888.00 4830624 6998408 Samsung EVO840 USB3 (Class=Mass Storage, Driver=uas, 5000M) real 154m51.541s user 407m18.963s sys 65m44.394s avg-cpu: %user %nice %system %iowait %steal %idle 83.58 0.00 12.39 3.89 0.00 0.14 75.49 0.00 16.36 7.95 0.00 0.20 54.74 0.00 19.54 25.07 0.00 0.65 74.57 0.00 16.33 8.83 0.00 0.27 51.38 0.00 22.86 24.88 0.00 0.88 5.81 0.00 1.01 0.57 0.00 92.60 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 899.99 3277.29 7391.12 5899448 13304748 sda 1771.87 4602.59 5641.83 8284336 10154892 sda 2859.21 7020.32 7443.85 12636572 13398932 sda 1627.26 4463.28 4558.92 8033988 8206140 sda 2986.07 8075.17 10204.91 14535304 18368832 sda 114.34 433.28 234.57 779896 422224 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 8.76 449.59 14.97 809300 26944 mmcblk1 6.06 225.07 4.76 405108 8564 mmcblk1 6.22 212.92 4.06 383248 7304 mmcblk1 7.90 290.09 28.89 522164 52008 mmcblk1 8.65 373.69 4.33 672648 7796 mmcblk1 0.74 25.53 15.89 45956 28596 Samsung EVO840 USB2 (Class=Mass Storage, Driver=uas, 480M) real 146m49.211s user 415m29.511s sys 66m59.827s avg-cpu: %user %nice %system %iowait %steal %idle 82.26 0.00 11.60 5.52 0.00 0.63 77.11 0.00 16.94 5.68 0.00 0.27 67.59 0.00 19.14 12.92 0.00 0.35 78.39 0.00 18.05 3.50 0.00 0.07 44.69 0.00 13.18 15.43 0.00 26.70 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 875.49 3208.80 6997.15 5775896 12595008 sda 1791.04 4718.25 5574.88 8493692 10035784 sda 2491.66 6055.81 6341.38 10900164 11414168 sda 1844.43 5053.24 4258.27 9095928 7664972 sda 1854.93 4253.01 5503.57 7655424 9906428 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 5.74 360.25 14.36 648456 25856 mmcblk1 3.96 176.13 4.72 317068 8504 mmcblk1 5.94 173.85 4.32 312916 7776 mmcblk1 6.75 182.92 7.72 329256 13888 mmcblk1 6.43 259.09 39.36 466356 70856 SAMSUNG HM500JI USB2 (Class=Mass Storage, Driver=uas, 480M) real 481m19.903s user 346m28.221s sys 23m5.888s avg-cpu: %user %nice %system %iowait %steal %idle 62.34 0.00 5.30 26.52 0.00 5.84 47.05 0.00 3.66 45.03 0.00 4.27 30.16 0.00 2.33 60.95 0.00 6.55 37.39 0.00 3.19 52.27 0.00 7.15 47.45 0.00 4.44 42.35 0.00 5.76 16.43 0.00 1.47 52.25 0.00 29.85 1.86 0.00 0.72 46.10 0.00 51.32 2.40 0.00 0.70 54.83 0.00 42.08 1.83 0.00 0.60 52.51 0.00 45.06 2.38 0.00 0.61 54.73 0.00 42.28 3.41 0.00 0.72 60.17 0.00 35.70 2.12 0.00 0.60 53.32 0.00 43.97 2.89 0.00 0.58 58.69 0.00 37.84 3.39 0.00 0.68 60.29 0.00 35.63 3.35 0.00 0.65 52.47 0.00 43.53 24.89 0.00 0.51 23.60 0.00 51.00 0.46 0.00 0.05 0.43 0.00 99.05 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 202.08 1103.73 2568.98 1987224 4625352 sda 210.18 823.92 759.15 1483160 1366572 sda 251.15 614.00 1118.09 1105060 2012324 sda 243.75 637.75 562.81 1147928 1013036 sda 242.72 535.27 757.41 963668 1363592 sda 179.62 584.52 240.07 1052216 432164 sda 183.93 595.70 468.54 1072096 843248 sda 196.65 569.87 352.33 1025772 634192 sda 185.96 533.97 285.93 961144 514676 sda 190.90 503.49 303.76 906288 546772 sda 189.79 479.81 467.16 863660 840892 sda 174.72 498.87 315.20 897960 567356 sda 178.52 462.67 278.10 832800 500588 sda 192.74 449.58 405.82 809244 730484 sda 183.37 497.22 350.15 894996 630268 sda 74.32 312.27 14.20 562084 25560 sda 2.92 12.27 0.00 22092 0 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 5.04 331.77 14.07 597332 25332 mmcblk1 0.85 27.32 5.08 49172 9144 mmcblk1 0.47 45.07 1.68 81124 3032 mmcblk1 1.67 41.63 5.73 74924 10312 mmcblk1 3.30 79.95 5.89 143936 10612 mmcblk1 0.99 24.50 2.61 44108 4692 mmcblk1 0.06 8.91 0.48 16036 860 mmcblk1 0.11 10.18 1.02 18328 1828 mmcblk1 0.08 10.23 1.04 18416 1876 mmcblk1 0.03 4.24 0.98 7640 1764 mmcblk1 0.02 3.66 0.45 6580 812 mmcblk1 0.05 7.84 1.00 14120 1804 mmcblk1 0.02 2.26 0.45 4068 812 mmcblk1 0.03 4.56 0.98 8216 1764 mmcblk1 0.09 15.84 1.41 28520 2536 mmcblk1 0.69 23.72 20.68 42696 37220 mmcblk1 0.26 6.97 22.35 12544 40232 zram lz4 4 streams: real 127m46.928s user 402m52.389s sys 60m1.737s avg-cpu: %user %nice %system %iowait %steal %idle 84.16 0.00 15.81 0.00 0.00 0.02 81.10 0.00 18.89 0.00 0.00 0.01 76.31 0.00 23.68 0.00 0.00 0.01 79.77 0.00 20.22 0.00 0.00 0.01 16.56 0.00 8.59 0.01 0.00 74.85 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn zram1 1203.30 1641.51 3171.71 2954732 5709104 zram2 1202.68 1638.97 3171.76 2950160 5709196 zram3 1203.74 1643.14 3171.81 2957672 5709288 zram4 1202.88 1639.80 3171.70 2951664 5709096 zram1 1634.75 2491.59 4047.41 4485068 7285668 zram2 1632.13 2481.02 4047.48 4466040 7285792 zram3 1632.28 2481.82 4047.32 4467468 7285496 zram4 1633.93 2488.36 4047.37 4479248 7285592 zram1 2142.44 3778.25 4791.51 6800844 8624712 zram2 2141.56 3774.83 4791.39 6794700 8624500 zram3 2141.69 3775.36 4791.42 6795640 8624556 zram4 2142.77 3779.59 4791.50 6803260 8624692 zram1 1714.65 2936.11 3922.50 5285296 7060884 zram2 1713.89 2933.00 3922.56 5279696 7061000 zram3 1712.34 2926.74 3922.62 5268420 7061116 zram4 1714.12 2933.77 3922.69 5281088 7061232 zram1 755.08 1467.73 1552.57 2641884 2794600 zram2 756.14 1472.05 1552.53 2649652 2794528 zram3 754.55 1465.77 1552.42 2638356 2794328 zram4 755.22 1468.43 1552.46 2643152 2794400 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 16.72 1025.73 15.19 1846324 27340 mmcblk1 17.52 957.67 6.43 1723876 11572 mmcblk1 21.79 1547.45 26.22 2785408 47188 mmcblk1 18.02 970.77 7.58 1747492 13652 mmcblk1 12.51 803.49 26.94 1446264 48500 zram lzo 4 streams: real 125m26.180s user 405m39.383s sys 36m14.588s avg-cpu: %user %nice %system %iowait %steal %idle 85.31 0.00 14.63 0.00 0.00 0.05 82.56 0.00 17.44 0.00 0.00 0.00 80.95 0.00 19.05 0.00 0.00 0.00 79.52 0.00 20.47 0.00 0.00 0.01 11.89 0.00 5.46 0.00 0.00 82.65 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn zram1 1174.74 1582.76 3116.19 2848960 5609136 zram2 1174.93 1583.45 3116.27 2850208 5609284 zram3 1175.11 1584.21 3116.24 2851580 5609232 zram4 1174.92 1583.52 3116.15 2850328 5609072 zram1 1588.69 2414.99 3939.76 4346988 7091564 zram2 1589.01 2416.06 3939.99 4348900 7091976 zram3 1588.51 2414.16 3939.86 4345492 7091748 zram4 1588.29 2413.34 3939.81 4344016 7091660 zram1 1816.51 3200.85 4065.19 5761560 7317376 zram2 1815.69 3197.45 4065.31 5755436 7317592 zram3 1816.19 3199.44 4065.32 5759020 7317620 zram4 1816.44 3200.38 4065.37 5760724 7317700 zram1 1823.10 3125.61 4166.79 5626100 7500224 zram2 1821.87 3120.63 4166.85 5617132 7500332 zram3 1822.11 3121.60 4166.83 5618876 7500288 zram4 1822.79 3124.31 4166.83 5623760 7500292 zram1 517.68 987.91 1082.82 1778232 1949072 zram2 517.41 986.80 1082.82 1776248 1949084 zram3 517.20 985.93 1082.87 1774680 1949168 zram4 517.13 985.70 1082.82 1774256 1949072 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 12.29 782.37 13.75 1408268 24752 mmcblk1 10.81 635.53 6.22 1143952 11188 mmcblk1 14.39 921.31 26.93 1658368 48476 mmcblk1 14.46 857.51 7.68 1543516 13828 mmcblk1 5.61 351.26 20.07 632264 36120 zram lzo 1 stream: real 124m52.403s user 397m20.110s sys 58m55.228s avg-cpu: %user %nice %system %iowait %steal %idle 84.59 0.00 15.28 0.00 0.00 0.13 81.48 0.00 18.35 0.00 0.00 0.18 79.98 0.00 19.84 0.00 0.00 0.17 76.64 0.00 22.98 0.00 0.00 0.38 10.40 0.00 5.06 0.00 0.00 84.54 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn zram1 4558.09 6483.94 11748.41 11671812 21148436 zram1 6377.26 10079.11 15429.92 18142504 27774004 zram1 7050.71 12673.06 15529.80 22811500 27953632 zram1 7258.40 12565.52 16468.06 22617944 29642512 zram1 1644.30 3404.62 3172.57 6128356 5710652 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk1 15.91 968.35 16.16 1743132 29092 mmcblk1 15.08 852.01 5.87 1533628 10568 mmcblk1 17.93 1064.32 26.88 1915772 48376 mmcblk1 18.86 1036.18 9.54 1865128 17168 mmcblk1 8.58 494.16 22.66 889484 40780 SD card: real 1151m21.149s user 342m49.658s sys 216m25.202s avg-cpu: %user %nice %system %iowait %steal %idle 11.12 0.00 1.60 80.44 0.00 6.83 9.03 0.00 1.71 78.10 0.00 11.15 10.69 0.00 1.42 82.05 0.00 5.84 21.97 0.00 1.34 70.34 0.00 6.35 9.90 0.00 1.97 69.94 0.00 18.18 0.35 0.00 0.83 88.24 0.00 10.57 2.14 0.00 1.50 81.17 0.00 15.20 2.68 0.00 1.25 81.60 0.00 14.47 2.87 0.00 1.10 84.92 0.00 11.11 8.89 0.00 2.19 77.69 0.00 11.23 3.54 0.00 1.47 84.79 0.00 10.21 10.19 0.00 2.91 76.93 0.00 9.96 10.22 0.00 3.20 78.63 0.00 7.96 8.12 0.00 4.10 73.85 0.00 13.93 2.93 0.00 9.44 68.68 0.00 18.95 2.02 0.00 5.03 62.21 0.00 30.73 2.30 0.00 6.99 69.24 0.00 21.47 7.43 0.00 6.35 68.76 0.00 17.45 6.63 0.00 15.24 61.14 0.00 16.99 6.37 0.00 12.22 66.69 0.00 14.73 7.44 0.00 13.48 64.41 0.00 14.67 1.59 0.00 2.16 81.48 0.00 14.76 8.89 0.00 13.72 64.28 0.00 13.11 4.74 0.00 5.52 77.09 0.00 12.65 5.57 0.00 9.39 72.62 0.00 12.42 9.20 0.00 13.25 63.39 0.00 14.16 7.95 0.00 12.44 65.51 0.00 14.11 11.55 0.00 14.41 60.93 0.00 13.11 9.60 0.00 15.77 62.18 0.00 12.44 3.92 0.00 15.74 59.88 0.00 20.46 5.34 0.00 19.68 55.40 0.00 19.58 7.11 0.00 19.83 55.26 0.00 17.81 6.17 0.00 16.61 57.38 0.00 19.84 6.29 0.00 16.96 56.82 0.00 19.93 6.26 0.00 17.32 55.47 0.00 20.95 6.20 0.00 8.00 56.80 0.00 29.00 9.91 0.00 7.30 50.51 0.00 32.28 18.88 0.00 6.58 46.38 0.00 28.16 7.03 0.00 0.15 0.43 0.00 92.39 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk2 76.61 450.41 1382.78 810772 2489124 mmcblk2 118.21 657.84 1485.70 1204804 2721000 mmcblk2 71.49 515.17 1415.50 955424 2625136 mmcblk2 35.76 296.81 1296.73 568028 2481664 mmcblk2 201.44 977.12 848.80 1840180 1598524 mmcblk2 29.22 16.47 110.05 28892 193032 mmcblk2 97.93 293.55 159.87 535056 291392 mmcblk2 78.06 206.14 127.74 369048 228684 mmcblk2 65.40 167.94 148.04 324444 286004 mmcblk2 135.49 394.42 180.17 685148 312972 mmcblk2 75.55 201.50 153.93 355436 271520 mmcblk2 143.00 401.61 227.92 749180 425180 mmcblk2 156.31 396.85 262.57 713496 472064 mmcblk2 139.27 240.70 347.53 435308 628516 mmcblk2 161.35 251.15 506.99 449260 906896 mmcblk2 239.78 528.38 476.98 949888 857484 mmcblk2 172.31 352.63 400.22 642808 729560 mmcblk2 178.92 468.90 311.74 844492 561436 mmcblk2 340.91 799.06 710.93 1439004 1280280 mmcblk2 277.69 683.66 547.90 1232240 987552 mmcblk2 321.37 796.36 631.85 1443872 1145604 mmcblk2 77.21 181.19 156.36 327988 283040 mmcblk2 317.58 788.05 607.13 1407312 1084220 mmcblk2 157.16 407.68 282.06 744680 515216 mmcblk2 198.91 439.60 443.84 787068 794652 mmcblk2 337.17 818.63 667.23 1474116 1201480 mmcblk2 332.78 796.49 659.56 1431248 1185196 mmcblk2 373.29 972.52 664.27 1750564 1195704 mmcblk2 335.74 778.88 707.79 1405296 1277036 mmcblk2 326.77 801.76 669.36 1445520 1206824 mmcblk2 357.16 1028.33 668.17 1845528 1199148 mmcblk2 328.49 891.48 669.25 1604684 1204672 mmcblk2 325.89 861.09 661.31 1553152 1192808 mmcblk2 358.29 981.11 661.84 1776640 1198484 mmcblk2 420.42 1245.85 659.41 2232780 1181772 mmcblk2 470.04 1186.00 723.31 2133452 1301144 mmcblk2 518.43 1405.45 696.22 2534760 1255640 mmcblk2 477.34 1259.47 666.39 2264684 1198256 mmcblk2 12.11 69.58 49.24 125248 88636 -
13 hours ago, sakibnaz said:
is there any Open Hardware project which I can consider as base of my study. All the available SBC's are open source
These 'open source' claims are BS almost everywhere. You need to pick one of the few Open Source Hardware protagonists, for example Olimex: https://www.olimex.com/Products/SOM204/ (RK3328 in the pipeline so if you're able to wait until 2019 maybe that's something for you)
Apart from this I can not follow since RK3328, RK3329, RK3229 and RK3399 are different beasts (only two of them receiving good 'open source' support by Rockchip and RK3329 not even existing)
Also worth to mention: Assumptions (like USB3 == great performance) should be questioned/checked.
-
6 hours ago, ag123 said:
Oh, there's something we also need to take care of with upgrades: the existing 128MB swap file on SD card present in /etc/fstab:
total used free shared buff/cache available Mem: 494M 66M 269M 2.7M 158M 415M Swap: 375M 0B 375M NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 50M 11.1M 2.9M 3.3M 4 /var/log /dev/zram1 lz4 61.8M 4K 63B 4K 4 [SWAP] /dev/zram2 lz4 61.8M 4K 63B 4K 4 [SWAP] /dev/zram3 lz4 61.8M 4K 63B 4K 4 [SWAP] /dev/zram4 lz4 61.8M 4K 63B 4K 4 [SWAP]With vm.swappiness=100 now it might be possible that the system decides to start to swap to SD card even if swap priority is pretty low. @Igor what do you think? Checking size of swap file and if it's 'our' 128MB file then removing fstab entry and swap file on upgrade?
-
-
-
-
-
14 hours ago, tkaiser said:
While zram is a nice way to make more use of the physically available DRAM the whole approach still sucks since we would need to take care also about our attempts to store browser profiles and caches in RAM (uncompressed -- what a waste)
Prepared a potential method to workaround that: https://github.com/armbian/build/commit/098a391996a4cd56d6e493d94decc85a53254ff1
Needs a lot of testing of course...
-
6 minutes ago, martinayotte said:
such board like OPiOne doesn't have any power controller to really cut the power from the SoC ...
Well, with legacy kernel it works flawlessly (ARISC)
-
-
-
Sunvell H3 2GB RAM + 16GB ROM TV Box
in Beginners
Posted
Advertised as Android 7 capable so it must be running with Allwinner's 4.4 kernel which is bad news since not supporting voltage regulation any more (same with Libre Computer Tritium boards): https://github.com/Allwinner-Homlet/H3-BSP4.4-linux/issues/1 -- be prepared that maximum cpufreq is lower than any of the older H3 boards.
Device tree settings from this Allwinner BSP kernel (and most probably u-boot too) are incompatible with mainline stuff so good luck with extracting settings and transforming them into something suitable for Linux (applies also to DRAM timings). How fast is the 16 GB eMMC? Which wireless chip?
In the past with Allwinner H3 based TV boxes it was rather easy to get them supported in Armbian since it was reading out the proprietary fex stuff and then adjusting few bits. Could be done for the legacy Allwinner kernel even without having the device in front of you (see Sunvell R69) but the situation with boards based on the new BSP is entirely different.
And I don't know who is still interested in Allwinner H3 here (at least me definitely not
)