I definitely understand, and the efforts are very much appreciated!
— Jeremiah
Since blkid shows it being mounted would make me move toward an OS issue.
Agree the VIM3 is running 20.04 and is rock sold, we have several desktops running that configuration for months with out any problems.
Jammy desktop has mouse trails on my board, that pretty much ended the game with that version.
Did get the UFW issue resolved with some kernel config changes so VIM4 and 22.04 server is back on the table.
A while back 6.0-rc5 or so had some amlogic updates. I have not done anything with that version.
While I agree with @JeremiahCornelius, I had to try Ubuntu Server out of curiosity.
Unfortunately, it still didn’t recognise my NVME drive in the USB3 caddy but I plugged it direct into the board and did an image backup of the eMMC to it using the exact same commands I’ve used before and then wrote the image to an SD card.
Lo and behold, the SD card booted and appeared to be fine.
I wonder though - could this be a fluke or could it be because there’s less I/O due to the system not having a Gnome Desktop to deal with?
1 Like
I just wanted to take the time to thank you @numbqq for all the work that your team is doing not only on the VIM4 but the other devices you’ve got… That sort of work is not easy and I just wanted to let you know that we appreciate what you’re doing. I think I can speak on behalf of the others here and say “thanks!” … It’s not fun being under constant pressure as I know we want a quick fix but sometimes the fixes are not quick and take a lot of painful examination & study to get the proper solution.
It’s not easy being the one in the middle so to speak if you’re not getting proper support from the chip or software companies … 
Thank you!!
3 Likes
Different USB IP would be a bummer. But what users report here wrt NVMe can’t be explained by all of them not differentiating between NVMe and USB, right?
One of my experiments involved a fresh NVMe install with the oowow server image, then rsync of my working eMMC desktop to the new filesystem, while having booted from a server install on SD.
It also failed badly, although rsync reported no errors. 
I’ve no ideas about the NVMe issues. I’m not actively doing anything with the board at the moment.
I am running the WD blue 570 and it has not crashed, uptime is showing over 2 days.
An issue does exist.
dd if=/dev/zero of=/dev/null && sync
You will have to use ctrl-c to stop dd command and read the report.
Vim 3 pro NVMe using WD 570 it is running 825 M/bs
Vim 4 ubuntu jammy server WD 570 is running 221 M/bs
dd if=/dev/nvme0n1 of=/dev/null && sync
vim 3 pro >> 340 M/bs
vim 4 >> 165 M/bs
Nope, Amlogic SoCs have a single PCIe Gen2 lane that is limited to 5 GT/s at 8b10b coding as such you have not the slightest chance to ever exceed 500 MB/s. You’re just using the wrong tool in a wrong way (dd defaults to 512 byte block size and this is slow as hell but you did not even test storage but filesystem buffers.)
This is what Khadas measured with tools up to the task: Khadas VIM3 Amlogic S922X Board to Support M.2 NVMe SSD, WiFi 5, and Bluetooth 5 Connectivity - CNX Software
That’s a lower number but still telling nothing. 
Khadas copy&pasted (mostly) my q&d script code over from Armbian to improve I/O performance but do you find the string vim4 anywhere in fenix-hardware-optimization today? Me not.
I sent Nick from Khadas already few PM to improve this several weeks ago but it seems they’re busy with other stuff.
The Armbian clowns even brag about their ignorance related to all of these I/O settings.
I did not have anything to use for CLI, been using gnome benchmark on gui. Here is gnome disks and a dd, very huge difference, same board.
Do you have a tool that will work on CLI, so an apple to apple comparison between boards can be made.
They (tkaiser) were using fio (flexible IO tester) in that discussion, which is a bit interesting.
The man page is good but I found this: https://arstechnica.com/gadgets/2020/02/how-fast-are-your-disks-find-out-the-open-source-way-with-fio/, which is also helpful.
my suggestions about dd usage for speed performance testing ( results for default 512 bytes io buffer size will be informative ), better use next example with bigger bs
dd if=/dev/nvme0n1 bs=512000 of=/dev/null status=progress
1 Like
Thank you, that seems like a much better number.
VIM4 535 M/bs
competitor 529 M/bs
Though still only some random numbers and nothing that represents your sequential storage performance. Again: VIM4 has only a single PCIe Gen2 lane that is limited to 5GT/s and uses 8b/10b coding. You can’t exceed 500 MiB/s with such a setup since this is the absolute maximum already at the physical layer. Then only further slowdowns here and there up the software stack add to this so the numbers Gouwa posted for VIM3 (around 427MiB/s / 448MB/s) are the best you could expect.
To be of any use dd would’ve to be used with correct flags (oflag/iflag=direct) and a larger blocksize. You’re still testing whatever but definitely not your storage performance.
For serious testing use iozone and/or fio. Most probably then your numbers are back at horribly low
Please can you or someone else owning a VIM4 post the output of this command:
cat /sys/devices/system/cpu/cpufreq/policy?/ondemand/io_is_busy
If there’s not two times a 1 printed then real-world storage performance is probably really low (asides meaningless benchmark numbers).
I have directories named policy0 and policy4 but neither of them contain an ondemand directory.
Maybe this will help to give you an idea of what is present on the VIM4 with Ubuntu 22.04 server at least:
khadas@Khadas:~$ find /sys/devices/system/cpu/cpufreq -type f -print
/sys/devices/system/cpu/cpufreq/policy4/scaling_min_freq
/sys/devices/system/cpu/cpufreq/policy4/scaling_available_governors
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_cur_freq
/sys/devices/system/cpu/cpufreq/policy4/scaling_governor
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_max_freq
/sys/devices/system/cpu/cpufreq/policy4/scaling_available_frequencies
/sys/devices/system/cpu/cpufreq/policy4/related_cpus
/sys/devices/system/cpu/cpufreq/policy4/scaling_cur_freq
/sys/devices/system/cpu/cpufreq/policy4/scaling_setspeed
/sys/devices/system/cpu/cpufreq/policy4/stats/reset
/sys/devices/system/cpu/cpufreq/policy4/stats/trans_table
/sys/devices/system/cpu/cpufreq/policy4/stats/total_trans
/sys/devices/system/cpu/cpufreq/policy4/stats/time_in_state
/sys/devices/system/cpu/cpufreq/policy4/affected_cpus
/sys/devices/system/cpu/cpufreq/policy4/scaling_max_freq
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_transition_latency
/sys/devices/system/cpu/cpufreq/policy4/scaling_driver
/sys/devices/system/cpu/cpufreq/policy4/cpuinfo_min_freq
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
/sys/devices/system/cpu/cpufreq/policy0/related_cpus
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed
/sys/devices/system/cpu/cpufreq/policy0/stats/reset
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table
/sys/devices/system/cpu/cpufreq/policy0/stats/total_trans
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
/sys/devices/system/cpu/cpufreq/policy0/affected_cpus
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency
/sys/devices/system/cpu/cpufreq/policy0/scaling_driver
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq
khadas@Khadas:~$
find /sys/devices/system/ | grep io_is_bus
/sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
maybe cat /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
Nope… it (the ‘ondemand’ directory) doesn’t exist:
khadas@Khadas:~$ ls -la /sys/devices/system/cpu/cpufreq
total 0
drwxr-xr-x 4 root root 0 Oct 4 15:38 .
drwxr-xr-x 16 root root 0 Oct 3 21:30 ..
drwxr-xr-x 3 root root 0 Oct 4 15:38 policy0
drwxr-xr-x 3 root root 0 Oct 8 15:49 policy4
khadas@Khadas:~$