I am having a lot of fun playing with Ubuntu on my VIM2, it certainly seems to have some strengths to use as a desktop replacement for my old Pi3!
chris@Khadas:~$ uname -a
Linux Khadas 4.9.26 #49 SMP PREEMPT Fri Aug 18 11:15:04 CST 2017 aarch64 aarch64 aarch64 GNU/Linux
I do have 2 observations/requests though:
I guess there is no DVB support in the kernel? Because when I plug in my DVB stick I get no driver loaded nor creation of the /dev/dvb tree.
Sep 13 09:50:35 Khadas kernel: usb 1-1.2: new high-speed USB device number 3 using xhci-hcd
Sep 13 09:50:36 Khadas mtp-probe[6143]: checking bus 1, device 3: "/sys/devices/platform/c9000000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.
Sep 13 09:50:36 Khadas mtp-probe[6143]: bus: 1, device: 3 was not an MTP device
chris@Khadas:/home/photos$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 048d:9135 Integrated Technology Express, Inc. Zolid Mini DVB-T Stick
Bus 001 Device 002: ID 1a40:0801 Terminus Technology Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
The eMMC/sdcard speeds seem pretty poor (e.g. compared to Odroid C2). I get 82.8/36.4MB/s Read/Write on the MMC and 18.0/4.5MB/s on a Toshiba Exceria UHS sdcard
chris@Khadas:~$ dd if=/dev/zero of=test.tmp oflag=direct bs=8M count=64
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 14.7652 s, 36.4 MB/s
chris@Khadas:~$ dd if=test.tmp of=/dev/null iflag=direct bs=8M count=64
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 6.4865 s, 82.8 MB/s
chris@Khadas:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 1.3G 0 1.3G 0% /dev
tmpfs 300M 9.0M 291M 3% /run
/dev/rootfs 58G 41G 15G 74% /
tmpfs 1.5G 84K 1.5G 1% /dev/shm
tmpfs 5.0M 8.0K 5.0M 1% /run/lock
tmpfs 1.5G 0 1.5G 0% /sys/fs/cgroup
/dev/mmcblk1p1 57G 52G 2.8G 95% /home/photos
tmpfs 300M 16K 300M 1% /run/user/1001
chris@Khadas:~$ cd /home/photos/
chris@Khadas:/home/photos$ dd if=/dev/zero of=test.tmp oflag=direct bs=8M count=64
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 120.423 s, 4.5 MB/s
chris@Khadas:/home/photos$ dd if=test.tmp of=/dev/null iflag=direct bs=8M count=64
64+0 records in
64+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 29.8903 s, 18.0 MB/s
Please keep up the good work!
ps - realised the default interactive governor may not be helping the IO speeds: swapping to performance does help - significantly in the case of eMMC reads. With performance governor I get
eMMC 129/47 MB/s
SDcard 20.9/4.8 MB/s
Which has convinced me to swap to performance full time.
1. Check current disk schedulers:
Code: Select all
root@odroidc2:/etc/udev/rules.d# for f in /sys/block/sd?/queue/scheduler; do printf "$f is "; cat $f; done
/sys/block/sda/queue/scheduler is [noop] deadline cfq
root@odroidc2:/etc/udev/rules.d# for f in /sys/block/mmcblk?/queue/scheduler; do printf "$f is "; cat $f; done
/sys/block/mmcblk0/queue/scheduler is [noop] deadline cfq
/sys/block/mmcblk1/queue/scheduler is [noop] deadline cfq
As per my custom kernel, I can use noop, deadline, or cfq for disk schedulers - and noop is the default for all drives. Lets change that!
2. Check that rotational field is valid per drive:
Code: Select all
root@odroidc2:/etc/udev/rules.d# for f in /sys/block/sd?/queue/rotational; do printf "$f is "; cat $f; done
/sys/block/sda/queue/rotational is 1
root@odroidc2:/etc/udev/rules.d# for f in /sys/block/mmcblk?/queue/rotational; do printf "$f is "; cat $f; done
/sys/block/mmcblk0/queue/rotational is 0
/sys/block/mmcblk1/queue/rotational is 0
As per the above, 0 means the drive does not rotate and 1 means the drive is a spinning disk.
3. Create udev rule:
Code: Select all
cat >/etc/udev/rules.d/60-disk-scheduler.rules <<EOL
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0",ATTR{queue/scheduler}="noop"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1",ATTR{queue/scheduler}="deadline"
ACTION=="add|change", KERNEL=="mmcblk[0-9]", ATTR{queue/rotational}=="0",ATTR{queue/scheduler}="noop"
EOL
5. Reboot and check the schedulers per drive by using the following commands:
Code: Select all
root@odroidc2:/etc/udev/rules.d# for f in /sys/block/sd?/queue/scheduler; do printf "$f is "; cat $f; done
/sys/block/sda/queue/scheduler is noop [deadline] cfq
root@odroidc2:/etc/udev/rules.d# for f in /sys/block/mmcblk?/queue/scheduler; do printf "$f is "; cat $f; done
/sys/block/mmcblk0/queue/scheduler is [noop] deadline cfq
/sys/block/mmcblk1/queue/scheduler is [noop] deadline cfq
My (or default in the Khadas firmware ) scheduler was cfq: swapping to noop arguably improves things (but the dd test is somewhat variable anyway). And yup Khadas default was already rotational = 0.
Have (re-)discovered my Toshiba Exceria card is rubbish: for the SDcard have tried a Samsung Evo+ which is far better on a RPi3 for small writes. But still performance governor is a much bigger gain over interactive. I am pretty happy with IO speeds now on the VIM2 - my latest numbers for the dd tests (with noop disk scheduler) are:
interactive governor
MMC 88.4/39.8 MB/s (Read/write)
SDcard 20.1/13.6 MB/s (this is the Evo+)
So my original point 2 is resolved for me. Just DVB support in the kernel would be nice. @freeasinbeer - if I can find some time may pick your brains how to compile a 4.13 kernel for the VIM2 and load it without having to burn a complete new firmware (I have never compiled a kernel before!)
My slap happy copy/paste, may have confused. NOOP for I/O scheduler for emmc / TF / SSD.
CFQ/Deadline for old drives (depending on kernel, because of changes to code, but google should answer the question per kernel. deadline for 4.9 was faster)
Using your test with dd, I see repeatable improvement using NOOP over either other for emmc.
As for the perf governor - you’re probably be better off setting ‘ondemand’
Technically, these should not make a real difference - regardless of mode, the cpu should kick in full speed under load.
Anyway ‘performance’ will just waste power in idle. Ondemand will take a cycle or two to get to full speed, but slow back down when doing nothing, saving power.
I could help with tips - we are all expecting @Khadas@Gouwa@numbqq to give us nice rewritten howto documents for compiling kernel, and configuring u-boot etc soon.
Note: latest kernel is not alway the best option. 4.9 is supported well (you will get usb/wifi/bt etc). Latest kernels have all sorts of issues with ethernet/wifi/usb at the moment.
Currently 4.9-40 will get you going, all supported. You can get on with what you need to do, rather than messing about with getting the kernel working.
It seems to me there is no USB tethering support in the V170818 image? lsusb shows my phone in tethering mode but dmesg has no rndis actions.
(Of course always possible I have messed something up but for sure cannot get to work today, cannot be sure if have ever had it working as think have used WiFi since plugging in my VIM2.)
Something else I have noticed - X11 or the hardware does not support dpms properly. sleep 1; xset dpms force off
just blanks the screen, it does not turn off the backlight. It would be nice if this could be fixed to help power saving.
Very bad decision! Why do you focus on Android? It would be more productive if dvb is avaiable under linux. There we have much more possibilities, like tvheadend as a tv server. If dvb would be supportet in linux your VTV Extension DTV Board makes more sense…without i think about resell the VIM2. If i want an Android i can use any cheap tablet…
Alternatively, it would be nice if the linux-headers would be available, so you can build the required firmware yourself.
) scheduler was cfq: swapping to noop arguably improves things (but the dd test is somewhat variable anyway). And yup Khadas default was already rotational = 0.
