Jump to content

Search the Community

Showing results for tags 'research'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Armbian
    • Armbian project administration
  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
    • Off-topic
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • TV boxes
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Support

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Matrix


Mastodon


IRC


Website URL


XMPP/Jabber


Skype


Github


Discord


Location


Interests

  1. Hi I am just doing some tests on a rockpi4b-2gb with a marvell 9235 sata controller and 4x Integral p5 120gb ssds. Purely out of interest as was expecting the card to bottleneck, but generally thought push it to the max and see how things go. I am just running on the default Radxa Debian-stretch-4.4 using mdadm for a start. Looking for benchmark mark tips & tricks and what I should be outputting, so we can have a look for curiosity sake. Currently syncing a Raid10 rock@rockpi4:~$ cat /proc/mdstat Personalities : [raid0] [raid10] md0 : active raid10 sdd[3] sdc[2] sdb[1] sda[0] 234309632 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU] [===========>.........] resync = 55.4% (129931520/234309632) finish=8.5min speed=202624K/sec bitmap: 2/2 pages [8KB], 65536KB chunk Jul 4 13:46:45 rockpi4 kernel: [ 75.172062] md0: detected capacity change from 479866126336 to 0 Jul 4 13:46:45 rockpi4 kernel: [ 75.172628] md: md0 stopped. Jul 4 13:46:45 rockpi4 kernel: [ 75.173397] md: unbind<sda> Jul 4 13:46:45 rockpi4 kernel: [ 75.190852] md: export_rdev(sda) Jul 4 13:46:45 rockpi4 kernel: [ 75.191282] md: unbind<sdd> Jul 4 13:46:45 rockpi4 kernel: [ 75.206849] md: export_rdev(sdd) Jul 4 13:46:45 rockpi4 kernel: [ 75.207325] md: unbind<sdb> Jul 4 13:46:45 rockpi4 udisksd[565]: Unable to resolve /sys/devices/virtual/block/md0/md/dev-sdb/block symlink Jul 4 13:46:45 rockpi4 kernel: [ 75.239056] md: export_rdev(sdb) Jul 4 13:46:45 rockpi4 kernel: [ 75.239439] md: unbind<sdc> Jul 4 13:46:45 rockpi4 kernel: [ 75.254837] md: export_rdev(sdc) Jul 4 13:47:12 rockpi4 kernel: [ 102.258308] sdc: sdc1 sdc2 Jul 4 13:47:12 rockpi4 kernel: [ 102.288150] sdc: sdc1 sdc2 Jul 4 13:48:09 rockpi4 kernel: [ 159.300017] md: bind<sda> Jul 4 13:48:09 rockpi4 kernel: [ 159.308923] md: bind<sdb> Jul 4 13:48:09 rockpi4 kernel: [ 159.319055] md: bind<sdc> Jul 4 13:48:09 rockpi4 kernel: [ 159.320188] md: bind<sdd> Jul 4 13:48:09 rockpi4 kernel: [ 159.326830] md/raid0:md0: md_size is 937238528 sectors. Jul 4 13:48:09 rockpi4 kernel: [ 159.327314] md: RAID0 configuration for md0 - 1 zone Jul 4 13:48:09 rockpi4 kernel: [ 159.327759] md: zone0=[sda/sdb/sdc/sdd] Jul 4 13:48:09 rockpi4 kernel: [ 159.328165] zone-offset= 0KB, device-offset= 0KB, size= 468619264KB Jul 4 13:48:09 rockpi4 kernel: [ 159.328937] sdc: sdc1 sdc2 Jul 4 13:48:09 rockpi4 kernel: [ 159.329369] Jul 4 13:48:09 rockpi4 kernel: [ 159.330145] md0: detected capacity change from 0 to 479866126336 Jul 4 13:48:09 rockpi4 udisksd[565]: Error creating watch for file /sys/devices/virtual/block/md0/md/sync_action: No such file or directory (g-file-error-quark, 4) Jul 4 13:48:09 rockpi4 udisksd[565]: Error creating watch for file /sys/devices/virtual/block/md0/md/degraded: No such file or directory (g-file-error-quark, 4) Jul 4 13:49:40 rockpi4 kernel: [ 250.355809] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) Jul 4 13:55:31 rockpi4 kernel: [ 601.335494] panel disable Jul 4 14:02:26 rockpi4 anacron[1047]: Anacron 2.3 started on 2019-07-04 Jul 4 14:02:26 rockpi4 anacron[1047]: Normal exit (0 jobs run) Jul 4 14:02:59 rockpi4 kernel: [ 1049.309314] md0: detected capacity change from 479866126336 to 0 Jul 4 14:02:59 rockpi4 kernel: [ 1049.309886] md: md0 stopped. Jul 4 14:02:59 rockpi4 kernel: [ 1049.310176] md: unbind<sdd> Jul 4 14:02:59 rockpi4 kernel: [ 1049.327147] md: export_rdev(sdd) Jul 4 14:02:59 rockpi4 kernel: [ 1049.327821] md: unbind<sdc> Jul 4 14:02:59 rockpi4 kernel: [ 1049.350959] md: export_rdev(sdc) Jul 4 14:02:59 rockpi4 kernel: [ 1049.351512] md: unbind<sdb> Jul 4 14:02:59 rockpi4 udisksd[565]: Unable to resolve /sys/devices/virtual/block/md0/md/dev-sdb/block symlink Jul 4 14:02:59 rockpi4 kernel: [ 1049.366971] md: export_rdev(sdb) Jul 4 14:02:59 rockpi4 kernel: [ 1049.367513] md: unbind<sda> Jul 4 14:02:59 rockpi4 kernel: [ 1049.383124] md: export_rdev(sda) Jul 4 14:03:21 rockpi4 kernel: [ 1071.066678] sdc: sdc1 sdc2 Jul 4 14:03:21 rockpi4 kernel: [ 1071.092394] sdc: sdc1 sdc2 Jul 4 14:05:23 rockpi4 kernel: [ 1193.551804] md: bind<sda> Jul 4 14:05:23 rockpi4 kernel: [ 1193.552267] sdc: sdc1 sdc2 Jul 4 14:05:23 rockpi4 kernel: [ 1193.552547] md: bind<sdb> Jul 4 14:05:23 rockpi4 kernel: [ 1193.553780] md: bind<sdc> Jul 4 14:05:23 rockpi4 kernel: [ 1193.554266] md: bind<sdd> Jul 4 14:05:23 rockpi4 kernel: [ 1193.570556] md: raid10 personality registered for level 10 Jul 4 14:05:23 rockpi4 kernel: [ 1193.573138] md/raid10:md0: not clean -- starting background reconstruction Jul 4 14:05:23 rockpi4 kernel: [ 1193.573765] md/raid10:md0: active with 4 out of 4 devices Jul 4 14:05:23 rockpi4 kernel: [ 1193.575635] created bitmap (2 pages) for device md0 Jul 4 14:05:23 rockpi4 kernel: [ 1193.578102] md0: bitmap initialized from disk: read 1 pages, set 3576 of 3576 bits Jul 4 14:05:23 rockpi4 kernel: [ 1193.581797] md0: detected capacity change from 0 to 239933063168 Jul 4 14:05:23 rockpi4 kernel: [ 1193.583297] md: md0 switched to read-write mode. Jul 4 14:05:23 rockpi4 kernel: [ 1193.588652] md: resync of RAID array md0 Jul 4 14:05:23 rockpi4 kernel: [ 1193.589019] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. Jul 4 14:05:23 rockpi4 kernel: [ 1193.589541] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync. Jul 4 14:05:23 rockpi4 kernel: [ 1193.590381] md: using 128k window, over a total of 234309632k. Jul 4 14:25:02 rockpi4 kernel: [ 2372.292473] md: md0: resync done. Jul 4 14:25:02 rockpi4 kernel: [ 2372.452970] RAID10 conf printout: Jul 4 14:25:02 rockpi4 kernel: [ 2372.452989] --- wd:4 rd:4 Jul 4 14:25:02 rockpi4 kernel: [ 2372.452998] disk 0, wo:0, o:1, dev:sda Jul 4 14:25:02 rockpi4 kernel: [ 2372.453005] disk 1, wo:0, o:1, dev:sdb Jul 4 14:25:02 rockpi4 kernel: [ 2372.453012] disk 2, wo:0, o:1, dev:sdc Jul 4 14:25:02 rockpi4 kernel: [ 2372.453019] disk 3, wo:0, o:1, dev:sdd Jul 4 14:30:45 rockpi4 kernel: [ 2715.470782] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 20355 28533 43513 44568 22556 28612 102400 16 60835 71891 111520 107540 66074 71640 102400 512 149988 129385 253123 263113 211684 131649 102400 1024 161360 164943 274007 275765 253893 165764 102400 16384 181646 182851 338294 347395 342601 176768 ************************************************************************************************* RAID5 rock@rockpi4:~$ sudo mdadm --create --verbose /dev/md0 --level=5 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd mdadm: layout defaults to left-symmetric mdadm: layout defaults to left-symmetric mdadm: chunk size defaults to 512K mdadm: /dev/sdc appears to be part of a raid array: level=raid0 devices=0 ctime=Thu Jan 1 00:00:00 1970 mdadm: partition table exists on /dev/sdc but will be lost or meaningless after creating array mdadm: size set to 117154816K mdadm: automatically enabling write-intent bitmap on large array Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. rock@rockpi4:~$ cat /proc/mdstat Personalities : [raid10] [raid6] [raid5] [raid4] md0 : active raid5 sdd[4] sdc[2] sdb[1] sda[0] 351464448 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_] [>....................] recovery = 1.6% (1898560/117154816) finish=19.2min speed=99924K/sec bitmap: 0/1 pages [0KB], 65536KB chunk Jul 4 14:49:52 rockpi4 kernel: [ 491.913061] md: bind<sda> Jul 4 14:49:52 rockpi4 kernel: [ 491.913784] md: bind<sdb> Jul 4 14:49:52 rockpi4 kernel: [ 491.914381] md: bind<sdc> Jul 4 14:49:52 rockpi4 kernel: [ 491.914971] md: bind<sdd> Jul 4 14:49:52 rockpi4 kernel: [ 491.920396] sdc: sdc1 sdc2 Jul 4 14:49:52 rockpi4 kernel: [ 491.929530] async_tx: api initialized (async) Jul 4 14:49:52 rockpi4 kernel: [ 491.952339] md: raid6 personality registered for level 6 Jul 4 14:49:52 rockpi4 kernel: [ 491.952833] md: raid5 personality registered for level 5 Jul 4 14:49:52 rockpi4 kernel: [ 491.953316] md: raid4 personality registered for level 4 Jul 4 14:49:52 rockpi4 kernel: [ 491.959926] md/raid:md0: device sdc operational as raid disk 2 Jul 4 14:49:52 rockpi4 kernel: [ 491.960484] md/raid:md0: device sdb operational as raid disk 1 Jul 4 14:49:52 rockpi4 kernel: [ 491.961025] md/raid:md0: device sda operational as raid disk 0 Jul 4 14:49:52 rockpi4 kernel: [ 491.962943] md/raid:md0: allocated 4384kB Jul 4 14:49:52 rockpi4 kernel: [ 491.964488] md/raid:md0: raid level 5 active with 3 out of 4 devices, algorithm 2 Jul 4 14:49:52 rockpi4 kernel: [ 491.965161] RAID conf printout: Jul 4 14:49:52 rockpi4 kernel: [ 491.965169] --- level:5 rd:4 wd:3 Jul 4 14:49:52 rockpi4 kernel: [ 491.965177] disk 0, o:1, dev:sda Jul 4 14:49:52 rockpi4 kernel: [ 491.965183] disk 1, o:1, dev:sdb Jul 4 14:49:52 rockpi4 kernel: [ 491.965188] disk 2, o:1, dev:sdc Jul 4 14:49:52 rockpi4 kernel: [ 491.965603] created bitmap (1 pages) for device md0 Jul 4 14:49:52 rockpi4 kernel: [ 491.966746] md0: bitmap initialized from disk: read 1 pages, set 1788 of 1788 bits Jul 4 14:49:52 rockpi4 kernel: [ 491.968765] md0: detected capacity change from 0 to 359899594752 Jul 4 14:49:52 rockpi4 kernel: [ 491.969465] md: md0 switched to read-write mode. Jul 4 14:49:52 rockpi4 kernel: [ 491.969930] RAID conf printout: Jul 4 14:49:52 rockpi4 kernel: [ 491.969951] --- level:5 rd:4 wd:3 Jul 4 14:49:52 rockpi4 kernel: [ 491.969968] disk 0, o:1, dev:sda Jul 4 14:49:52 rockpi4 kernel: [ 491.969984] disk 1, o:1, dev:sdb Jul 4 14:49:52 rockpi4 kernel: [ 491.969997] disk 2, o:1, dev:sdc Jul 4 14:49:52 rockpi4 kernel: [ 491.970009] disk 3, o:1, dev:sdd Jul 4 14:49:52 rockpi4 kernel: [ 491.980149] md: recovery of RAID array md0 Jul 4 14:49:52 rockpi4 kernel: [ 491.980523] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. Jul 4 14:49:52 rockpi4 kernel: [ 491.981044] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery. Jul 4 14:49:52 rockpi4 kernel: [ 491.981894] md: using 128k window, over a total of 117154816k. Jul 4 14:51:41 rockpi4 kernel: [ 601.050246] panel disable Jul 4 15:00:30 rockpi4 anacron[1052]: Anacron 2.3 started on 2019-07-04 Jul 4 15:00:30 rockpi4 anacron[1052]: Normal exit (0 jobs run) Jul 4 15:05:53 rockpi4 kernel: [ 1453.287257] md: md0: recovery done. Jul 4 15:05:53 rockpi4 kernel: [ 1453.567652] RAID conf printout: Jul 4 15:05:53 rockpi4 kernel: [ 1453.567661] --- level:5 rd:4 wd:4 Jul 4 15:05:53 rockpi4 kernel: [ 1453.567666] disk 0, o:1, dev:sda Jul 4 15:05:53 rockpi4 kernel: [ 1453.567670] disk 1, o:1, dev:sdb Jul 4 15:05:53 rockpi4 kernel: [ 1453.567674] disk 2, o:1, dev:sdc Jul 4 15:05:53 rockpi4 kernel: [ 1453.567677] disk 3, o:1, dev:sdd Jul 4 15:07:07 rockpi4 kernel: [ 1527.108599] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 8159 8947 43789 42643 24543 10212 102400 16 33078 40985 98244 98407 70763 41851 102400 512 52870 53418 212184 202157 203772 50657 102400 1024 66426 69555 250660 250200 249607 69539 102400 16384 108537 112300 326090 324173 320777 106363 ********************************************************************************************************************************** RAID1 rock@rockpi4:~$ sudo mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90 mdadm: size set to 117155264K mdadm: automatically enabling write-intent bitmap on large array Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. rock@rockpi4:~$ cat /proc/mdstat Personalities : [raid10] [raid6] [raid5] [raid4] [raid1] md0 : active raid1 sdb[1] sda[0] 117155264 blocks super 1.2 [2/2] [UU] [>....................] resync = 2.3% (2801408/117155264) finish=8.8min speed=215492K/sec bitmap: 1/1 pages [4KB], 65536KB chunk unused devices: <none> Jul 4 15:20:25 rockpi4 kernel: [ 2324.757953] md: bind<sda> Jul 4 15:20:25 rockpi4 kernel: [ 2324.759742] md: bind<sdb> Jul 4 15:20:25 rockpi4 kernel: [ 2324.772561] md: raid1 personality registered for level 1 Jul 4 15:20:25 rockpi4 kernel: [ 2324.783910] md/raid1:md0: not clean -- starting background reconstruction Jul 4 15:20:25 rockpi4 kernel: [ 2324.784534] md/raid1:md0: active with 2 out of 2 mirrors Jul 4 15:20:25 rockpi4 kernel: [ 2324.785261] created bitmap (1 pages) for device md0 Jul 4 15:20:25 rockpi4 kernel: [ 2324.787956] md0: bitmap initialized from disk: read 1 pages, set 1788 of 1788 bits Jul 4 15:20:25 rockpi4 kernel: [ 2324.790798] md0: detected capacity change from 0 to 119966990336 Jul 4 15:20:25 rockpi4 kernel: [ 2324.791556] md: md0 switched to read-write mode. Jul 4 15:20:25 rockpi4 kernel: [ 2324.794162] md: resync of RAID array md0 Jul 4 15:20:25 rockpi4 kernel: [ 2324.794546] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. Jul 4 15:20:25 rockpi4 kernel: [ 2324.795124] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync. Jul 4 15:20:25 rockpi4 kernel: [ 2324.795964] md: using 128k window, over a total of 117155264k. Jul 4 15:30:14 rockpi4 kernel: [ 2913.737079] md: md0: resync done. Jul 4 15:30:14 rockpi4 kernel: [ 2913.745998] RAID1 conf printout: Jul 4 15:30:14 rockpi4 kernel: [ 2913.746016] --- wd:2 rd:2 Jul 4 15:30:14 rockpi4 kernel: [ 2913.746027] disk 0, wo:0, o:1, dev:sda Jul 4 15:30:14 rockpi4 kernel: [ 2913.746035] disk 1, wo:0, o:1, dev:sdb Jul 4 15:31:19 rockpi4 kernel: [ 2978.675630] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 24759 31559 39765 41196 25476 30710 102400 16 62662 73245 124756 125744 62209 72778 102400 512 139397 160038 260433 261606 218154 147652 102400 1024 165815 155189 258119 261744 232643 164702 102400 16384 172905 186702 318211 322998 321997 170680 ******************************************************************************8 RAID0 rock@rockpi4:~$ sudo mdadm --create --verbose /dev/md0 --level=0 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd mdadm: chunk size defaults to 512K mdadm: /dev/sdc appears to be part of a raid array: level=raid0 devices=0 ctime=Thu Jan 1 00:00:00 1970 mdadm: partition table exists on /dev/sdc but will be lost or meaningless after creating array Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. rock@rockpi4:~$ cat /proc/mdstat Personalities : [raid10] [raid6] [raid5] [raid4] [raid1] [raid0] md0 : active raid0 sdd[3] sdc[2] sdb[1] sda[0] 468619264 blocks super 1.2 512k chunks unused devices: <none> Jul 4 15:38:35 rockpi4 kernel: [ 3415.084442] md: bind<sda> Jul 4 15:38:35 rockpi4 kernel: [ 3415.085523] md: bind<sdb> Jul 4 15:38:35 rockpi4 kernel: [ 3415.086511] md: bind<sdc> Jul 4 15:38:35 rockpi4 kernel: [ 3415.087930] md: bind<sdd> Jul 4 15:38:35 rockpi4 kernel: [ 3415.101830] md: raid0 personality registered for level 0 Jul 4 15:38:35 rockpi4 kernel: [ 3415.101836] sdc: sdc1 sdc2 Jul 4 15:38:35 rockpi4 kernel: [ 3415.107953] md/raid0:md0: md_size is 937238528 sectors. Jul 4 15:38:35 rockpi4 kernel: [ 3415.108427] md: RAID0 configuration for md0 - 1 zone Jul 4 15:38:35 rockpi4 kernel: [ 3415.108866] md: zone0=[sda/sdb/sdc/sdd] Jul 4 15:38:35 rockpi4 kernel: [ 3415.109261] zone-offset= 0KB, device-offset= 0KB, size= 468619264KB Jul 4 15:38:35 rockpi4 kernel: [ 3415.109973] Jul 4 15:38:35 rockpi4 kernel: [ 3415.110235] md0: detected capacity change from 0 to 479866126336 Jul 4 15:38:35 rockpi4 udisksd[572]: Error creating watch for file /sys/devices/virtual/block/md0/md/sync_action: No such file or directory (g-file-error-quark, 4) Jul 4 15:38:35 rockpi4 udisksd[572]: Error creating watch for file /sys/devices/virtual/block/md0/md/degraded: No such file or directory (g-file-error-quark, 4) Jul 4 15:41:08 rockpi4 kernel: [ 3568.278677] EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 31874 42784 44859 48796 26191 42465 102400 16 89104 112188 110570 114486 77652 111816 102400 512 248787 259180 258800 270097 227197 229707 102400 1024 309271 324243 293455 293122 268819 286143 102400 16384 373574 382208 324869 326204 326070 380622 Concurrent single disks Command line used: iozone -l 4 -u 4 -r 16k -s 512M -F /home/rock/sda/tmp1 /home/rock/sdb/tmp2 /home/rock/sdc/tmp3 /home/rock/sdd/tmp4 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. Min process = 4 Max process = 4 Throughput test with 4 processes Each process writes a 524288 kByte file in 16 kByte records Children see throughput for 4 initial writers = 468982.85 kB/sec Parent sees throughput for 4 initial writers = 391562.16 kB/sec Min throughput per process = 115979.48 kB/sec Max throughput per process = 118095.79 kB/sec Avg throughput per process = 117245.71 kB/sec Min xfer = 513488.00 kB Children see throughput for 4 rewriters = 448753.70 kB/sec Parent sees throughput for 4 rewriters = 378103.46 kB/sec Min throughput per process = 108174.91 kB/sec Max throughput per process = 119841.15 kB/sec Avg throughput per process = 112188.42 kB/sec Min xfer = 472992.00 kB Children see throughput for 4 readers = 319857.60 kB/sec Parent sees throughput for 4 readers = 319587.93 kB/sec Min throughput per process = 78386.40 kB/sec Max throughput per process = 81170.33 kB/sec Avg throughput per process = 79964.40 kB/sec Min xfer = 506336.00 kB Children see throughput for 4 re-readers = 331737.53 kB/sec Parent sees throughput for 4 re-readers = 331539.26 kB/sec Min throughput per process = 74617.11 kB/sec Max throughput per process = 90278.13 kB/sec Avg throughput per process = 82934.38 kB/sec Min xfer = 433360.00 kB Children see throughput for 4 reverse readers = 769042.86 kB/sec Parent sees throughput for 4 reverse readers = 768023.53 kB/sec Min throughput per process = 43320.77 kB/sec Max throughput per process = 262961.66 kB/sec Avg throughput per process = 192260.72 kB/sec Min xfer = 86384.00 kB Children see throughput for 4 stride readers = 1795856.09 kB/sec Parent sees throughput for 4 stride readers = 1781767.61 kB/sec Min throughput per process = 65569.88 kB/sec Max throughput per process = 920383.50 kB/sec Avg throughput per process = 448964.02 kB/sec Min xfer = 37360.00 kB Children see throughput for 4 random readers = 1971409.70 kB/sec Parent sees throughput for 4 random readers = 1958188.18 kB/sec Min throughput per process = 69869.92 kB/sec Max throughput per process = 861175.75 kB/sec Avg throughput per process = 492852.43 kB/sec Min xfer = 41904.00 kB Children see throughput for 4 mixed workload = 1176863.17 kB/sec Parent sees throughput for 4 mixed workload = 275991.88 kB/sec Min throughput per process = 98414.23 kB/sec Max throughput per process = 606498.81 kB/sec Avg throughput per process = 294215.79 kB/sec Min xfer = 84304.00 kB Children see throughput for 4 random writers = 428459.84 kB/sec Parent sees throughput for 4 random writers = 318774.34 kB/sec Min throughput per process = 96696.56 kB/sec Max throughput per process = 118440.29 kB/sec Avg throughput per process = 107114.96 kB/sec Min xfer = 428352.00 kB Children see throughput for 4 pwrite writers = 467800.79 kB/sec Parent sees throughput for 4 pwrite writers = 381736.33 kB/sec Min throughput per process = 111798.68 kB/sec Max throughput per process = 120814.23 kB/sec Avg throughput per process = 116950.20 kB/sec Min xfer = 485168.00 kB Children see throughput for 4 pread readers = 309714.87 kB/sec Parent sees throughput for 4 pread readers = 309501.91 kB/sec Min throughput per process = 76447.56 kB/sec Max throughput per process = 79120.13 kB/sec Avg throughput per process = 77428.72 kB/sec Min xfer = 506592.00 kB Children see throughput for 4 fwriters = 442763.85 kB/sec Parent sees throughput for 4 fwriters = 373418.60 kB/sec Min throughput per process = 107828.45 kB/sec Max throughput per process = 114495.70 kB/sec Avg throughput per process = 110690.96 kB/sec Min xfer = 524288.00 kB Children see throughput for 4 freaders = 331765.48 kB/sec Parent sees throughput for 4 freaders = 325459.39 kB/sec Min throughput per process = 81387.83 kB/sec Max throughput per process = 86099.32 kB/sec Avg throughput per process = 82941.37 kB/sec Min xfer = 524288.00 kB single disk sda Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 36038 45031 52457 52672 27342 44553 102400 16 93224 115531 124822 114115 79868 115219 102400 512 249415 223799 267595 273488 227651 258480 102400 1024 259449 236700 268852 273148 242803 266988 102400 16384 313281 317096 324922 325600 319687 267843 single disk sdb Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 33918 45021 52628 52655 27404 44621 102400 16 100152 106531 127148 115452 76579 113503 102400 512 251035 259812 272338 273634 227332 225607 102400 1024 260791 268019 273578 276074 241042 268323 102400 16384 267448 316877 323467 324679 319983 316710 single disk sdc Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 36074 44819 52358 52592 23334 44073 102400 16 92510 114568 127346 126830 72293 112819 102400 512 220032 260191 271136 274745 225818 258574 102400 1024 258895 228236 270047 271946 239184 267370 102400 16384 312151 316425 318919 323689 317570 268308 single disk sdd Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 36100 44939 52756 52768 27569 42697 102400 16 100207 111073 127120 118992 76555 105342 102400 512 248869 259052 271718 272745 227450 258252 102400 1024 226653 266979 262772 265104 236617 266018 102400 16384 314211 269062 322937 325634 320150 315470
  2. Hardware: 1 - NEO-8M GPS Satellite Positioning Module for Arduino STM32 C51 $7.49 USD on Ebay. NOTE it is using TTL output. Validated USB GPS connection to work fine. 2 - Uxcell a14041500ux1216 MAX232CSE Transfer Chip RS232 to TTL Converter Module COM Serial Board for $7.37 USD (Amazon) I connected PPS pin to Pin #1 on RS-232 interface. Using Linux connected USB port and RS-232 port to laptop. I see GPS chit chat fine on two serial intefaces. Using this for a new PFSense box QOTOM Mini PC. Transport ==> USB power coming from QOTOM Mini PC and RS-232 coming from GPS/TTL converter. NOTE: PFSense is BSD. I see only one serial interface using command line /dev: cat cuaU0 $GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E $GNTXT,01,01,02,HW UBX-M8030 00080000*60 $GNTXT,01,01,02,ROM CORE 3.01 (107888)*2B $GNTXT,01,01,02,FWVER=SPG 3.01*46 $GNTXT,01,01,02,PROTVER=18.00*11 $GNTXT,01,01,02,GPS;GLO;GAL;BDS*77 $GNTXT,01,01,02,SBAS;IMES;QZSS*49 $GNTXT,01,01,02,GNSS OTP=GPS;GLO*37 $GNTXT,01,01,02,LLC=FFFFFFFF-FFFFFFFD-FFFFFFFF-FFFFFFFF-FFFFFFF9*50 $GNTXT,01,01,02,ANTSUPERV=AC SD PDoS SR*3E $GNTXT,01,01,02,ANTSTATUS=OK*25 $GNTXT,01,01,02,PF=3FF*4B This is coming from the USB serial connection (and power). I have the RS-232 9 Pin (from TTL to RS-232) plugged in to Quotom serial com port #1. I do not see this port using command line where as I saw this in Linux. If I power the GPS externally I see chatter from the RS-232 connection fine with Linux but not in BSD. Any suggestions? I am currently using a Sure GPS with a PPS modification on another PFSense box and it is working fine.
  3. I have a local OpenVPN server on Banan Pi M1, with latest armbian. I tried to replace with OrangePi3 but current results is disappointing iperf3 results on Banana Pi M1 OpenVPN server Connecting to host bouygues.iperf.fr, port 5201 [ 4] local 10.8.0.4 port 46250 connected to 89.84.1.222 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 1.69 MBytes 14.1 Mbits/sec [ 4] 1.00-2.00 sec 1.81 MBytes 15.1 Mbits/sec [ 4] 2.00-3.00 sec 2.43 MBytes 20.4 Mbits/sec [ 4] 3.00-4.00 sec 681 KBytes 5.58 Mbits/sec [ 4] 4.00-5.00 sec 1.99 MBytes 16.7 Mbits/sec [ 4] 5.00-6.00 sec 1.33 MBytes 11.2 Mbits/sec [ 4] 6.00-7.00 sec 1.55 MBytes 13.0 Mbits/sec [ 4] 7.00-8.00 sec 1.62 MBytes 13.6 Mbits/sec [ 4] 8.00-9.00 sec 1.33 MBytes 11.2 Mbits/sec [ 4] 9.00-10.00 sec 1.76 MBytes 14.8 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 16.2 MBytes 13.6 Mbits/sec sender [ 4] 0.00-10.00 sec 15.7 MBytes 13.2 Mbits/sec receiver iperf3 results on Orange Pi 3 OpenVPN server Connecting to host bouygues.iperf.fr, port 5201 [ 4] local 10.8.1.4 port 41583 connected to 89.84.1.222 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 621 KBytes 5.09 Mbits/sec [ 4] 1.00-2.00 sec 868 KBytes 7.11 Mbits/sec [ 4] 2.00-3.00 sec 1.18 MBytes 9.89 Mbits/sec [ 4] 3.00-4.00 sec 1.16 MBytes 9.75 Mbits/sec [ 4] 4.00-5.00 sec 1.02 MBytes 8.53 Mbits/sec [ 4] 5.00-6.00 sec 966 KBytes 7.92 Mbits/sec [ 4] 6.00-7.00 sec 726 KBytes 5.95 Mbits/sec [ 4] 7.00-8.00 sec 676 KBytes 5.54 Mbits/sec [ 4] 8.00-9.00 sec 2.58 MBytes 21.7 Mbits/sec [ 4] 9.00-10.00 sec 4.78 MBytes 40.1 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 14.5 MBytes 12.2 Mbits/sec sender [ 4] 0.00-10.00 sec 14.0 MBytes 11.7 Mbits/sec receiver As you can see, connection via OPi3 is slower, but more than that, it is unstabe and fluctuating from 5-8 MBit/s to 40 MBit/s What can I tune to improve openvpn connectivity?
  4. Looking to purchase a tablet with Android to run Armbian Desktop on. Any suggestions? Looking at the FreakTab forum and see a bunch of tablets listed but no subtopics of removal of Android. Here I was able to install Ubuntu just fine on my Intel based Pipo X7.
  5. with the armiban-build-system I did build some dev-images. Sometimes I see in other threads, that later build images have newer kernel or package versions. While trying apt update && apt upgrade I didnt get these newer packages So my first try was to use the armbian-build-system and do use the function for creating u-boot and kernel that will give me some .debs in ./build/output/debs/ like this: linux-u-boot-dev-nanopineo2_5.82_arm64.deb linux-dtb-dev-sunxi64_5.82_arm64.deb linux-image-dev-sunxi64_5.82_arm64.deb linux-headers-dev-sunxi64_5.82_arm64.deb linux-source-dev-sunxi64_5.82_all.deb install these (mostly I didnt do that for the headers and source) with dpkg -i will result in higher package numbers, but not for the armbian / bsp-kernel version for getting here the right version I have to compile (again) - now - the a whole OS-image to get linux-stretch-root-dev-nanopineo2_5.82_arm64.deb in ./build/output/debs/stretch If you did install also this .deb with dpkg -i I do get the right/higer armbian/bsp-kernel-version: Welcome to ARMBIAN 5.82 user-built Debian GNU/Linux 9 (stretch) 5.0.7-sunxi64 package bsp-kernel[5.82] u-boot[5.82] dtb[5.82] firmware[5.79] config[5.81] armbian-config does update via apt update && apt upgrade I try to update this way because I didnt want to use a whole new OS-image and reconfigure it. But I think it isnt the right way to update, when I have to compile 2 times on to get the root-deb Is there another way to generate this file? And is there a way to not generate the headers and source .debs? The source .deb take a while because it is getting as big as 370MB Is there a better way or does nobody other like me update this way?
  6. I'm only just getting started with this project. So far I have gotten a lot of help from some great people and looking to get further along with this project as time goes on. My main goal is to turn the tinkerboard into a linuxcnc control system with a drop in SDcard/EMMC image(s). The images will be preloaded with everything needed to setup a cnc machine for different control systems such as GPIO, ETHERNET, SPI depending on one's choice or needs for control. The gpio will provide direct step/dir, end stops, router power control signals, etc.... the normal cnc machine control logic one would expect when using a parallel port. Ethernet and SPI will be options for anyone using drivers like the MESA controllers for example. At this point I have the working and current FULL preempt RT images and kernel DEB packages for any one looking to build or install. I have posted the files HERE. I have a working image setup with linuxcnc already compiled, and 3d/opengl video drivers fully working. If anyone is interested or willing to host the multi gig file let me know. CURRENTLY HAL for SPI, GPIO and ETHERNET are not built. These are areas I'm looking for help. Also at this point I could really use a hand with TUNING the build or tuning options for compiling the kernel if any. I'm weak in regards to software, strong in the hardware as well the electronics side. The last few issues I'm having are with the driver support for my LCD. it is not currently working at all. I have a raspberry pi 7" LCD with a native res. of 1024x600. I have to run it at 1024x768 which stretches the image a bit as well makes smaller print harder to read. The other issue though more of a personal one, I have an I2C RTC setup but i2c is not fetching the TIME/DATE but rather seeking network time. I do not know how to fix this and the few febal attempts I've made, I discovered that armbian has been rather locked down to use network time rather then seek multi sources for current time. I'm currently on the kernel 4.19 full preempt RT kernel. If anyone is interested in seeing photos of the project and the VERY custom mold and shell I built for this project check this LINK I've gotten a lot of positive feed back on it so far.
  7. Some SBCs, such as PIneA64, provide a built-in RTC on-board while others do not. For those boards that do have a built-in RTC, it appears the kernel driver is configured as a builtin rather than as a module at least in some cases (I only checked a few). This in turn brings up a question: For boards that include a built-in RTC and also have the respective kernel driver configured as a built-in, should the kernel configuration to also set the system clock from that RTC (RTC_HCTOSYS) be enabled by default? There is a dependency that the RTC be built-in as the kernel will try to read from the RTC rather early, before any loadable modules would have been loaded. That would potentially preclude this from being a common default, but doesn't necessarily need to. For cases where this can be done, this has the advantage of not requiring separate user-space accommodations. For distributions based on systemd there are sadly a very large number of discussions and proposals on how to set the system time from RTC at boot time but also sadly there is no standard nor common solution. /lib/udev/hwclock-set explicitly exits without setting the system clock if systemd is found, and systemd will not read the RTC itself expecting to use a network time source (NTP) instead. Having the kernel set system time from RTC would happen a bit earlier than any user-land option which would result in consistent and correct timestamps on files created/modified during startup as well as in various logs. It may not be a perfect nor complete solution, but where possible does this seem like something that could/should be done?
  8. Hi all. Since I wanted a 3D intro for my Youtube Channel I started working with Blender again. Now the intro is finished I've got time to try to make a 3D Armbian Logo. I'll show some of the progress here for those who are interested. And if anybody else wants to do the same, go ahead. We can then compare the results. I've only just begun. But I needed a break so I started writing this. Here's how it begins... create a side view ...  Then put those pictures in Blender, add a cube, position it right on both pictures, and start modeling.... All done with the NanoPi M4 on Armbian Bionic. I'll slowly keep working on it. I can't promise it will look great, but nothing is lost if it doesn't... Someone once asked me to do this, I can't remember who it was. I think Chwe or jmcc or tido. Could also have been a ghost in my sleep. Cheers, NicoD ps: @Igor It would be nice if we could easily resize images in our posts. Maybe with a dropdown box and % would be easiest to do. I know this isn't a priority, just a suggestion.
  9. Hi Everyone. I'm having trouble updating to TLS 1.2 on my pcDuino 3 and cannot connect to any website other than Google.com or pinging 8.8.8.8 See attached return from my terminal when attempting to run "sudo apt-get update && sudo apt-get install --only-upgrade openssl" Seems http://www.wiimu.com from what I can tell is a server from a company called LinkSprite. I think the company has disbanded and no longer offers any services… Also seems LinkSprite was lead/CEO by a guy named Jingfeng Liu who is the creator of pcDuino. Also Link Sprite does not monitor their forums nor respond to queries of any sort. There’s got to be an alternative to updating the SSL certs… Has anyone updated their TLS lately? Updating SSL_pcDuino
  10. Release WIP and CSC images from their own page with very specific limitations, including, but not limited to: no kernel or u-boot updates, ideally with the kernel and u-boot package names modified with -unsupported- Explain these are demo snapshot images, potentially even package a different wallpaper that has -unofficial- or something similar watermarked across it. Maybe even use the default WM theme.
  11. Is everybody being hit with custom & handling charges via royal mail? Added a total of £11.72 to my OrangePi H3 plus2 £3.72 customs and £8.00 handling charge. Its no bother as just curiosity with Smaller format boards but just wondering is this a Brexit shape of things to come?
  12. Just wanted to announce that Armbian-NG (https://github.com/AndrewBCN/Armbian-NG/) has been chosen as the OS to power the new CNX Election Meddling System (https://www.cnx-software.com/2019/04/01/introducing-cnx-election-meddling-system/). Why? Because Python. Have a nice day and don't forget to vote!
  13. Hi, I am looking for a device, which has the following hardware: - 2x wifi adapter - 2x ethernet adapter - CSI connector for camera - 2x USB port or 1x USB and 1x USB-C port I know it would be very hard to find such a device, but an option would be to use one USB port and WiFi dongle instead second build-in WiFi and another USB to connect ethernet dogle into it. And for USB-C I can use use an USB-C-to-USB adapter... So at least I would like to find a device with: - 1x wifi adapter - 1x ethernet adapter - CSI connector for camera - 2x or 3x USB port Any ideas?
  14. Hi, I bought the edimax EW-7822ULC usb wifi device (based on rtl8822). I was able to build the driver, install it, and test it (works!). Edimax provides the sources on their site. Is anyone working on incorporating this into Armbian? Steve
  15. In the following window the cursor keys (arrow up, down, left, right) aren't working: the raw terminal control chars appear instead. And the window is kind of "distorted" (for example the G char of General setup appears at the right side of the window, same with the following lines): Tried in a X console as well on tty8, same behavior. One can press only CTRL-C to get out of this window, this of course also aborts the build: How to fix this? My system: x86_64 Debian 8 (jessie) with LXDE desktop, using a Debian 8 in a LXC container for building Armbian for an A20 device. .config - Linux/arm 4.19.25 Kernel Configuration ────────────────────────────────────────────────────────────────────────────── ┌──────────────── Linux/arm 4.19.25 Kernel Configuration ─────────────────┐ │ Arrow keys navigate the menu. <Enter> selects submenus ---> (or empty │ │ submenus ----). Highlighted letters are hotkeys. Pressing <Y> │ │ includes, <N> excludes, <M> modularizes features. Press <Esc><Esc> to │ │ exit, <?> for Help, </> for Search. Legend: [*] built-in [ ] │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ │ │ │ │neral setup ---> │ │ │ │aximum PAGE_SIZE order of alignment for DMA IOMMU buffers │ │ Sy │ │Type ---> │ │ B │ │pport ---> │ │ K │ │ Features ---> │ │ B │ │ptions ---> │ │ C │ │wer Management ---> │ │ F │ │ng point emulation ---> │ │ P │ │management options ---> │ │ │ └────┴(+)─────────────────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────────────────────┤ │ <Select> < Exit > < Help > < Save > < Load > │ └─────────────────────────────────────────────────────────────────────────┘
  16. I'm a newbie to Armbian, just a hobby user, no company behind me. While building Armbian for my Banana Pi R1 (aka Lamobo R1) [Allwinner A20, sunxi] the build system gave the following warnings originating from the U-Boot project. I think some maintainers and/or experienced users should take a look at the following. ===================== WARNING ====================== This board does not use CONFIG_DM_MMC. Please update the board to use CONFIG_DM_MMC before the v2019.04 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_SCSI. Please update the storage controller to use CONFIG_DM_SCSI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_VIDEO Please update the board to use CONFIG_DM_VIDEO before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. ==================================================== Here's also the full content of the file ./cache/sources/u-boot/v2019.01/doc/driver-model/MIGRATION.txt :
  17. https://github.com/StuartIanNaylor/log2ram/tree/log2zram git clone --single-branch --branch log2zram https://github.com/StuartIanNaylor/log2ram /etc/log2ram.conf says it all. # Configuration file for Log2Ram (https://github.com/azlux/log2ram) under MIT license. This configuration file is read # by the log2ram service Size for the ram folder, it defines the size the log folder will reserve into the RAM. If it's # not enough, log2ram will not be able to use ram. Check you /var/log size folder. The default is 40M and is basically # enough for a lot of applications. You will need to increase it if you have a server and a lot of log for example. # Above is log2ram original size increased to 80M zram. Assuming 3:1 LZO compression ram usage should be reduced to # 26.66M. Size is in MB SIZE=80 # This variable can be set to true if you prefer "rsync" rather than "cp". I use the command cp -u and rsync -X, so I # don't copy the all folder every time for optimization. You can choose which one you want. Be sure rsync is installed # if you use it. USE_RSYNC=false # If there are some errors with available RAM space, a system mail will be send Change it to false and you will have # only a log if there is no place on RAM anymore. MAIL=true # Big cores should only be counted really but this is where you can dictate zram stream count Default is 1 and settings # can be edited to personal taste. # BIG_CORES=0 Disables zram BIG_CORES=1 # Free mem factor deb is 505 I concur that 75 is better but its open. Free mem factor is just the fraction of # free mem used for swap drive total Drive size = Free_Mem * mem_factor / 100 / Big_Cores # So if you want .75 of total mem make mem_factor 75 as divided by 100 to avoid float usage MEM_FACTOR=75 # Compression algorythm either LZ0 or LZ$ COMP_ALG=lzo # ZLTG flag means use ZRAM ramdisk for log2ram true=enable / false=disable ZLTG=true # SWAP_PRI sets swap_priority of zram streams set by big_cores default=75 SWAP_PRI=75 Just gives you a bit more control than zram-config_0.5_all.deb but basically is just that and log2ram in a single package. Any issues tips or ideas give us a shout here or github
  18. Hi everyone, I'm building a micro server based on orange pi prime and armbian, after reading a lot about sd card wear out, I started thinking how could I improve that in my project. For my project it is ok, if data would be physically written to card, every 1 minute instead of on every commit. Now, what I can't find: is there a way to generally configure such memory buffering for a filesystem, so that I don't have to configure this for a database engine?
  19. Hi, while toying around build system for Odroid C1 I saw that toolchains for arm-linux-gnueabihf where "old" as we are at "gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf" since the 7.3.1 looks like it is not available for this platform. So I did some changes in lib/general.sh and added the following as a fast hack: "https://releases.linaro.org/components/toolchain/binaries/7.4-2019.02/arm-linux-gnueabihf/gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf.tar.xz" "https://developer.arm.com/-/media/Files/downloads/gnu-a/8.2-2019.01/gcc-arm-8.2-2019.01-x86_64-arm-linux-gnueabihf.tar.xz" Then I modified the configuration files for odroidc1 to test both toolchains (namely config/sources/odroidc1.conf) and I produced working images with both toolchains. Personally (but without any scientific approach) I saw: 7.4.1 it looked like very slow to compile... maybe my system was busy doing other things maybe not 8.2 produced a smaller kernel (with same .config) and its speed was acceptable Is there a reason that arm-linux-gnueabihf is stil at 7.2.1 (2017.11)? Thanks in advance *Bye Piero
  20. Hi there, I was playing around with the new sun6i-csi driver and was able to capture up to 800x600, but if I try to capture with a higher resolution it will always fail: fswebcam -S 5 -d /dev/video0 -r 1600x1200 -p YUV420P test.jpg --- Opening /dev/video0... Trying source module v4l2... /dev/video0 opened. No input was specified, using the first. [ 2313.151304] sun6i-csi 1cb4000.csi: Wrong width or height 1600x1200 (800x600 expected) Error starting stream. VIDIOC_STREAMON: Broken pipe Unable to use mmap. Using read instead. Unable to use read. I have also tried to set a higher resolution with v4l2-ctl beforehand. It doesn't make an difference. v4l2-ctl --set-fmt-video=width=1600,height=1200,pixelformat=YUV420P I'm using a OV2640 with a maximal resolution of 1600x1200. This piece of code throws out the error message (from sun6i_video.c): if (source_fmt.format.width != video->fmt.fmt.pix.width || source_fmt.format.height != video->fmt.fmt.pix.height) { dev_err(video->csi->dev, "Wrong width or height %ux%u (%ux%u expected)\n", video->fmt.fmt.pix.width, video->fmt.fmt.pix.height, source_fmt.format.width, source_fmt.format.height); return -EPIPE; } video->mbus_code = source_fmt.format.code; return 0; } Maybe someone can help me with that. thanks
  21. Hello, I have had a look to the new Development Image (Armbian_5.76.190228_Tinkerboard_Debian_stretch_dev_5.0.0-rc8_desktop.7z) My SixFfab Hat which was working like a charm on 4.19-20 kernel. Any changes to add supoort for this Hardware again? Do you need any additional information? Many Thanks Roman
  22. Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations. Edit: See an early 2017 update at the end of the thread regarding new SD specs also covering random IO performance. Edit 2: Some thoughts/observations on lifespan/reliability of SBC storage: http://tech.scargill.net/a-question-of-lifespan/ (see also/especially the comments there) Edit 3: CNX Software picked up recent performance reports (eg. by Andreas Spiess) and other important issues around SD cards: http://www.cnx-software.com/2017/06/13/micro-sd-cards-for-development-boards-classes-tools-benchmarks-reliability-and-tips-tricks/ Edit 4: See an early 2018 update testing real world A1 performance class products at the end of the thread. Edit 5: See here and there for some rather boring but very important information about Armbian's tries to prevent SD cards wearing out too fast. Preparations: I tested 8 different SD/TF cards under identical conditions. I created an Armbian 5.07 image to be used on Banana Pi (A20 SoC with 4.4.6 kernel, ext4 rootfs (Armbian defaults == no journal), 960MHz scaling_max_cpufreq, scaling_governor == performance. All test runs were done using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and monitored using 'sudo iostat 5' for anomalies (none detected). Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot). Sequential speeds: Random I/O: The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run) Sequential speed mostly irrelevant / random I/O differs and matters a lot! The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s). Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot. All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes. Detailed results (summary table also available as .ods, .xlsx or .txt): Samsung Pro 64GB (brand new) http://sprunge.us/DEYd Samsung EVO+ 64GB (brand new) http://sprunge.us/NLQd Samsung EVO+ 32GB (brand new) http://sprunge.us/heGL Samsung EVO 64GB (already used some time) http://sprunge.us/DUOS SanDisk Extreme Pro 8GB (already used some time) http://sprunge.us/ZPFZ SanDisk 'Class 10' 8GB (already used some time) http://sprunge.us/OHjT Intenso 'Class 10' 16GB (already used some time) http://sprunge.us/LUMZ Intenso 'Class 4' 4GB (already used some time) http://sprunge.us/GbAY Some updates from Igor (still showing superiour EVO results but the clear winner is ODROID's eMMC module with SD card adapter): Transcend Premium 300x 16GB (almost new) http://sprunge.us/UcSD Sandisk Extreme Pro 8Gb (almost new) http://sprunge.us/aDJJ Hardkernel eMMC 8G via SD reader (brand new) http://sprunge.us/SHXF Sandisk Ultra 8Gb (old and very used) http://sprunge.us/OWZf Sandisk 8GB (almost new) http://sprunge.us/iViT Sandisk 8G (new) http://sprunge.us/XHjj Transcend 8Gb (used) http://sprunge.us/NTRT Samsung EVO 32Gb (brand new) http://sprunge.us/bTQh Further readings: http://www.bunniestudios.com/blog/?page_id=1022 http://thewirecutter.com/reviews/best-microsd-card/ http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card http://www.bradfordembedded.com/2014/05/flashbenching/ Conclusions: If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders) When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card) No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size) Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface) One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes. It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card
  23. As already done with other topics this will be the start of a new thread collecting more information over time. Since we had a lot of annoying discussions recently regarding Wi-Fi on Orange Pi Zero and in general I thought let's give it a try a few days ago. I did some preparations in the meantime (monitoring 24/7 Wi-Fi throughput in 2.4 GHz band for example) and then started to test in a not too crowded environment here. As a start some quick Wi-Fi tests with a random 'quality' USB Wi-Fi dongle and 3 different Wi-Fi chipsets that can be found an a few boards Armbian supports: RTL8192CU (used on a lot of cheap USB dongles and even on Lamobo R1) Ampak AP6212 (based on Broadcom's BCM43438 module also used on RPi 3 and Zero W, nearly all Wi-Fi equipped NanoPi and Banana Pi) RealTek RTL8723BS (used on Pine64+ and on CHIP for example) RealTek 8189FTV (used on the more recent Wi-Fi equipped Orange Pi) The usual Wi-Fi performance 'benchmark' results available here and there most of the time ignore a lot of important bits, eg. Environment (Wi-Fi means shared media so in crowded areas with a lot of other Wi-Fis around you fight for free slots on the media, even USB3 peripherals or microwave ovens happily interfere with your Wi-Fi performance) Environment (yeah, again: This time aerial/antenna used, position of antenna in relation to AP, distance, free sight or not, walls/stuff that filter or reflect signals) Settings (Wi-Fi powermanagement enabled or not? Which cpufreq governor used? Performance results can vary based on at which clockspeed CPU cores run) So for the test I chose to let all boards run with performance governor and Wi-Fi powermanagement disabled. All are equipped with the same el cheapo Xunlong aerial (sent with all Orange Pi that are Wi-Fi capable). Position of antenna is always the same, distance from AP (Fritzbox 7390) to board approx 50 cm, AP in cabinet (20mm MDF). Almost same environmental conditions (due to some testing delays I could not guarantee that Wi-Fi channel utilization was always the same but since I let a constant iperf3 monitoring run for the last couple of days I chose time slots where maximum throughput seemed to be possible). Also no Ethernet connected (since it's easy to f*ck up performance tests in this scenario when wired and wireless interfaces of both device and router/AP are somehow all connected since some kernels then send packets over the wrong interface) and Wi-Fi connection established the usual way (nmtui --> 'Activate connection' --> done) with /etc/network/interfaces being empty (to let network-manager control all devices for smooth networking). Now the results: NanoPi Air with el cheapo Xunlong aerial, AP6212 module, Kernel 3.4.113, no BT configured: 39 Mbits/sec and 188 retransmits on average. Full log: http://sprunge.us/aPXb Pine64+ with same el cheapo Xunlong aerial, RTL8723BS module, Kernel 3.10.104, no BT configured: 39 Mbits/sec and 58 retransmits on average. Full log: http://sprunge.us/EffO Orange Pi Lite, RTL8189FTV module, Kernel 3.4.113: 41.5 Mbits/sec and 50 retransmits on average. Full log: http://sprunge.us/dWJV ODROID-C2 with TP-Link TL-WN823N dongle, RTL8192CU module, kernel 3.14.79: 77 Mbits/sec and 73 retransmits on average. Full log: http://sprunge.us/Njhi How to interpret the results? The test setup is stupid for any real world consideration (if distance between device and AP is just 50 cm then use a cable instead! ) But this set of tests was about identifying the maximum you can get under perfect or at least pretty good conditions (no interference, rather good signal/noise ratio and so on) All 3 onboard Wi-Fi chips perform identical. This is due to single antenna 2.4 GHz Wi-Fi: 65Mbps bit rate resulting in ~40 Mbit/sec TCP/IP throughput with ideal/good/identical environmental conditions The only reason the TP-Link Wi-Fi dongle could outperform the onboard Wi-Fi chips is called MIMO. This is available with 802.11n and makes use of more than one antenna (2 in this dongle's case). Now we're talking about 130 Mbps bit rate resulting in almost 80 Mbit/sec TCP/IP throughput Next steps: Let's have a look how worse environmental conditions affect performance. This means increasing distance between AP and device, put a few walls in between, use a more crappy antenna. To save some time I will continue the testing solely with the TP-Link Wi-Fi dongle (connected to the ODROID but here the board doesn't matter at all, it's just about the driver variant/version used) and Orange Pi Lite since this is the cheapest 'general purpose Wi-Fi' enabled board Armbian supports and the same chip is also used on OPi PC Plus and OPi Plus 2E (which are both also priced very competitively for their feature set). But I will add also results from Raspberry Zero W if this board ever arrives (if not I'll take RPi 3 instead, both use same BCM43438 chip that is also contained in Ampak's AP6212 which is the solution present on most Wi-Fi enabled Armbian boards)
  24. 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 216m25 You 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:
  25. With this commit I added 7-zip benchmark reporting to Armbian now. Will be available after next updates and with next batch of new images. Why not recommending to just do an 'apt install p7zip ; 7zr b'? Since 'fire and forget' benchmarking is always BS. You need some monitoring in parallel to know whether your system was really idle and at which clockspeeds the CPU cores were operating (throttling occuring or not?). Most recent 7-zip contains an own routine to 'pre-heat' the system prior to starting the benchmark (to let cpufreq scaling switch from low clockspeeds to highest ones and e.g. on Intel systems let the system enter TurboBoost modes). This 7-zip code runs single threaded so based on the kernel's scheduler sometimes ending up on the 'wrong' CPU core (e.g. a little core on big.LITTLE SoCs) On a NanoPC T4 with conservative settings (limiting big CPU cores to 1.8 GHz and little cores to 1.4 GHz) this looks like this: root@nanopct4:/home/tk# armbianmonitor -z Preparing benchmark. Be patient please... 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,6 CPUs LE) LE CPU Freq: 1413 1414 1414 1411 1413 1414 1414 1414 1415 RAM size: 3878 MB, # CPU hardware threads: 6 RAM usage: 1323 MB, # Benchmark threads: 6 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 3642 363 976 3543 | 98020 543 1540 8359 23: 3691 365 1030 3761 | 95217 541 1522 8239 24: 3606 354 1094 3878 | 92662 535 1520 8133 25: 4597 451 1164 5249 | 89079 529 1498 7928 ---------------------------------- | ------------------------------ Avr: 383 1066 4108 | 537 1520 8165 Tot: 460 1293 6136 Monitoring output recorded while running the benchmark: Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 10:16:19: 1800/1416MHz 0.12 12% 1% 7% 2% 1% 0% 44.4°C 0/5 10:16:25: 408/ 600MHz 0.11 0% 0% 0% 0% 0% 0% 43.9°C 0/5 10:16:30: 600/1416MHz 0.10 1% 0% 0% 0% 0% 0% 45.0°C 0/5 10:16:35: 1800/1416MHz 0.17 40% 0% 39% 0% 0% 0% 49.4°C 0/5 10:16:40: 1800/1416MHz 0.32 77% 0% 77% 0% 0% 0% 55.0°C 0/5 10:16:45: 1800/1416MHz 0.94 73% 0% 72% 0% 0% 0% 51.1°C 0/5 10:16:50: 1800/1416MHz 0.94 65% 0% 65% 0% 0% 0% 53.3°C 0/5 10:16:55: 1800/1416MHz 1.19 68% 0% 67% 0% 0% 0% 56.1°C 0/5 10:17:00: 1800/1416MHz 1.49 79% 1% 78% 0% 0% 0% 53.9°C 0/5 10:17:06: 1800/1416MHz 1.45 31% 0% 31% 0% 0% 0% 57.8°C 0/5 10:17:11: 1800/1416MHz 2.07 68% 0% 67% 0% 0% 0% 57.2°C 0/5 10:17:17: 1800/1416MHz 2.30 78% 0% 77% 0% 0% 0% 58.9°C 0/5 10:17:22: 1800/1416MHz 2.52 90% 1% 89% 0% 0% 0% 57.8°C 0/5 10:17:27: 1800/1416MHz 2.72 81% 0% 80% 0% 0% 0% 57.2°C 0/5 Time big.LITTLE load %cpu %sys %usr %nice %io %irq CPU C.St. 10:17:32: 1800/1416MHz 2.66 61% 0% 60% 0% 0% 0% 60.6°C 0/5 We get an overall score of above 6100 and 7-zip's 'CPU Freq' line reports CPU0 (a little core) being clocked at 1.4 GHz. But since this is a big.LITTLE design we need the monitoring output that gets displayed below 7-zip benchmark numbers. By looking at the 2nd line we see that the system was totally idle prior to starting the benchmark (I implemented a 10 second sleep between starting monitoring and firing up the benchmark for this reason -- to control whether the system was already busy or not). As a comparison 7-zip numbers of another RK3399 board that allowed the CPU cores to clock slightly higher (2.0/1.5 GHz): ODROID-N1 scored 6500. As a reference some other boards. Rock64 with new 1.4 GHz settings: NanoPi NEO with cpufreq scaling limited to 816 MHz to keep the board always at lowest DVFS voltage (results irrelevant) Please keep in mind that benchmarks that run fully multi threaded are NOT representative for most workloads running on computers (they're single threaded). Also please keep in mind that while 7-zip is not that much affected by different compiler settings (like the infamous sysbench) of course it is somewhat. So when you see 7-zip benchmark numbers generated few years ago when the 7z binary has been built with a GCC 4.x most probably with today's software and a binary built by GCC 7.x you see higher scores. So take these comparison numbers with a grain of salt: https://s1.hoffart.de/7zip-bench/ To get new armbianmonitor with -z functionality today it's as easy as wget -O /usr/bin/armbianmonitor https://raw.githubusercontent.com/armbian/build/master/packages/bsp/common/usr/bin/armbianmonitor
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines