kimidare

Members
  • Content Count

    9
  • Joined

  • Last visited

About kimidare

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I've read this and it surprised me noone mentioned e2image. I'm using armbian orange pi pc build. The fs is stock ext4 hence why I stick to e2image below. It is not about cloning a live system, hence the sdcard is plugged into my PC. Fdisk shows a single partition at 4M offset. First I backup the partition table and bootloader dd if=/dev/sdX of=offset0.img bs=4M count=1 Next I backup the single partition with e2image into a qcow2 image e2image -Qa /dev/sdX1 part0.qcow2 qcow2 only keeps used blocks. My partition size is 14.7G, space taken is 12%. part0.qcow2 file is 1.7G. Done with backup. Now recover onto an sdcard of the same size (I know armbian keeps some % free when expanding the partition, so there is no problem with Xgb cards having different space up to some bytes, Kbs or even Mbs). First recover the partition table and bootloader dd if=offset0.img of=/dev/sdX bs=4M Make the kernel aware about the partitions on /dev/sdX partprobe /dev/sdX Recover the partition e2image -rc part0.qcow2 /dev/sdX1 That's all, just 2 lines to backup (while only keeping used blocks) and 3 lines to restore. As simple as it is, is it correct overall or mby I've missed something? Update: changed the recover partition command from qemu-img to e2image to utilize the latter's "-c" option targeted for flash drives.
  2. https://linux-sunxi.org/Cryptographic_Hardware_Accelerators Does it mean AES CBC will be hardware accelerated out-of-the-box on Allwinner H3 boards when armbian starts to ship kernel 5.5?
  3. So, with a clean install of Armbian_19.11.3_Orangepipc_buster_current_5.3.9 there is no performance problem outlined above. The pi saturates 30mbit connection when dowloading a torrent over openvpn, cpu usage is the same 40% as with my older setup. But the cpu temperature shown is still much higher with armbian 19.11.3. Idle stats armbian 5.92 kernel 4.19.62 vs 19.11.3 kernel 5.3.9 Torrent downloading at 30mbit over openvpn link stats 5.92 kernel 4.19.62 vs 19.11.3 kernel 5.3.9 I wonder if there mby was some change in temp reporting for H3 in the kernel? Mby readings for 4.19.62 are actually wrong? Ambient temp is slightly over 20C, the chip has an aluminium heatsink installed, the board is enclosed in the official orangepi pc case
  4. KK. I'll try a clean install on another sdcard later and report the results here then.
  5. I've been happily running orangepipc with armbian (buster, 4.19.62-sunxi) as an openvpn gateway for my home devices for some time. Here are some details: I have a remote openvpn server the pi runs an openvpn client and connects to the server the pi has ipv4 packets forwarding enabled my wifi router provides the pi's ip as the default gateway via dhcp So when I connect to wifi with my phone, all phone traffic will be routed through the remote openvpn server without need to install the openvpn client on the phone itself. With this setup the pi can easily saturate my 30mbit cable connection when downloading torrents for example. Just now I tried to upgrade the kernel to 5.3.9 as is outlined here https://forum.armbian.com/topic/12210-armbian-1911y-release-notes/ So first I tried "linux-image-current-sunxi=19.11.3 5.3.9-sunxi" After reboot I noticed the cpu got +10C more hot: 35 vs 45 idle. The cpu freq settings /etc/default/cpufrequtils were missing and the cpu was running 480-1368MHZ. So I created /etc/default/cpufrequtils using the same settings from the 4.19.62-sunxi kernel (408-1296MHZ) and restarted the cpufrequtils service. Nothing changed much, the temp was still like +10C higher than previously. Next I tried "linux-image-legacy-sunxi=19.11.3 4.19.84-sunxi" After reboot the cpu was still hot. But I noticed another problem. I started a torrent and it was hardly hitting 1Mb/s instead of usual 3Mb/s. Openvpn process was at 70% cpu and some kernel process was at 20% some. I guess both processes used the same cpu core and the downloading of 1MB/s was because of the core bottleneck. I think the same problem comes with "linux-image-current-sunxi=19.11.3 5.3.9-sunxi", but I mostly payed attention to the temparature trying that. Next I rolled back to "linux-image-next-sunxi=5.92 4.19.62-sunxi" After reboot the cpu was back to the normal temperature. The torrent download speed was over 3Mb/s while the openvpn process was only using like 40% cpu core and there was no kernel process eating much cpu in "top" output. Cpu temperature was up to 42-43C during that - it was lower than idle temp for "linux-image-current-sunxi=19.11.3 5.3.9-sunxi" and "linux-image-legacy-sunxi=19.11.3 4.19.84-sunxi" ! Is this (more heat and performance problem) a well-known problem with 19.11.3 (both 5.3.9-sunxi and 4.19.84-sunxi) for orangepipc|H3 ?
  6. Have you tried plugging anything else into the usb port? Did it work? Like a usb flash, another wifi dongle or usb-hdd?
  7. Don't you have a usb-ttl thing? http://wiki.t-firefly.com/ROC-RK3328-CC/debug.html
  8. Hey guys. 1. This piece if [[ $(lsb_release -sc) =~ bionic|buster|cosmic|disco ]]; then mkopts[ext4]='-q -m 2 -O ^64bit,^metadata_csum' elif [[ $(lsb_release -sc) == xenial ]]; then mkopts[ext4]='-q -m 2' fi Why disable metadata_csum? Why disable 64bit overall, not just for pure 32 bit boards? Edit on Mar 9 2020 Metadata checksums is a new feature of ext4 since e2fsprogs 1.44 (xenial has 1.42). It makes the fs more robust to data corruption but it requires some extra cpu power to calculate the checksums. It is not a problem for generic cpus with SSE4.2 (= hardware accelerated crc32): intel since core gen1, amd since bulldozer. Arm world is not that simple. So we just disable the checksums in distros which have them on by default in /etc/mke2fs.conf to reduce cpu usage. The 64bit option is only required for the checksums (since armbian is not something for use with really huge storages) hence we disable it as well. 2. This piece [[ $ROOTFS_TYPE == ext4 ]] && tune2fs -o journal_data_writeback $rootdevice > /dev/null Why enable journal_data_writeback feature? What are the pros and cons? Edit on Mar 9 2020 "Data mode" section in https://www.kernel.org/doc/Documentation/filesystems/ext4.txt