-
Content Count
42 -
Joined
-
Last visited
Reputation Activity
-
TCB13 reacted to williamv in NanoPI M4
received my nvme board and ssd this week, here is my iozone results.
FriendlyArm Nanopi M4v1 4GB board NVME board Armbian Buster Desktop Kernel 5.4.28 Adata XPG SX8200 Pro 1TB Tom's hardware favorite
iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
random random
kB reclen write rewrite read reread read write
102400 4 97170 133733 155927 156368 61290 133851
102400 16 254791 325694 337906 339478 134043 323214
102400 512 669920 744732 662990 674603 558387 670433
102400 1024 658770 710258 677015 705205 627108 776480
102400 16384 820732 824027 727671 731739 722866 821623
Power consumption is up from 5.5-6.5watts for 2 and with 1024 and 16384 for 3 watts up to 9.5watts.
Not bad for a lame SBC. I use with Postgres, Timescaledb and Grafana in Docker containers.
-
TCB13 reacted to NicoD in NanoPI M4
Try bigger files. This test does files of 64k. Try files of 100MB 100times.
dd if=/dev/zero of=test bs=100MB count=100 conv=fdatasync I use the gnome-disks utility to benchmark. It shows the performance with big files, but also the latency what is important for small files. That way you get numbers that can be understood.
-
TCB13 got a reaction from Larry Matter in NanoPI M4
My results with a NanoPi M4v2 + 8A custom power supply + Samsung NVMe 250 GB EVO 960 PRO:
$ dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.72603 s, 394 MB/s
Kernel 4.4.213-rk3399
Slow isn't it ? I wonder what can be done to improve this.
-
TCB13 reacted to shaun27 in NanoPI M4
I like to further add regarding Sabrent 256GB Rocket NVMe i have tested this write speed and read speed same time.
Read 390mb give or take few mb and around 380 write.
So i would assume this is the upper limit on the pci2.1 on the m4 of around 780 something considering the NVMe is rated 1050mb write 3100 read. Still alot faster then the ssd i tested through usb3.
-
TCB13 reacted to Sir Lazarus in NanoPI M4
It seems, that there is no driver for fan in armbian. So I wrote a little program in C to control fan on the hat. This nice program adjust the fan speed on cpu temperature accordingly. It starts the fan as 60 °C with 30% power. At 70 °C up to 60% and at 80 °C to 90%. You can adjust it within the code easily.
Compile it with "gcc fancontrol.c -o fancontrol". I configured the program as service. If you want it too, do the following steps:
Create a file fancontrol.service with the following content:
[Unit] Description=Fan control [Service] Type=simple User=root Group=root WorkingDirectory=/usr/bin ExecStart=/usr/bin/fancontrol [Install] WantedBy=multi-user.target do the following steps
sudo cp fancontrol /usr/bin sudo cp fancontrol.service /etc/systemd/system sudo systemctl enable fancontrol sudo systemctl start fancontrol and that's it.
It works perfekt for me.
Have fun.
-
TCB13 reacted to justin.wills in NanoPi M4 V2 - M4 Image not working
Linux m4-2 5.4.13-rockchip64 #19.11.8 SMP PREEMPT Wed Jan 22 22:53:38 AEDT 2020 aarch64 aarch64 aarch64 GNU/Linux
this is a home built image with X
-
TCB13 reacted to Nobby42 in NanoPi M4 V2 - M4 Image not working
Now I have get the next crash processes (see the log).
Kernel 5.4.13
CPU 1,42/1,8Ghz governor is set to "conservative"
What I doing. I open the webgui from a nextcloud (docker) installation.
log_crash-20200191.txt
-
TCB13 reacted to Noboot in SSHD crashes at kernel 5.4.8 by using rsync
Hi,
First, I use a mean well S-100F-12 (12 Volt 8.5 A)
https://www.meanwell-web.com/nl-nl/ac-dc-enclosed-power-supply-output-12vdc-at-8-5a-s--100f--12
This one I had some time and I wasn't using it.
I power the NanoPi true the 4-pin connector on the sata hat with a connector used from an old PC power supply. (All 4 wires connected)
I had some spare time this week-end and did some test with my NanoPi.
The problem seems to be more noticeable when I use midnight commander and copy files from usb to the sata hat.
It also shows up when copying files from network to sata true a samba share on the NanoPi.
Slowing down the CPU to 1800 ,1600 and 1400 did not make a difference.
Temperature found with htop was approx. 42-40°C at max CPU and at 1600 - 1400 about 36°C
I have a large slow turning fan on the NanoPi and a 50mm direct above the sata hat.
What I found strange is, that when I started from a cooled down NanoPi the NanoPi worked longer before failing than when is just rebooted and started again. (Or it is my imagination :-))
After another tip on https://forum.openmediavault.org/index.php/Thread/30512-Nanopi-crashes-on-file-transfers/ I restarted and used kernel 4.4.
The CPU is now running at 1800 with a temp of 30 a 35°C and I don’t seem to have this problem anymore.
At this point I'm not sure it's a power problem or a temperature problem but I'm planning to spend some more time on it this weekend.
There is also still a possibility that I received a faulty NanoPi or hat . . .
Any further input about this is always welcome.
-
TCB13 reacted to Nobby42 in SSHD crashes at kernel 5.4.8 by using rsync
Since I set the CPU frequency to 1.4/1.8Ghz I have no problems.
Look at this topic
-
TCB13 reacted to denni_isl in NanoPi M4 V2 - M4 Image not working
Erueka! Now the wifi is working perfectly.
Did fallow part of this instructions https://askubuntu.com/questions/621452/something-keeps-changing-my-wireless-regulatory-domain
-
TCB13 reacted to Nobby42 in NanoPi M4 V2 - M4 Image not working
It was the same with me, too. CPU message on the console and nothing works. I use the 5.4.8 kernel.
Currently I use a power supply with 5.3V/4A on pin4/6
https://www.amazon.de/gp/product/B01HRR9GY4/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1
But I'm not entirely satisfied with that either.
I am currently preparing a rack mounting of the NanoPi and will then use this power supply.
https://www.meanwell.com/webapp/product/search.aspx?prod=RS-25
That's stable at 5A.
-
TCB13 reacted to Matthias in NanoPi M4 V2 - M4 Image not working
I didn't observe any crashes because of high load but what I encountered when compiling code were messages on the console indicating (indirectly) that there is something odd with the CPU (sorry, I don't remember the text). I tried to fix that using more powerful power supply, but that did not help. Not even the 12V supply via the SATA-hat. What did help was setting the governor for the CPU frequency to "conservative". Since I did that, I never got any strange messages anymore. So my conclusion was, that the board might have problems handling spikes or large changes in power consumption.
But of course, that's not a prove against crashes...
-
TCB13 reacted to piter75 in NanoPi M4 V2 - M4 Image not working
@Matthias the original issue with tx_delay/rx_delay (as tested with iperf) was fixed in all kernels back then.
The issue with tx programmable buffer length that exhibited itself with Samba is fixed only in 5.x for now.
-
TCB13 reacted to piter75 in NanoPi M4 V2 - M4 Image not working
Could you possibly test it with 4.x on M4v2?
-
TCB13 reacted to Matthias in NanoPi M4 V2 - M4 Image not working
Interesting, I also had problems copying files using the 5.4 kernel on my NanoPi M4V2. I compiled it myself and copies files from the sd-card to and external hard drive connected via the SATA-hat. I used file systems on the hard drive that were able to detect corrupted data on the drive (ZFS and BTRFS) and every time I did a scrub after copying the files, failed CRC-checks within the data were reported, some of them even at the same position on two redundant drives (mirror).
I'll try again with the legacy kernel (4.x). Would be greate if it works in this configuration. @piter75: Did you apply your fixes for ethernet also to the legacy kernel? Then it would be much easier to get the data onto the device in the first place.
-
TCB13 reacted to guidol in NanoPI M4: Disable LEDs and WiFi
for the LEDs you can try the following:
ls -l /sys/class/leds
(here as example from a NanoPi Neo2):
lrwxrwxrwx 1 root root 0 Feb 20 21:50 nanopi:green:status -> ../../devices/platform/leds/leds/nanopi:green:status
lrwxrwxrwx 1 root root 0 Feb 20 21:50 nanopi:red:pwr -> ../../devices/platform/leds/leds/nanopi:red:pwr
then echo none to the trigger of the led-name:
echo 'none' > /sys/class/leds/[name_of_the_led]/trigger
so it should look like this:
echo 'none' > /sys/class/leds/nanopi:green:status/trigger
You only have to check the led-names of your board and add the commands in /etc/rc.local before "exit 0"
-
-
TCB13 reacted to martinayotte in AppArmor
Probably ...
To confirm, check it by doing "grep APPARMOR /boot/config-*" .
-
TCB13 reacted to littlema in NanoPI M4
I try it in kernel 4.4.167.
Thank you for your help.
I am very excited that it can work very well.
But I also try it in the latest kernel 4.20,but get 'don't support the operation'.
I don't know why.
But I can have a good work in the 4.4.167.
Thank you very much!!!
-
TCB13 reacted to Igor in NanoPI M4
Most Armbian images do not have this problem as well.
It should be fixed, but our fix could also be broken - RK3399 has handull of small troubles which is why we actually don't provide end user support yet. When you are approaching with a problem, you always need to provide logs (armbianmonitor -u).
-
-
-
TCB13 reacted to Igor in NanoPi NEO2: Update not working
You are using something what was designed for developers and for testing. Neo2 does not have stable builds with mainline kernel yet.
This particular error shows that daily automated system is broken and it doesn't provide consistent updates. I am working on fixing it for last two days ... try once again in a week, but beware that you are using unstable kernel, which update might break your system completely. Rather don't upgrade until stable builds are out ...
-
TCB13 reacted to Igor in NanoPi NEO2: CPU Frequency
You are using modern mainline development kernel and those images are experimental. AFAIK this feature is not ported / developed / forgotten to add.