Обзор мини-ПК и роутера NanoPi R6S на RK3588S – Часть 2: Ubuntu 22.04

NanoPi R6S представляет собой одновременно мини-ПК и роутер на базе процессора Rockchip RK3588S . Образцы были получены в ноябре, и начат обзор NanoPi R6S с OpenWrt/FriendlyWrt , включая быструю проверку интерфейсов 2.5GbE и маршрутизации через iperf3, где система показала себя хорошо. Однако использование платформы с восьмиядерным процессором Cortex-A76/A55 и 8 ГБ ОЗУ исключительно как роутера OpenWrt выглядит расточительным, поэтому для дальнейшего тестирования была выбрана более универсальная ОС – Ubuntu 22.04.

Трудности при установке Ubuntu 22.04 на NanoPi R6S

FriendlyELEC предоставляет различные образы на Wiki , включая загрузку с SD-карты, установку с MicroSD во флеш-память eMMC (образы eFlasher) или прошивку через USB с помощью инструментов Windows. Образы eFlasher предпочтительны, так как ОС запускается с внутренней памяти eMMC и не требуются специальные инструменты. После успешного использования образа FriendlyWrt eFlasher ожидалось, что переход на образ Ubuntu 22.04 eFlasher пройдет легко.

Но возникла проблема: утилита eFlasher запускалась, но процесс обновления проходил слишком быстро. Попытки использовать другие образы eFlasher завершались ошибкой, тогда как возврат к FriendlyWrt всегда работал. Тестирование загрузки с образа MicroSD и Windows USB utility также не позволило успешно установить Ubuntu 22.04 на NanoPi R6S.

После подключения отладочной платы UART к NanoPi R6S в логах загрузки проблемных образов наблюдались ошибки разделов и файловой системы. Сообщение в FriendlyElec о корректной работе FriendlyWrt на двух образцах не помогло; анализ логов и проблемы с USB utility навели их на подозрения о неисправности eMMC, и была прислана новая плата с предустановленной Ubuntu 22.04, которая, однако, также поставлялась с образом FriendlyWrt.

Повторные попытки обновить плату привели к той же ошибке… Различные образы Debian и Ubuntu не работали, тогда как FriendlyWrt запускался без проблем… Ключевой упущенный ранее момент: для записи использовался USBImager – легковесная утилита, применяемая с 2020 года без нареканий, которая и оказалась причиной. FriendlyElec распространяет образы, сжатые GZIP. Распаковка образа через gzip перед записью через USBImager позволила eFlasher успешно установить Ubuntu 22.04 или Debian 11, и ОС загрузилась с eMMC.

NanoPi R6S Ubuntu 22.04

Хотя USBImager должен поддерживать запись сжатых образов, создание issue на GitLab и пояснение разработчика указали на ограничение формата GZIP ( RFC 1952 ): размер файла ограничен 4 ГБ из-за 32-битного поля хранения. Действительно, при открытии gz-файла в Ubuntu отображался некорректный размер 3.5 ГБ вместо 7.8 ГБ… gzip (в основном) игнорирует заявленный размер и распаковывает весь файл для определения реального размера. Этим объясняется работоспособность меньшего по размеру образа FriendlyWrt и сбой с десктопными ОС… Проблема в USBImager пока не решена, поэтому важно распаковывать gz-файлы перед записью, а производителям плат стоит избегать сжатия gzip в пользу современных форматов.

На выяснение ушло более 10 часов, но теперь можно продолжить обзор…

Информация о системе Ubuntu 22.04

Основные характеристики системы:

Ubuntu 22.04.2 с ядром Linux 5.10.110, ~8 ГБ ОЗУ и корневым разделом на 25 ГБ

Желающие могут ознакомиться с логом загрузки Linux на pastebin .

Тесты производительности NanoPi R6S в Ubuntu 22.04

Запуск бенчмарков, начиная с sbc-bench.sh:

Троттлинг не наблюдалось, максимальная температура составила 64.7°C при нагрузке CPU miner в помещении с температурой ~27°C, что подтверждает эффективность пассивного охлаждения. Менее впечатляющи результаты 7-zip: ~14,500 против 16,200–16,400 MIPS на Khadas Edge2 и Rock 5B . Тактовые частоты ядер Cortex-A76 – 2316 и 2244 МГц (измерено), что не является проблемой; объяснение будет приведено далее.

SBC Bench NanoPi R6S

Остальные результаты схожи с другими платформами на RK3588(S) и значительно выше, чем на Raspberry Pi 4.

Speedometer 2.0 в браузере Chromium показал разочаровывающий результат:

Speedometer 2.0 NanoPi R6S Ubuntu 22.04 Chromium

Показатели стабильны между прогонами; повторный тест позже дал 17.1 запуска в минуту… Speedometer 2.0 NanoPi R6S Ubuntu 22.04 Chromium details

Firefox обычно медленнее в этом тесте, но на NanoPi R6S с Ubuntu 22.04 он показал 41.3 запуска в минуту в Firefox 110.

Speedometer 2.0 NanoPi R6S Ubuntu 22.04 Firefox

Причина, вероятно, в проблемах конфигурации Chromium. На плате Khadas Edge2 с тем же Rockchip RK3588S результаты составили 80.7 в Chromium и 53.12 в Firefox.

Тестирование и бенчмарки накопителей

Производительность eMMC проверена через iozone3:

Довольно высокая: 296 МБ/с последовательное чтение, 200 МБ/с последовательная запись; случайные операции также на уровне.

Для тестирования порта USB 3.0 (5 Гбит/с) подключен контейнер ORICO M234C3-U4 с NVMe SSD :

Скорости ~340 МБ/с чтения и 400+ МБ/с записи соответствуют ожиданиям для порта 5 Гбит/с, хотя чтение можно немного улучшить.

Сетевая производительность (2.5GbE)

Поскольку 2.5GbE уже тестировалась в OpenWrt, в Ubuntu 22.04 проверен только порт WAN через iperf3:

  • Скачивание:

  • Загрузка:

  • Полный дуплекс:

Отличные результаты, за исключением нескольких повторных передач в режиме полного дуплекса.

Режим “review” в SBC Bench

Thomas Kaiser добавил в SBC Bench режим “review” для выявления/исправления типовых проблем и отображения ключевых характеристик железа и ПО:

В логе выше не видно, но предупреждения выделены красным:

SBC Bench Review Mode

В данном случае скрипт переключил режимы управления (governors) CPU, GPU, NPU и ОЗУ с “ondemand” на “performance”. Это обеспечивает максимальную производительность в тестах, но может быть неоптимально для сценариев с ограничением энергопотребления или работы от батареи.

После вывода строк со временем и частотами CPU можно перезапустить тесты. Начнем с 7-zip:

Общий рейтинг MIPS “Total” составил 16385, что соответствует показателям Rock 5B и Edge2. По словам Thomas, причина – в конфигурации ОЗУ, а режим “ondemand” на частоте 528 МГц по умолчанию действительно влияет на производительность 7-zip.

Дополнительная проверка eMMC:

Незначительный прирост скорости.

Тестирование USB-накопителя:

Скорости записи и чтения необъяснимо снизились (результат воспроизводим).

Повторная проверка iperf3 в полном дуплексе на порту WAN:

В первом прогоне не было повторных передач, но во втором появились, как при настройках по умолчанию:

Скорость составила 2.35 Гбит/с в обоих направлениях. Возможно, повезло, или сказалась настройка PCIe ASPM ( Active State Power Management) в “performance”.

Несмотря на фокус Thomas на headless-сценариях, дополнительно запущен Speedometer 2.0 в Firefox для оценки эффекта новых настроек.

Firefox Speedometer 2.0 Performance governor

57 баллов – примерно на 38% выше 41.3 балла при настройках по умолчанию. Теперь результат лучше, чем у Khadas Edge2 (со стандартными настройками). Улучшение наблюдается и в Chromium: 21.8 баллов. Это все еще на 75% медленнее, чем на Edge2, так что чуда не произошло…

Chromium Speedometer 2.0 Performance governor

Режим review также способен выявлять проблемы с накопителями: поддельные SD-карты, изношенные диски и т.д. При тестировании с заведомо поддельной microSD картой она была определена как “Definite counterfeit APPSD”, а скрипт указал на ошибки в dmesg:

Изменения, внесенные режимом review, не сохраняются после перезагрузки, что является правильным поведением.

Аппаратное ускорение 3D-графики на NanoPi R6S

Подтверждена загрузка и работоспособность драйвера Arm Mali:

Сообщение “eglInitialize failed” также наблюдалось на Khadas Edge2, но не помешало запустить glmark2-es2-wayland. Проверка на NanoPi R6S:

NanoPi R6S glmark2-es2-wayland

Работает достаточно хорошо. Вывод в терминале:

4525 баллов на NanoPi R6S против 4005 баллов на Khadas Edge2 . Учтите, что оптимизации SBC bench были активны, а на Edge2 перед запуском графического теста режим управления GPU также был переключен на “performance”.

Установка SuperTuxKart: игра была запущена в оконном режиме, но, вероятно, не использовала GPU:

llvmpipe указывает на программный рендеринг. При переключении на полноэкранный режим 1920×1080 кадровая частота упала до 1-2 кадров/с, что подтвердило отсутствие задействования GPU. SuperTuxKart должен работать с аппаратным ускорением OpenGL ES, но решение проблемы не найдено.

Согласно wiki, ускорение графики включено в Chromium… Проверка через ввод chrome://gpu в адресной строке.

NanoPi R6S Ubuntu 22.04 GPU acceleration Chromium

WebGL и WebGL2 действительно активированы.

Chromium Arm Mali LODX driver

Используется драйвер Arm “Mali-LODX”. Проверка демо WebGL Aquarium.

NanoPi R6S WebGL Aquarium 1000 fish
1000 рыб @ 60 кадров/с

Демо плавно отрисовывает 1000 рыб на 60 кадрах/с и сохраняет приемлемую производительность при 5000 рыб (~30 кадров/с).

NanoPi R6S WebGL Aquarium 5000 fish

5000 рыб @ 31 кадров/сПри увеличении до 10 000 рыб и более появляются артефакты отрисовки (рыбы показываются периодически) и падает кадровая частота. Подтверждено: аппаратное ускорение 3D-графики работает в образе Ubuntu 22.04, включая Chromium.

Воспроизведение видео

В предыдущих обзорах оборудования на Rockchip RK3588(S) под Linux были проблемы с воспроизведением видео, но достигнут прогресс. Во-первых, как видно из скриншота “GPU” Chromium, “Video Decode” активирован, а поддержка аппаратного ускорения заявлена для HEVC, H.264, VP9 до 3840×2160.

Chromium RK3588S Video Acceleration Information

Проверка 4K-видео на 1080p60…

YouTube NanoPi R6S Full HD VP9 hardware video decoding

Воспроизведение без сброса кадров. Как убедиться в использовании аппаратного декодирования? Первый признак – энергопотребление: ~5.4 Вт, тогда как при программном декодировании на других платформах RK3588 оно колебалось между 8 и 10+ Вт.

Wiki также рекомендует использовать fuser во время воспроизведения:

Наличие вывода указывает на аппаратное декодирование VP9. После закрытия вкладки YouTube вывод отсутствует:

Переключение на 4K (в YouTube) при выводе на дисплей 1080p60 также не вызвало проблем.

YouTube NanoPi R6S 4K VP9 hardware video decoding

Уверенность позволила попробовать локальное 8K-видео AV1 через командную строку:

Результат неудовлетворительный: обрывки звука, множество сброшенных кадров, подтормаживающее видео. Проверка традиционного 4K H.264 @ 30 кадров/с:

Проблем нет. Но система не справляется и с 4K H.265 @ 60 кадров/с:

FriendlyElec утверждает, что предустановленный Kodi 19.4 поддерживает аппаратное декодирование. Проверка видео в Kodi.

Kodi 4K H.264 infoKodi 4K H.265 info

Интерфейс информации изменился, но результаты идентичны: H.264 @ 30 кадров/с воспроизводится нормально, H.265 @ 60 кадров/с – непригодно для просмотра из-за сброса кадров.

Прогресс есть, но воспроизведение видео в Linux требует доработки. Побочная проблема: беспроводная клавиатура иногда теряла отзывчивость при подключенном USB HDD для локального видео. Отключение HDD решало проблему.

Энергопотребление

Измерения проведены при подключении NanoPi R6S к HDMI-дисплею, сети 2.5GbE и двум RF-приемникам клавиатуры/мыши.

Результаты при настройках по умолчанию:

  • Выключено – 0.9 Вт (Довольно высокий показатель, сохраняется даже при отключении всех устройств от NanoPi R6S, кроме кабеля питания. Отключение кабеля снижает показания ваттметра до 0.4 Вт, значит плата потребляет ~0.5 Вт в выключенном состоянии)
  • Простой – 4.6 Вт
  • 4K YouTube в Firefox (полный экран – ПО-декодирование) – 9.7–11.3 Вт
  • 4K YouTube в Chromium (полный экран – Апп.-декодирование) – 5.3–7.3 Вт
  • Нагрузка на все 8 ядер (stress -c 8) – 10.9 Вт

Дополнительно оценено влияние режима “performance” на энергопотребление с помощью скрипта sbc-bench.sh в режиме review.

  • Простой – 5.4 Вт
  • 4K YouTube в Firefox (полный экран – ПО-декодирование) – 9.9–11.6 Вт
  • 4K YouTube в Chromium (полный экран – Апп.-декодирование) – 6.6–8.6 Вт
  • Нагрузка на все 8 ядер (stress -c 8) – 11.4 Вт
  • CPU Miner (часть sbc-bench.sh review) – 11.2 Вт

Включение режимов “performance” увеличивает энергопотребление на 0.3–1.2 Вт в зависимости от нагрузки. Значимость зависит от конкретного сценария использования.

Итоги

После трудного старта (не связанного с поддержкой FriendlyElec) Ubuntu 22.04 наконец установлена на NanoPi R6S. Система работает стабильно (аптайм >5 дней). Производительность отличная, как на других платформах Rockchip RK3588(S), а поддержка ПО улучшилась, но до “работает из коробки, как на x86” еще далеко.

Аппаратное ускорение 3D-графики и декодирования видео реализовано, но работает не во всех программах. Радует аппаратное декодирование VP9 в YouTube и плавная работа WebGL-демо в Chromium. Не выявлено проблем с сетевыми интерфейсами 2.5GbE, а быстрая внутренняя память eMMC обеспечивает быструю загрузку и отзывчивость. Металлический корпус эффективно охлаждает безвентиляторную систему под нагрузкой. К проблемам относятся аномально низкий результат Chromium в Speedometer 2.0 и повышенное энергопотребление.

Благодарность FriendlyElec за предоставленные образцы NanoPi R6S. Модель доступна за $139 плюс доставка в фирменном магазине, а также у реселлеров на Amazon и Aliexpress .

Выражаем свою благодарность источнику, с которого взята и переведена статья, сайту cnx-software.com.

Оригинал статьи вы можете прочитать здесь.

0 0 votes
Article Rating
Подписаться
Уведомление о
guest

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

0 Комментарий
Inline Feedbacks
View all comments