Same symptom as overwriting the rootfs with /dev/uramdom. Everything slows down and then the install freezes/crashes (I sometimes do this for fun when phasing out server hardware).
I would believe you experienced a broken eMMC module where the flash controller did weird things. Most probably neither related to board nor software.
@willy, may you check what kind of numbers you get with iperf3 (with PC as server and then with Rock5 as server)?
When I try this on my setup (10G switch with 2.5G/5G transceiver) I receive 2.5G on one direction and 1.3G on another
From Rock5 (iperf3 -c 192.168.1.38) to PC (iperf3 -s)
Connecting to host 192.168.1.38, port 5201 [ 5] local 192.168.1.45 port 59722 connected to 192.168.1.38 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 289 MBytes 2.43 Gbits/sec 0 218 KBytes [ 5] 1.00-2.00 sec 290 MBytes 2.43 Gbits/sec 0 218 KBytes [ 5] 2.00-3.00 sec 288 MBytes 2.42 Gbits/sec 0 227 KBytes [ 5] 3.00-4.00 sec 288 MBytes 2.42 Gbits/sec 0 227 KBytes [ 5] 4.00-5.00 sec 288 MBytes 2.41 Gbits/sec 0 227 KBytes [ 5] 5.00-6.00 sec 288 MBytes 2.42 Gbits/sec 0 227 KBytes [ 5] 6.00-7.00 sec 288 MBytes 2.41 Gbits/sec 0 227 KBytes [ 5] 7.00-8.00 sec 289 MBytes 2.43 Gbits/sec 0 227 KBytes [ 5] 8.00-9.00 sec 286 MBytes 2.40 Gbits/sec 0 227 KBytes [ 5] 9.00-10.00 sec 288 MBytes 2.42 Gbits/sec 0 227 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 2.81 GBytes 2.42 Gbits/sec 0 sender [ 5] 0.00-10.00 sec 2.81 GBytes 2.42 Gbits/sec receiver
From PC (iperf3 -c 192.168.1.45) to Rock5 (iperf3 -s)
---------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.1.38, port 59368 [ 5] local 192.168.1.45 port 5201 connected to 192.168.1.38 port 59369 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 46.4 MBytes 390 Mbits/sec [ 5] 1.00-2.00 sec 126 MBytes 1.05 Gbits/sec [ 5] 2.00-3.00 sec 206 MBytes 1.73 Gbits/sec [ 5] 3.00-4.00 sec 29.6 MBytes 248 Mbits/sec [ 5] 4.00-5.00 sec 91.6 MBytes 767 Mbits/sec [ 5] 5.00-6.00 sec 165 MBytes 1.39 Gbits/sec [ 5] 6.00-7.00 sec 93.3 MBytes 782 Mbits/sec [ 5] 7.00-8.00 sec 94.7 MBytes 795 Mbits/sec [ 5] 8.00-9.00 sec 242 MBytes 2.03 Gbits/sec [ 5] 9.00-10.00 sec 168 MBytes 1.41 Gbits/sec [ 5] 10.00-10.19 sec 46.0 MBytes 2.03 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.19 sec 1.28 GBytes 1.08 Gbits/sec receiver
Not sure which Desktop you are referring to but 290MB of total used memory is from CLI (no Desktop). The Desktop i have used is xfce4 with X11. Wayland seems to be twice faster than X11 for the hw accel but Gnome and Kde use a lot of memory, maybe twice as of xfce4.
I have a new 64GB eMMC installed and will rebuild everything. If that is what happened (and looks like), i will update here.
Building kernel natively … Pass OK
Ambient Temp… 12 ºC
Hm, completely forgot about this one.
root@rock-5b:/mnt/md127# cat /sys/module/pcie_aspm/parameters/policy [default] performance powersave powersupersave
Not like it helped in this case, but maybe it will solve my another problem
Sooo, you are not gonna cool the memory modules or power module or at least use fan cooler? You just use small passive heatsink for 12W cpu, and receive 85 degree on CPU\GPU temp. HMMMM, totally not overheat
For example - that is my setup for building kernel. And I still get 61 degree on it.
root@rock-5b:/mnt/md127# cat /sys/class/thermal/thermal_zone*/temp 65615 68384 68384 66538 62846 61000 62846
I measured 2.35 Gbps even with iperf3 pinned to a little core as such I would propose to repeat the test this time still with the PC as server and using iperf3 -R -c 192.168.1.38 on Rock 5B. This way retransmits are reported. If there are plenty of them I would check/replace the cable (TX/RX use different pairs).
Also removing the switch would be an idea. Just install avahi-autoipd avahi-daemon prior to this and access the other host not via an IP address but by it’s name (if your PC’s hostname is foobar then it can be accessed as foobar.local).
I did not expect it would heat up like that, but it was one-time only to make sure eMMC would survive. I am glad it survived.
Ok, I think VCore is fixed.
cat /sys/class/regulator/regulator.??/name |grep vdd_cpu
vdd_cpu_lit_s0
vdd_cpu_big0_s0
vdd_cpu_big1_s0
root@rock5b:/home/rock# cat /sys/devices/platform/fd880000.i2c/i2c-0/0-0042/regulator/regulator.30/name
vdd_cpu_big0_s0
root@rock5b:/home/rock# cat /sys/devices/platform/fd880000.i2c/i2c-0/0-0043/regulator/regulator.31/name
vdd_cpu_big1_s0
cat /sys/kernel/debug/regulator/vdd_cpu_lit_s0/voltage
675000
Welp, switched from windows to ubuntu. 14k retransmission surely explain why speed so low. I guess the problem with my setup
Not really possible, since I don’t have any 2.5G nic with me. That’s why I was asking for results from someone else.
Yes. So to be clear your PC has a 10GbE NIC and your switch is Nbase-T capable?
2.35 Gbit/sec in both directions even on a little core.
BTW: RealTek RTL8156B USB3 dongles work pretty well. With macOS even RTL8156 (without the B) but numerous people report problems with Linux (no idea about Windows, almost no use for this OS).
But as usual: ‘buy cheap, buy twice’.
Yes, that’s correct. I guess the transceiver is to blame here. Since I get the same picture even if I force it to 1G with PC to PC. Mikrotik with S+RJ10 is not best choice for 2.5G Ethernet
This is great news. Means its getting closer for us that pre-ordered months and months ago. Looking forward to the new chip and retiring my RK3399’s
More Ethernet basics (but I’ll leave that up to @willy to explain).
Anyway: it’s not an Rock 5B / RTL8125BG issue.
BTW: the amount of feedback from Radxa is overwhelming. But maybe all the important stuff happens in some closed/hidden Discord channel and they (together with those great Armbian guys babbling in their armbian-devel Discord crap channel that is not logged anywhere) simply laugh about everything that happens here ‘in the open’?
Yes, it’s not.
Btw, there should be link towards this closed channel somewhere?
Are you hinting at something special or can we expect that Rock 5B’s M.2 implementation supports ‘bifurcation’ including clocks to the point where aforementioned PCIe splitters or this ODROID H2 net card work flawlessly?
Currently we have reserved two PCIe clock on the M.2 M key of ROCK 5B, which means if splitting the PCIe x4 to two PCIe x2 is possible, without additional PCIe switch.
it needs pipewire-pulse. you may try this: https://pipewire-debian.github.io/pipewire-debian/
Ooh, I wonder if the Optane H10 (which uses x2x2 bifurcation) would work…
Why ask the Radxa team to support an obsolete Intel technology that only works on Microsoft Windows?