Мы начали обзор NanoPi R5S с распаковки, разборки, тестирования предустановленного FriendlyWrt на основе OpenWrt и некоторых тестов iperf3 на интерфейсах 2,5GbE, результаты которых были совсем не воодушевляющими. При дальнейшем тестировании мы переключились на образ FriendlyCore на основе Ubuntu 20.04, так как мы больше знакомы с операционными системами на основе Debian, а некоторые инструменты не будут работать на OpenWrt. Обратите внимание, что производительность все еще не совсем оптимальна, и именно поэтому мы называем это предварительным просмотром, поскольку, в ближайшие несколько месяцев, цифры должны улучшиться, поскольку все больше людей настраивают программное обеспечение.
Оптимизация OpenWrt?
Но, перейдя к Ubuntu, мы установили обновленную версию FriendlyWrt, так как представители FriendElec сказали нам, что они добавили некоторые оптимизации:
Мы внесли некоторые оптимизации в новый образ, такие как настройки прерывания сетевой карты и поддержку разгрузки…
Итак, мы скачали «rk3568-eflasher-friendlywrt-20220526.img.gz», найденный на Google Диске, сохранили его на карту microSD с помощью USBImager и загрузили на роутер.
Он автоматически записал изображение на флэш-память eMMC. Если вы подключите монитор, вы сможете следить за результатом. Как только это будет сделано, извлеките карту microSD и выключите и снова включите маршрутизатор.
Вы можете проверить состояние, подключив монитор HDMI (как показано выше) или проверив светодиоды на устройстве. Это очень быстро, и установка на флэш-память eMMC занимает всего несколько секунд.
Основные изменения были внесены в файл 40-net-smp-affinity. В предустановленном FriendlyWrt это выглядит так:
friendlyelec,nanopi-r5s)
set_interface_core 8 "eth0"
echo 7 > /sys/class/net/eth0/queues/rx-0/rps_cpus
set_interface_core 2 "eth1-0"
set_interface_core 4 "eth1-16"
set_interface_core 4 "eth1-18"
echo b > /sys/class/net/eth1/queues/rx-0/rps_cpus
set_interface_core 4 "eth2-0"
set_interface_core 2 "eth2-16"
set_interface_core 2 "eth2-18"
echo 9 > /sys/class/net/eth2/queues/rx-0/rps_cpus
;;
esacХотя новый файл 40-net-smp-affinity действительно отличается:
friendlyelec,nanopi-r5s)
set_interface_core 8 "eth0"
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
set_interface_core 4 "eth1-0"
set_interface_core 4 "eth1-16"
set_interface_core 4 "eth1-18"
echo b > /sys/class/net/eth1/queues/rx-0/rps_cpus
set_interface_core 2 "eth2-0"
set_interface_core 2 "eth2-16"
set_interface_core 2 "eth2-18"
echo d > /sys/class/net/eth2/queues/rx-0/rps_cpus
;;
esac
Вилли Тарро объясняет изменения, внесенные в интерфейс eth1:
Речь идет о RPS …. т.е. они получают IRQ на ядре 2 и перераспределяют входящий трафик на ядра 0,1,3. Это правильный способ использования RPS. Однако вам придется вручную назначать iperf и следить за первым ядром, которое насыщается. Если он сначала насыщает ядро 2 с помощью ksoftirqd, убедитесь, что iperf работает на любом из остальных 3. Если ядро 2 немного простаивает, попробуйте назначить на него iperf. Если при его включении всплывает ksoftirqd, то они мешают друг другу, и вам лучше изменить настройку RPS, чтобы освободить еще одно ядро и использовать его для iperf.
Мы не пробовали этот метод до тестирования и перехода на Ubuntu, и наши результаты были еще хуже с новым образом FriendlyWrt:
$ iperf3 -t 60 -c 192.168.2.1 -i 10
Connecting to host 192.168.2.1, port 5201
[ 5] local 192.168.2.130 port 49590 connected to 192.168.2.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-10.00 sec 1.92 GBytes 1.65 Gbits/sec 0 1.62 MBytes
[ 5] 10.00-20.00 sec 1.91 GBytes 1.64 Gbits/sec 10 2.34 MBytes
[ 5] 20.00-30.00 sec 1.90 GBytes 1.63 Gbits/sec 0 2.61 MBytes
[ 5] 30.00-40.00 sec 1.85 GBytes 1.59 Gbits/sec 4 1.30 MBytes
[ 5] 40.00-50.00 sec 1.88 GBytes 1.61 Gbits/sec 1 1.06 MBytes
[ 5] 50.00-60.00 sec 1.76 GBytes 1.51 Gbits/sec 2 868 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 11.2 GBytes 1.61 Gbits/sec 17 sender
[ 5] 0.00-60.05 sec 11.2 GBytes 1.60 Gbits/sec receiver
iperf Done.
$ iperf3 -t 60 -c 192.168.2.1 -i 10 -R
Connecting to host 192.168.2.1, port 5201
Reverse mode, remote host 192.168.2.1 is sending
[ 5] local 192.168.2.130 port 49594 connected to 192.168.2.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.22 GBytes 1.05 Gbits/sec
[ 5] 10.00-20.00 sec 1.36 GBytes 1.17 Gbits/sec
[ 5] 20.00-30.00 sec 1.31 GBytes 1.12 Gbits/sec
[ 5] 30.00-40.00 sec 1.46 GBytes 1.26 Gbits/sec
[ 5] 40.00-50.00 sec 1.47 GBytes 1.26 Gbits/sec
[ 5] 50.00-60.00 sec 1.46 GBytes 1.26 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.05 sec 8.29 GBytes 1.19 Gbits/sec 1 sender
[ 5] 0.00-60.00 sec 8.29 GBytes 1.19 Gbits/sec receiver
iperf Done.Так что это надо будет пересмотреть.
Установка M.2 NVMe SSD в NanoPi R5S
На днях мы приобрели APACER AS2280 (AP256GAS2280P4-1) PCIe Gen 3.0 x4 SSD, который может обеспечить скорость последовательного чтения до 1800 МБ/с и скорость последовательной записи до 1100 МБ/с на подходящем оборудовании.
Установка проста, так как нам просто нужно было ослабить четыре винта, чтобы снять нижнюю крышку, установить SSD и закрепить его прилагаемым винтом.
Установка Ubuntu 20.04 FriendlyCore на NanoPi R5S
Сначала мы попытались установить FriendlyCore, используя образ eflasher.
Все выглядело хорошо, поэтому мы перезапустили роутер, но потом заметили, что интерфейс WAN не отображается на коммутаторе TP-Link, а горит только индикатор питания (бывает, что последнее нормально для образа FriendlyCore/Ubuntu) . Мы попробовали еще раз, зайдя в настройки пользовательского интерфейса eflasher, нажав «Готово», но по-прежнему безуспешно.
Вместо этого мы загрузили образ «SD», чтобы загрузиться непосредственно с карты microSD и запустить оттуда ОС. Это работает нормально. Если вы собираетесь использовать NanoPi R5S для нескольких целей и ожидаете среду рабочего стола в образе Ubuntu 20.04, вы будете разочарованы, поскольку выход HDMI в настоящее время используется только для доступа к терминалу.
Информация о системе FriendlyCore
Вы найдете журнал загрузки на CNX Software Pastebin. Мы вошли в систему с помощью SSH, используя учетные данные pi/pi (имя пользователя/пароль), и обновили систему до последних пакетов с помощью:
sudo apt update
sudo apt dist-upgradeДавайте запустим несколько команд, чтобы получить информацию о системе:
pi@FriendlyELEC:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.4 LTS"
pi@FriendlyELEC:~$ uname -a
Linux FriendlyELEC 5.10.66 #219 SMP PREEMPT Fri Apr 22 18:20:21 CST 2022 aarch64 aarch64 aarch64 GNU/Linux
pi@FriendlyELEC:~$ free -mh
total used free shared buff/cache available
Mem: 1.9Gi 150Mi 1.7Gi 3.0Mi 114Mi 1.7Gi
Swap: 0B 0B 0B
pi@FriendlyELEC:~$ df -mh
Filesystem Size Used Avail Use% Mounted on
udev 969M 0 969M 0% /dev
tmpfs 197M 480K 196M 1% /run
overlay 27G 1013M 26G 4% /
tmpfs 981M 0 981M 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 981M 0 981M 0% /sys/fs/cgroup
tmpfs 197M 0 197M 0% /run/user/1000Все выглядит хорошо, за исключением того, что диск NVMe не был смонтирован автоматически. Давайте найдем больше деталей с inxi:
pi@FriendlyELEC:~$ inxi -Fc0
System:
Host: FriendlyELEC Kernel: 5.10.66 aarch64 bits: 64 Console: tty 0
Distro: Ubuntu 20.04.4 LTS (Focal Fossa)
Machine:
Type: ARM Device System: FriendlyElec NanoPi R5S details: N/A
serial: 8cbfe79e107c459c
Battery:
ID-1: test_battery charge: 100% condition: N/A
CPU:
Topology: Quad Core model: N/A variant: cortex-a55 bits: 64 type: MCP
Speed: 408 MHz min/max: 408/1992 MHz Core speeds (MHz): 1: 1992 2: 1992
3: 1992 4: 1992
Graphics:
Device-1: display-subsystem driver: rockchip_drm v: N/A
Device-2: mali-bifrost driver: mali v: N/A
Device-3: rk3568-dw-hdmi driver: dwhdmi_rockchip v: N/A
Display: server: X.org 1.20.8 driver: dwhdmi_rockchip tty: 80x24
Message: Advanced graphics data unavailable in console. Try -G --display
Audio:
Device-1: rk3568-dw-hdmi driver: dwhdmi_rockchip
Device-2: simple-audio-card driver: asoc_simple_card
Device-3: simple-audio-card driver: N/A
Device-4: simple-audio-card driver: asoc_simple_card
Sound Server: ALSA v: k5.10.66
Network:
Device-1: Realtek RTL8125 2.5GbE driver: r8125
IF: eth1 state: down mac: e2:1d:62:a1:1a:ca
Device-2: Realtek RTL8125 2.5GbE driver: r8125
IF: eth1 state: down mac: e2:1d:62:a1:1a:ca
Device-3: rk3568-gmac driver: rk_gmac_dwmac
IF-ID-1: eth0 state: up speed: 1000 Mbps duplex: full
mac: de:1d:62:a1:1a:ca
IF-ID-2: eth2 state: down mac: 12:bf:2b:d6:4b:e0
Drives:
Local Storage: total: 274.88 GiB used: 1012.3 MiB (0.4%)
ID-1: /dev/mmcblk0 model: SD16G size: 29.12 GiB
ID-2: /dev/mmcblk2 model: 8GTF4R size: 7.28 GiB
ID-3: /dev/nvme0n1 vendor: Apacer model: AS2280P4 256GB size: 238.47 GiB
Partition:
ID-1: / size: 26.48 GiB used: 1012.3 MiB (3.7%) fs: overlay
source: ERR-102
Sensors:
System Temperatures: cpu: 46.1 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 130 Uptime: 7m Memory: 1.92 GiB used: 211.4 MiB (10.8%)
Init: systemd Shell: bash inxi: 3.0.38 Работает только порт eth0 WAN, а порты eth1/eth2 2.5GbE отключены и вообще не настроены. Похоже, что FriendlyElec в основном фокусируется на образе FriendlyWrt, и нам сказали, что оптимизация еще не была реализована на FriendlyCore, поэтому большинству людей, вероятно, следует использовать вместо него FriendlyWrt, так как будет проще настроить параметры сети и маршрутизатора. Мы видим, что SSD Apacer AS2280P4 определяется, и оказывается, что он не отформатирован из коробки, поэтому мы просто отформатировали его с помощью mkfs.ext4.
Сравнительный анализ NanoPi R5S
Давайте запустим SBC Bench на маршрутизаторе, чтобы протестировать ЦП и, возможно, найти некоторые проблемы:
$ sudo /bin/bash ./sbc-bench.sh -c
[sudo] password for pi:
WARNING: dmesg output does not contain early boot messages which
help in identifying hardware details.
It is recommended to reboot now and then execute the benchmarks.
Press [ctrl]-[c] to stop or [enter] to continue.
Average load and/or CPU utilization too high (too much background activity). Waiting...
Too busy for benchmarking: 07:21:06 up 3 min, 1 user, load average: 0.41, 0.27, 0.11, cpu: 3%
Too busy for benchmarking: 07:21:11 up 3 min, 1 user, load average: 0.38, 0.26, 0.11, cpu: 1%
Too busy for benchmarking: 07:21:16 up 3 min, 1 user, load average: 0.35, 0.26, 0.11, cpu: 1%
Too busy for benchmarking: 07:21:21 up 3 min, 1 user, load average: 0.32, 0.25, 0.11, cpu: 1%
Too busy for benchmarking: 07:21:26 up 3 min, 1 user, load average: 0.29, 0.25, 0.11, cpu: 1%
Too busy for benchmarking: 07:21:31 up 3 min, 1 user, load average: 0.27, 0.24, 0.10, cpu: 1%
sbc-bench v0.9.7
Installing needed tools. This may take some time. Done.
Checking cpufreq OPP. Done (results will be available in 20-28 minutes).
Executing tinymembench. Done.
Executing RAM latency tester. Done.
Executing OpenSSL benchmark. Done.
Executing 7-zip benchmark. Done.
Executing cpuminer. 5 more minutes to wait. Done.
Checking cpufreq OPP. Done (23 minutes elapsed).
Memory performance:
memcpy: 2800.5 MB/s
memset: 6191.5 MB/s (0.2%)
Cpuminer total scores (5 minutes execution): 6.87,6.86,6.85,6.84,6.83,6.82,6.79 kH/s
7-zip total scores (3 consecutive runs): 4756,4768,4727
OpenSSL results:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-128-cbc 173609.37k 509936.75k 972013.31k 1264387.07k 1383497.73k 1392645.46k
aes-128-cbc 175451.26k 506569.66k 973690.71k 1264628.74k 1382845.10k 1393180.67k
aes-192-cbc 166539.51k 448796.48k 790104.58k 970846.55k 1040621.57k 1046462.46k
aes-192-cbc 168407.31k 451709.25k 792148.91k 970579.63k 1041061.21k 1046375.08k
aes-256-cbc 159430.38k 412822.74k 676804.10k 809129.64k 857347.41k 861137.58k
aes-256-cbc 162313.43k 412763.39k 677746.94k 809317.38k 857642.33k 861334.19k
Unable to upload full test results. Please copy&paste the below stuff to pastebin.com and
provide the URL. Check the output for throttling and swapping please.Мы запустили его почти сразу после загрузки, поэтому вывод dmesg должен быть полным (см. загрузку ранее в этом предварительном просмотре/обзоре), но в сценарии отсутствует некоторая информация из него. Полный вывод скрипта sbc-bench.sh можно найти на pastebin, и мы заметно видим, что объявленная частота «1992» МГц протестирована как 1845 МГц, поэтому здесь возможна некоторая оптимизация.
7zip по-прежнему быстрее, чем на маршрутизаторе NanoPi R2S (3871), или примерно на 23% быстрее, в то время как AES-256-CBC 16 КБ примерно на 22% быстрее ( 704 872,45 против 861 334,19 кГц/с).
Тестирование NVMe
Мы тестировали NVMe SSD три раза с iozone 3, один раз с файлом размером 100 МБ:
pi@FriendlyELEC:/media/nvme0n1$ sudo iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Iozone: Performance Test of File I/O
Version $Revision: 3.489 $
Compiled for 64 bit mode.
Build: linux
Include fsync in write timing
O_DIRECT feature enabled
Auto Mode
File size set to 102400 kB
Record Size 4 kB
Record Size 16 kB
Record Size 512 kB
Record Size 1024 kB
Record Size 16384 kB
Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
102400 4 34994 53668 30431 30385 30136 59719
102400 16 102031 130543 80174 80125 79796 133162
102400 512 300692 296328 276975 291837 276681 313464
102400 1024 309822 340026 308900 326826 306102 339059
102400 16384 357975 392544 369753 391219 370336 390004
iozone test complete.затем файл размером 500 МБ:
pi@FriendlyELEC:/media/nvme0n1$ sudo iozone -e -I -a -s 500M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
512000 4 35308 62195 30436 30380 30251 61600
512000 16 101504 134916 80454 80449 79642 133631
512000 512 293784 308843 284081 284902 281025 306749
512000 1024 326784 333909 318075 321837 315874 333259
512000 16384 378436 383013 381319 383621 382224 381967 и, наконец, файл размером 1 ГБ:
pi@FriendlyELEC:/media/nvme0n1$ sudo iozone -e -I -a -s 1000M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
random random bkwd record stride
kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread
1024000 4 35105 58082 30395 30447 27458 60895
1024000 16 102421 135279 80210 80314 74596 133579
1024000 512 300759 314704 282743 283883 277911 313413
1024000 1024 329840 337468 318228 319091 317641 337714
1024000 16384 383289 385247 382642 382850 382870 381344 Результаты более или менее согласуются во всех трех тестах без значительных изменений, и в последнем мы получили около 380 МБ/с для чтения и записи, что значительно ниже заявленной скорости записи/чтения SSD и результатов для ODROID-M1, но это из-за интерфейса PCIe 2.0 x1, используемого в этой конструкции, вместо интерфейса PCIe Gen 3.0 x2, используемого в плате Hardkernel.
Вот вывод lspci для справки:
pi@FriendlyELEC:/media/nvme0n1$ sudo lspci -v
0002:21:00.0 Non-Volatile memory controller: Phison Electronics Corporation Device 5013 (rev 01) (prog-if 02 [NVM Express])
Subsystem: Phison Electronics Corporation Device 5013
Flags: bus master, fast devsel, latency 0, IRQ 87
Memory at 380900000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [80] Express Endpoint, MSI 00
Capabilities: [d0] MSI-X: Enable+ Count=9 Masked-
Capabilities: [e0] MSI: Enable- Count=1/8 Maskable+ 64bit+
Capabilities: [f8] Power Management version 3
Capabilities: [100] Latency Tolerance Reporting
Capabilities: [110] L1 PM Substates
Capabilities: [200] Advanced Error Reporting
Capabilities: [300] Secondary PCI Express
Kernel driver in use: nvmeКонфигурация интерфейсов 2.5GbE и тестирование
Поскольку из коробки настроен только интерфейс eth0 Gigabit Ethernet «WAN», нам нужно настроить два порта 2.5GbE вручную. Мы использовали тот же тестовый стенд, что и в первой части обзора с FriendlyWrt, а именно ноутбук Ubuntu 20.04 с USB-ключом Realtek RTL8156BG USB 3.0 на 2,5GbE, подключенный к eth1, и мини-ПК UP Xtreme i11, подключенный к eth2. Вместо использования мостового интерфейса, как в FriendlyWrt, мы настроили две разные подсети: 192.168.2.0 для eth1 и 192.168.3.0 для eth2.
Давайте создадим два новых файла в /etc/network/interfaces.d/:
- eth1
auto eth1
iface eth1 inet static
address 192.168.2.1
network 192.168.2.0
netmask 255.255.255.0
broadcast 192.168.2.255- eth2
auto eth2
iface eth2 inet static
address 192.168.3.1
network 192.168.3.0
netmask 255.255.255.0
broadcast 192.168.3.255Теперь установите DHCP-сервер
sudo apt install isc-dhcp-server
отредактируем файл /etc/dhcp/dhcpd.conf с двумя нашими подсетями:
subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.100 192.168.2.200;
option routers 192.168.2.1;
}
subnet 192.168.3.0 netmask 255.255.255.0 {
range 192.168.3.100 192.168.3.200;
option routers 192.168.3.1;
}… перед перезапуском DHCP-сервера:
sudo systemctl restart isc-dhcp-serverНа этом этапе ноутбук и мини-ПК должны получить свой IP-адрес от NanoPi R5S в соответствующих подсетях. Мы можем начать тестирование интерфейсов:
Загрузка iperf3 (Rx с точки зрения R5S) с использованием eth1, подключенного к ноутбуку:
$ iperf3 -t 60 -c 192.168.2.1 -i 10
Connecting to host 192.168.2.1, port 5201
[ 5] local 192.168.2.130 port 59822 connected to 192.168.2.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-10.00 sec 2.28 GBytes 1.96 Gbits/sec 42 1.41 MBytes
[ 5] 10.00-20.00 sec 2.02 GBytes 1.74 Gbits/sec 0 1.61 MBytes
[ 5] 20.00-30.00 sec 1.72 GBytes 1.48 Gbits/sec 0 1.62 MBytes
[ 5] 30.00-40.00 sec 1.87 GBytes 1.61 Gbits/sec 0 1.62 MBytes
[ 5] 40.00-50.00 sec 1.89 GBytes 1.62 Gbits/sec 0 1.70 MBytes
[ 5] 50.00-60.00 sec 2.06 GBytes 1.77 Gbits/sec 21 1.66 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 11.8 GBytes 1.70 Gbits/sec 63 sender
[ 5] 0.00-60.04 sec 11.8 GBytes 1.69 Gbits/sec receiver
iperf Done.Результат немного медленнее, чем у нас (1,85 Гбит/с) в OpenWrt, и есть повторные передачи. Мы также мониторили систему с помощью sbc-bench.sh во время переноса:
pi@FriendlyELEC:~$ sudo ./sbc-bench.sh -m
Rockchip RK3568 (35682000), Kernel: aarch64, Userland: arm64
CPU sysfs topology (clusters, cpufreq members, clockspeeds)
cpufreq min max
CPU cluster policy speed speed core type
0 0 0 408 1992 Cortex-A55 / r2p0
1 0 0 408 1992 Cortex-A55 / r2p0
2 0 0 408 1992 Cortex-A55 / r2p0
3 0 0 408 1992 Cortex-A55 / r2p0
Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal)
Time CPU load %cpu %sys %usr %nice %io %irq Temp
03:38:07: 1416MHz 0.32 5% 3% 1% 0% 0% 0% 55.0°C
03:38:12: 1992MHz 0.37 35% 15% 0% 0% 0% 20% 56.7°C
03:38:17: 1992MHz 0.42 43% 18% 0% 0% 0% 24% 58.3°C
03:38:23: 1992MHz 0.47 42% 17% 0% 0% 0% 23% 57.2°C
03:38:28: 1992MHz 0.51 29% 10% 0% 0% 0% 18% 56.7°C
03:38:33: 1992MHz 0.55 29% 10% 0% 0% 0% 18% 57.2°C
03:38:38: 1992MHz 0.59 26% 8% 0% 0% 0% 17% 56.7°C
03:38:43: 1992MHz 0.62 33% 12% 0% 0% 0% 20% 57.2°C
03:38:48: 1992MHz 0.65 30% 11% 0% 0% 0% 18% 57.2°C
03:38:53: 1992MHz 0.68 26% 7% 0% 0% 0% 17% 57.2°C
03:38:58: 1992MHz 0.79 37% 15% 0% 0% 0% 21% 57.2°C
03:39:03: 1992MHz 0.80 34% 13% 0% 0% 0% 20% 57.2°C
03:39:09: 1104MHz 0.82 34% 14% 0% 0% 0% 19% 55.0°C
Во время теста система работает на максимальной заявленной частоте, и мы не видим здесь каких-либо явных узких мест.
Мы также можем проверить некоторую информацию и статистику с помощью ethtool:
pi@FriendlyELEC:~$ sudo ethtool -i eth1
driver: r8125
version: 9.008.00-NAPI
firmware-version:
expansion-rom-version:
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no
pi@FriendlyELEC:~$ sudo ethtool -S eth1
NIC statistics:
tx_packets: 451228
rx_packets: 9569147
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 9569102
broadcast: 45
multicast: 0
tx_aborted: 0
tx_underrun: 0
tx_octets: 31676089
rx_octets: 14506385933
rx_multicast64: 0
tx_unicast64: 451214
tx_broadcast64: 2
tx_multicast64: 12
tx_pause_on: 570
tx_pause_off: 570
tx_pause_all: 1140
tx_deferred: 0
tx_late_collision: 0
tx_all_collision: 0
tx_aborted32: 0
align_errors32: 0
rx_frame_too_long: 0
rx_runt: 0
rx_pause_on: 0
rx_pause_off: 0
rx_pause_all: 0
rx_unknown_opcode: 0
rx_mac_error: 0
tx_underrun32: 0
rx_mac_missed: 31
rx_tcam_dropped: 0
tdu: 0
rdu: 570Мы получили rx_mac_missed.
Давайте сделаем это в обратном порядке (Tx):
$ iperf3 -t 60 -c 192.168.2.1 -i 10 -R
Connecting to host 192.168.2.1, port 5201
Reverse mode, remote host 192.168.2.1 is sending
[ 5] local 192.168.2.130 port 59826 connected to 192.168.2.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.75 GBytes 1.50 Gbits/sec
[ 5] 10.00-20.00 sec 1.95 GBytes 1.67 Gbits/sec
[ 5] 20.00-30.00 sec 1.95 GBytes 1.67 Gbits/sec
[ 5] 30.00-40.00 sec 1.95 GBytes 1.67 Gbits/sec
[ 5] 40.00-50.00 sec 1.94 GBytes 1.67 Gbits/sec
[ 5] 50.00-60.00 sec 1.94 GBytes 1.67 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.04 sec 11.5 GBytes 1.64 Gbits/sec 0 sender
[ 5] 0.00-60.00 sec 11.5 GBytes 1.64 Gbits/sec receiver
iperf Done.Выглядит намного лучше, чем в OpenWrt (1,12 Гбит/с).
pi@FriendlyELEC:~$ sudo ./sbc-bench.sh -m
Rockchip RK3568 (35682000), Kernel: aarch64, Userland: arm64
CPU sysfs topology (clusters, cpufreq members, clockspeeds)
cpufreq min max
CPU cluster policy speed speed core type
0 0 0 408 1992 Cortex-A55 / r2p0
1 0 0 408 1992 Cortex-A55 / r2p0
2 0 0 408 1992 Cortex-A55 / r2p0
3 0 0 408 1992 Cortex-A55 / r2p0
Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal)
Time CPU load %cpu %sys %usr %nice %io %irq Temp
03:56:48: 1416MHz 0.00 2% 1% 0% 0% 0% 1% 55.0°C
03:56:53: 1992MHz 0.00 23% 17% 0% 0% 0% 4% 57.2°C
03:56:58: 1992MHz 0.30 31% 27% 0% 0% 0% 3% 57.2°C
03:57:03: 1992MHz 0.36 31% 27% 0% 0% 0% 3% 57.8°C
03:57:08: 1992MHz 0.41 31% 27% 0% 0% 0% 3% 57.8°C
03:57:13: 1992MHz 0.46 31% 27% 0% 0% 0% 3% 57.8°C
03:57:19: 1992MHz 0.50 31% 27% 0% 0% 0% 3% 57.8°C
03:57:24: 1992MHz 0.62 31% 27% 0% 0% 0% 3% 57.8°C
03:57:29: 1992MHz 0.65 31% 28% 0% 0% 0% 2% 58.3°C
03:57:34: 1992MHz 0.68 31% 27% 0% 0% 0% 2% 58.3°C
03:57:39: 1992MHz 0.71 31% 27% 0% 0% 0% 2% 57.8°C
03:57:44: 1992MHz 0.73 31% 28% 0% 0% 0% 3% 58.3°C
03:57:49: 1104MHz 0.75 26% 22% 0% 0% 0% 3% 55.0°CПроцент IRQ намного ниже, но мы полагаем, что это нормально для Tx.
Переключимся на eth2, подключенный к UP Xtreme i11:
devkit@UPX-i11:~$ iperf3 -t 60 -c 192.168.3.1 -i10
Connecting to host 192.168.3.1, port 5201
[ 5] local 192.168.3.100 port 37794 connected to 192.168.3.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-10.00 sec 2.73 GBytes 2.35 Gbits/sec 0 1.81 MBytes
[ 5] 10.00-20.00 sec 2.73 GBytes 2.35 Gbits/sec 0 1.81 MBytes
[ 5] 20.00-30.00 sec 2.73 GBytes 2.35 Gbits/sec 0 1.81 MBytes
[ 5] 30.00-40.00 sec 2.73 GBytes 2.34 Gbits/sec 0 2.90 MBytes
[ 5] 40.00-50.00 sec 2.73 GBytes 2.35 Gbits/sec 0 4.37 MBytes
[ 5] 50.00-60.00 sec 2.73 GBytes 2.35 Gbits/sec 0 4.37 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 16.4 GBytes 2.35 Gbits/sec 0 sender
[ 5] 0.00-60.00 sec 16.4 GBytes 2.35 Gbits/sec receiver
iperf Done.Круто! Это первый раз, когда мы получаем приличную передачу 2,35 Гбит/с, так что есть надежда!
pi@FriendlyELEC:~$ sudo ./sbc-bench.sh -m
Rockchip RK3568 (35682000), Kernel: aarch64, Userland: arm64
CPU sysfs topology (clusters, cpufreq members, clockspeeds)
cpufreq min max
CPU cluster policy speed speed core type
0 0 0 408 1992 Cortex-A55 / r2p0
1 0 0 408 1992 Cortex-A55 / r2p0
2 0 0 408 1992 Cortex-A55 / r2p0
3 0 0 408 1992 Cortex-A55 / r2p0
Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal)
Time CPU load %cpu %sys %usr %nice %io %irq Temp
04:11:00: 1104MHz 0.00 2% 1% 0% 0% 0% 0% 53.8°C
04:11:05: 1992MHz 0.08 34% 12% 0% 0% 0% 21% 56.1°C
04:11:10: 1992MHz 0.23 40% 14% 0% 0% 0% 25% 56.1°C
04:11:15: 1992MHz 0.30 40% 15% 0% 0% 0% 25% 57.2°C
04:11:20: 1992MHz 0.43 40% 14% 0% 0% 0% 25% 57.2°C
04:11:25: 1992MHz 0.48 41% 15% 0% 0% 0% 25% 56.7°C
04:11:30: 1992MHz 0.60 40% 15% 0% 0% 0% 25% 57.2°C
04:11:36: 1992MHz 0.71 40% 14% 0% 0% 0% 25% 57.2°C
04:11:41: 1992MHz 0.74 41% 15% 0% 0% 0% 25% 57.2°C
04:11:46: 1992MHz 0.84 40% 14% 0% 0% 0% 25% 56.7°C
04:11:51: 1992MHz 0.85 40% 14% 0% 0% 0% 25% 57.2°C
04:11:56: 1992MHz 0.86 40% 14% 0% 0% 0% 25% 56.7°C
04:12:01: 1416MHz 0.87 35% 13% 0% 0% 0% 21% 53.8°CЕсли мы не ошибаемся, 25% IRQ должны означать, что ядро полностью используется для их обработки.
Попробуем Тх:
devkit@UPX-i11:~$ iperf3 -t 60 -c 192.168.3.1 -i 10 -R
Connecting to host 192.168.3.1, port 5201
Reverse mode, remote host 192.168.3.1 is sending
[ 5] local 192.168.3.100 port 37800 connected to 192.168.3.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.92 GBytes 1.65 Gbits/sec
[ 5] 10.00-20.00 sec 1.84 GBytes 1.58 Gbits/sec
[ 5] 20.00-30.00 sec 1.84 GBytes 1.58 Gbits/sec
[ 5] 30.00-40.00 sec 1.84 GBytes 1.58 Gbits/sec
[ 5] 40.00-50.00 sec 1.84 GBytes 1.58 Gbits/sec
[ 5] 50.00-60.00 sec 1.84 GBytes 1.58 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.01 sec 11.1 GBytes 1.59 Gbits/sec 0 sender
[ 5] 0.00-60.00 sec 11.1 GBytes 1.59 Gbits/sec receiver
iperf Done.1,59 Гбит/с. Не идеально, но все же лучше, чем в OpenWrt.
pi@FriendlyELEC:~$ sudo ./sbc-bench.sh -m
Rockchip RK3568 (35682000), Kernel: aarch64, Userland: arm64
CPU sysfs topology (clusters, cpufreq members, clockspeeds)
cpufreq min max
CPU cluster policy speed speed core type
0 0 0 408 1992 Cortex-A55 / r2p0
1 0 0 408 1992 Cortex-A55 / r2p0
2 0 0 408 1992 Cortex-A55 / r2p0
3 0 0 408 1992 Cortex-A55 / r2p0
Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal)
Time CPU load %cpu %sys %usr %nice %io %irq Temp
04:13:37: 1104MHz 0.31 3% 1% 0% 0% 0% 1% 53.8°C
04:13:42: 1992MHz 0.37 25% 22% 0% 0% 0% 3% 56.1°C
04:13:47: 1992MHz 0.42 31% 27% 0% 0% 0% 3% 56.1°C
04:13:52: 1992MHz 0.47 30% 25% 0% 0% 0% 4% 56.1°C
04:13:58: 1992MHz 0.51 30% 25% 0% 0% 0% 4% 56.1°C
04:14:03: 1992MHz 0.55 30% 25% 0% 0% 0% 4% 56.1°C
04:14:08: 1992MHz 0.58 30% 25% 0% 0% 0% 4% 56.1°C
04:14:13: 1992MHz 0.62 30% 25% 0% 0% 0% 5% 56.1°C
04:14:18: 1992MHz 0.65 30% 25% 0% 0% 0% 5% 56.1°C
04:14:23: 1992MHz 0.68 30% 25% 0% 0% 0% 4% 56.1°C
04:14:28: 1992MHz 0.70 30% 25% 0% 0% 0% 4% 56.1°C
04:14:34: 1992MHz 0.82 30% 26% 0% 0% 0% 4% 56.1°C
04:14:39: 1104MHz 0.76 26% 22% 0% 0% 0% 3% 53.8°C
^CОпять же, ЦП работает на полной скорости и далеко не на 100% загружен, поэтому узкие места должны быть где-то еще. Мы снова можем проверить информацию и статистику eth2 с помощью ethtool.
$ sudo ethtool -i eth2
driver: r8125
version: 9.008.00-NAPI
firmware-version:
expansion-rom-version:
bus-info: 0001:11:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: nosudo ethtool -S eth2
NIC statistics:
tx_packets: 8506609
rx_packets: 12553353
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 12553209
broadcast: 144
multicast: 0
tx_aborted: 0
tx_underrun: 0
tx_octets: 12543719502
rx_octets: 18471602900
rx_multicast64: 0
tx_unicast64: 8503557
tx_broadcast64: 3035
tx_multicast64: 17
tx_pause_on: 35
tx_pause_off: 35
tx_pause_all: 70
tx_deferred: 0
tx_late_collision: 0
tx_all_collision: 0
tx_aborted32: 0
align_errors32: 0
rx_frame_too_long: 0
rx_runt: 0
rx_pause_on: 0
rx_pause_off: 0
rx_pause_all: 0
rx_unknown_opcode: 0
rx_mac_error: 0
tx_underrun32: 0
rx_mac_missed: 335
rx_tcam_dropped: 0
tdu: 0
rdu: 35У нас есть еще rx_mac_missed. Таким образом, будут некоторые настройки для повышения производительности, но, исходя из нашего опыта с RTL8156B, настройка параметров действительно сложна, и опытные люди, похоже, не согласны с тем, что нужно настраивать, речь идет об инженерах Realtek, работающих над драйверами RTL8156/8125, в сравнении с обычными читателями, которые являются экспертами в области сетей.
Настройка NAT между двумя интерфейсами 2.5GbE
Поскольку интерфейсы 2.5GbE работают не оптимально с iperf3, мы не стали тестировать производительность маршрутизатора в FriendlyWrt, но несколько человек все же спросили. Итак, мы покажем, как мы настроили NAT в Ubuntu 20.04, и, как и раньше, проверим производительность NAT, имея в виду, что через несколько недель или месяцев она, безусловно, улучшится.
Нам нужно включить переадресацию IP и NAT. Мы использовали инструкции, адаптированные из поста на networkreverse .
Отредактируйте /etc/sysctl.conf , чтобы включить переадресацию IP (раскомментируйте следующую строку):
net.ipv4.ip_forward=1Примените изменения:
sudo sysctl -pТеперь включим NAT:
sudo iptables ! -o lo -t nat -A POSTROUTING -j MASQUERADE
Теперь мы можем пропинговать UP Xtreme i11 в подсети 192.168.3.0 с нашего ноутбука в подсети 192.168.2.0:
jaufranc@cnx-laptop-4:~$ ping 192.168.3.100
PING 192.168.3.100 (192.168.3.100) 56(84) bytes of data.
64 bytes from 192.168.3.100: icmp_seq=1 ttl=63 time=0.690 ms
64 bytes from 192.168.3.100: icmp_seq=2 ttl=63 time=0.764 msЕсли вы хотите сделать изменения постоянными:
sudo apt install iptables-persistent
sudo sh -c 'iptables-save > /etc/iptables/rules.v4'Давайте попробуем iperf3 между UP Xtreme i11 и нашим ноутбуком с маршрутизацией данных через маршрутизатор NanoPi R5S.
jaufranc@cnx-laptop-4:~$ iperf3 -t 60 -c 192.168.3.100 -i 10
Connecting to host 192.168.3.100, port 5201
[ 5] local 192.168.2.130 port 59430 connected to 192.168.3.100 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-10.00 sec 914 MBytes 767 Mbits/sec 355 1011 KBytes
[ 5] 10.00-20.00 sec 912 MBytes 765 Mbits/sec 324 1.23 MBytes
[ 5] 20.00-30.00 sec 917 MBytes 769 Mbits/sec 124 1.09 MBytes
[ 5] 30.00-40.00 sec 915 MBytes 767 Mbits/sec 150 942 KBytes
[ 5] 40.00-50.00 sec 915 MBytes 767 Mbits/sec 78 1.22 MBytes
[ 5] 50.00-60.00 sec 919 MBytes 771 Mbits/sec 64 1.03 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.00 sec 5.36 GBytes 768 Mbits/sec 1095 sender
[ 5] 0.00-60.06 sec 5.36 GBytes 767 Mbits/sec receiver
iperf Done.
jaufranc@cnx-laptop-4:~$ iperf3 -t 60 -c 192.168.3.100 -i 10 -R
Connecting to host 192.168.3.100, port 5201
Reverse mode, remote host 192.168.3.100 is sending
[ 5] local 192.168.2.130 port 59434 connected to 192.168.3.100 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.09 GBytes 935 Mbits/sec
[ 5] 10.00-20.00 sec 1.09 GBytes 938 Mbits/sec
[ 5] 20.00-30.00 sec 1.09 GBytes 938 Mbits/sec
[ 5] 30.00-40.00 sec 1.09 GBytes 938 Mbits/sec
[ 5] 40.00-50.00 sec 1.09 GBytes 939 Mbits/sec
[ 5] 50.00-60.00 sec 1.09 GBytes 937 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-60.05 sec 6.55 GBytes 937 Mbits/sec 973 sender
[ 5] 0.00-60.00 sec 6.55 GBytes 937 Mbits/sec receiver
iperf Done.768 Мбит/с в одну сторону и 937 Мбит/с в другую.
pi@FriendlyELEC:~$ sudo ./sbc-bench.sh -m
Rockchip RK3568 (35682000), Kernel: aarch64, Userland: arm64
CPU sysfs topology (clusters, cpufreq members, clockspeeds)
cpufreq min max
CPU cluster policy speed speed core type
0 0 0 408 1992 Cortex-A55 / r2p0
1 0 0 408 1992 Cortex-A55 / r2p0
2 0 0 408 1992 Cortex-A55 / r2p0
3 0 0 408 1992 Cortex-A55 / r2p0
Thermal source: /sys/devices/virtual/thermal/thermal_zone0/ (soc-thermal)
Time CPU load %cpu %sys %usr %nice %io %irq Temp
05:00:01: 1608MHz 0.16 4% 3% 0% 0% 0% 1% 52.5°C
05:00:06: 1992MHz 0.15 21% 0% 0% 0% 1% 19% 53.8°C
05:00:11: 1992MHz 0.22 25% 0% 0% 0% 0% 25% 53.8°C
05:00:16: 1992MHz 0.28 25% 0% 0% 0% 0% 25% 53.8°C
05:00:21: 1992MHz 0.34 25% 0% 0% 0% 0% 25% 53.8°C
05:00:26: 1992MHz 0.39 25% 0% 0% 0% 0% 25% 53.8°C
05:00:31: 1992MHz 0.44 25% 0% 0% 0% 0% 25% 54.4°C
05:00:36: 1992MHz 0.49 25% 0% 0% 0% 0% 25% 53.8°C
05:00:41: 1992MHz 0.53 25% 0% 0% 0% 0% 25% 53.8°C
05:00:47: 1992MHz 0.57 25% 0% 0% 0% 0% 25% 53.8°C
05:00:52: 1992MHz 0.84 25% 0% 0% 0% 0% 24% 53.8°C
05:00:57: 1992MHz 0.94 25% 0% 0% 0% 0% 25% 54.4°C
05:01:02: 1104MHz 0.86 24% 0% 0% 0% 0% 24% 52.5°C
05:01:07: 1992MHz 0.79 16% 0% 0% 0% 0% 15% 54.4°C
05:01:12: 1992MHz 0.81 25% 0% 0% 0% 0% 25% 54.4°C
05:01:17: 1992MHz 0.83 25% 0% 0% 0% 0% 25% 54.4°C
05:01:22: 1992MHz 0.84 25% 0% 0% 0% 0% 24% 54.4°C
05:01:27: 1992MHz 0.85 25% 0% 0% 0% 0% 25% 55.0°C
05:01:33: 1992MHz 0.87 25% 0% 0% 0% 0% 25% 54.4°C
05:01:38: 1992MHz 0.88 25% 0% 0% 0% 0% 25% 54.4°C
05:01:43: 1992MHz 0.89 25% 0% 0% 0% 0% 25% 55.0°C
05:01:48: 1992MHz 0.90 25% 0% 0% 0% 0% 25% 54.4°C
05:01:53: 1992MHz 0.90 25% 0% 0% 0% 0% 25% 54.4°C
05:01:58: 1992MHz 0.91 25% 0% 0% 0% 0% 25% 54.4°C
05:02:03: 1992MHz 0.92 25% 0% 0% 0% 0% 25% 54.4°CМониторинг с помощью sbc-bench.sh показывает, что процессор работает на частоте 1992 МГц (или 1845 МГц на самом деле), и снова 25% IRQ должны означать, что одно ядро полностью используется для обработки IRQ.
Команда mpstat показывает, что это должно обрабатываться ядром #0.
$ mpstat -P ALL -I SUM
Linux 5.10.66 (FriendlyELEC) 06/05/22 _aarch64_ (4 CPU)
09:52:53 CPU intr/s
09:52:53 all 226.34
09:52:53 0 174.51
09:52:53 1 20.32
09:52:53 2 21.34
09:52:53 3 10.16И это можно подтвердить, используя top и htop.
На сегодня, пожалуй, остановимся на этом. Оптимизация должна включать в себя изменение прошивки, чтобы ядра Rockchip работали на частоте 1992 МГц, и настройку различных параметров, связанных с настройками PCIe и Ethernet, с большинством которых мы не знакомы (пока). Мы также проверим энергопотребление, как только получим настенный измеритель мощности, который заказали несколько дней назад.
Нам хотелось бы поблагодарить FriendlyElec за отправку образцов мини-маршрутизатора NanoPi R5S для обзора. Роутер в металлическом корпусе можно купить на сайте FriendlyElec за 75 долларов, а плату можно купить всего за 59 долларов. Маршрутизатор также можно найти на Aliexpress у нескольких продавцов, некоторые из которых также продают версию с 4 ГБ ОЗУ, что странно, поскольку в настоящее время FriendlyElec продает только модель с 2 ГБ ОЗУ.
Выражаем свою благодарность источнику из которого взята и переведена статья, сайту cnx-software.com.
Оригинал статьи вы можете прочитать здесь.