Orange Pi Zero 4 — компактный одноплатный компьютер на базе восьмиядерного процессора Allwinner A733. Несмотря на небольшие размеры, плата получила современную аппаратную платформу с памятью LPDDR5, гигабитным Ethernet, Wi-Fi 6, Bluetooth 5.4, USB 3.0, поддержкой вывода изображения через HDMI и USB-C, а также встроенными GPU и NPU.
В этом обзоре я буду тестировать Orange Pi Zero 4 с 4 ГБ оперативной памяти. В отличие от обычного краткого знакомства с характеристиками, здесь постараемся проверить возможности платы на практике: от скорости процессора и памяти до сети, накопителя, USB, температуры, энергопотребления, графики, аппаратного видео и работы NPU.
Для тестирования я выбрал официальный образ Debian 13 Trixie Server с ядром Linux 6.6.98, предоставленный производителем платы.
Orange Pi Zero 4: что заявляет производитель
В основе Orange Pi Zero 4 находится SoC Allwinner A733. Процессорная часть состоит из двух ядер ARM Cortex-A76 и шести энергоэффективных Cortex-A55 с максимальной частотой до 2,0 ГГц.
За графику отвечает Imagination BXM-4-64, а для задач искусственного интеллекта предусмотрен отдельный NPU с производительностью до 3 TOPS.
Моя версия платы оснащена 4 ГБ LPDDR5. Производитель также предусматривает варианты с большим объёмом памяти — до 16 ГБ.
Основные заявленные характеристики Orange Pi Zero 4:
- SoC: Allwinner A733;
- CPU: 2 × Cortex-A76 + 6 × Cortex-A55;
- максимальная частота CPU: до 2,0 ГГц;
- GPU: Imagination BXM-4-64;
- NPU: до 3 TOPS;
- оперативная память: LPDDR5, в моей версии — 4 ГБ;
- сетевой интерфейс: Gigabit Ethernet;
- беспроводная связь: Wi-Fi 6;
- Bluetooth: 5.4;
- видеовыход: HDMI 2.0 до 4K@60;
- USB-C: USB 3.0 Host и USB 2.0 Host/Device;
- DisplayPort: DP 1.4 через USB-C;
- камеры: два интерфейса MIPI CSI с четырьмя линиями;
- PCIe: PCIe 3.0;
- GPIO: 26-контактный разъём;
- интерфейсы GPIO: I2C, SPI, UART и PWM;
- питание: USB-C, 5 В / 3 А;
- размер: 50 × 55 мм;
- масса: около 21 г.
Производитель также заявляет поддержку аппаратного кодирования и декодирования видео, GPU, NPU, температурного датчика и watchdog. В таблице адаптации Linux 6.6 отдельно указана поддержка Ethernet, Wi-Fi, Bluetooth, USB 2.0/3.0, HDMI, USB-C DisplayPort, накопителей, камер и 26-контактного GPIO.
Размеры и внешность
По размерам Orange Pi Zero 4 действительно относится к очень компактным одноплатным компьютерам. При этом производителю удалось разместить на небольшой плате полноценный гигабитный Ethernet, беспроводные интерфейсы, USB, видеовыходы и 26-контактный GPIO.
Выбор операционной системы
Для практического тестирования я решил использовать не графическую оболочку, а серверный вариант системы. Это позволяет получить более чистую среду для измерения производительности и одновременно проверить Orange Pi Zero 4 в сценариях, для которых часто используются одноплатные компьютеры: сервер, Docker, сетевые сервисы, домашняя автоматизация и другие фоновые задачи.
В качестве основной системы выбран официальный образ:
Debian 13 Trixie Server, Linux 6.6.98.
Перед записью образа я сначала проверил его контрольную сумму SHA-256.
Проверяем скачанный образ
После загрузки образа я перешёл в каталог с файлами:
cd ~/Загрузки/Образы/OrangePi/4\ zero/Orangepizero4_1.0.0_debian_trixie_server_linux6.6.98Затем запустил проверку SHA-256:
sha256sum -c Orangepizero4_1.0.0_debian_trixie_server_linux6.6.98.img.shaВ результате получил:
Orangepizero4_1.0.0_debian_trixie_server_linux6.6.98.img: ЦЕЛ
Таким образом, перед записью на карту памяти я убедился, что скачанный файл соответствует контрольной сумме производителя.
Записываем Debian на карту памяти
Для записи образа я использовал Raspberry Pi Imager. Программа записала подготовленный образ Debian на карту microSD, после чего карта была установлена в Orange Pi Zero 4.
Первый запуск Orange Pi Zero 4
После записи образа карта памяти была установлена в Orange Pi Zero 4, после чего плата получила питание и начала загрузку.
После завершения загрузки появился первый вход в систему.
Обновление системы и настройка зеркал
После первого входа в систему я первым делом решил полностью обновить пакеты — стандартная процедура после установки серверной ОС. Однако при обновлении обнаружились проблемы с доступностью некоторых зарубежных репозиториев из России.
Изначально в системе был настроен репозиторий Docker через зеркало Aliyun:
deb [arch=arm64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://mirrors.aliyun.com/docker-ce/linux/debian trixie stableЗагрузка пакета containerd.io шла со скоростью около 71 КБ/с, а расчётное время загрузки превышало 14 минут. Для нормального обновления системы такая скорость оказалась непрактичной.
Затем я попробовал заменить репозиторий Docker на зеркало Yandex, но получил ошибку 404 Not Found: на момент тестирования в зеркале отсутствовали необходимые пакеты для Debian 13 Trixie.
Основное обновление системы также сначала выполнялось через зеркало Huawei Cloud, однако команда apt update зависала на этапе:
0% [Waiting for headers]Поэтому перед дальнейшей настройкой я отключил старые источники, которые мешали обновлению. Файлы репозиториев в Debian обычно находятся в каталоге /etc/apt/sources.list.d/. Вместо удаления их можно временно переименовать, сохранив возможность вернуть исходную конфигурацию.
Сначала посмотрим, какие дополнительные источники вообще настроены:
ls -la /etc/apt/sources.list.d/
grep -RniE 'aliyun|huaweicloud|docker' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/nullЕсли среди них есть старый репозиторий Docker, его можно отключить, переименовав файл с расширением .list:
sudo mv /etc/apt/sources.list.d/docker.list /etc/apt/sources.list.d/docker.list.disabledИмя файла может отличаться. Поэтому перед выполнением команды его нужно определить по результату предыдущей проверки. Файлы с расширением .disabled APT не использует.
Аналогичным образом отключаем проблемные дополнительные репозитории, если они присутствуют:
sudo mv /etc/apt/sources.list.d/<имя-файла>.list /etc/apt/sources.list.d/<имя-файла>.list.disabledОсновной файл источников предварительно сохраняем:
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bakНастройка зеркала Debian
Открываем основной файл источников:
sudo nano /etc/apt/sources.listДля тестирования использовалась следующая конфигурация:
deb http://mirror.yandex.ru/debian trixie main contrib non-free non-free-firmware
deb http://mirror.yandex.ru/debian trixie-updates main contrib non-free non-free-firmware
deb http://mirror.yandex.ru/debian trixie-backports main contrib non-free non-free-firmware
deb http://mirror.yandex.ru/debian-security trixie-security main contrib non-free non-free-firmwareПосле этого обновляем информацию о пакетах и устанавливаем доступные обновления:
sudo apt update
sudo apt full-upgrade -yПосле перехода на рабочее зеркало скорость загрузки в моём тесте достигала 11,1 МБ/с, и обновление системы прошло без проблем.
Установка инструментов для тестирования
После обновления устанавливаем программы, которые понадобятся в следующих разделах обзора:
sudo apt install -y sysbench stress-ng 7zip iperf3 hdparm mmc-utilsНастройка Docker
После подготовки основной системы отдельно настраиваем Docker. Старый репозиторий Aliyun оставляем отключённым и устанавливаем Docker из доступных пакетов Debian:
sudo apt install -y docker.io docker-cliДля ускорения загрузки образов настраиваем зеркало Docker. Создаём каталог конфигурации, если его ещё нет:
sudo mkdir -p /etc/dockerСоздаём файл /etc/docker/daemon.json:
sudo nano /etc/docker/daemon.jsonИ добавляем:
{
"registry-mirrors": [
"https://dockerhub.timeweb.cloud"
]
}После сохранения перезапускаем Docker:
sudo systemctl restart docker
sudo systemctl enable dockerПроверить состояние службы можно командой:
sudo systemctl status dockerА работу загрузки образов — запуском стандартного тестового контейнера:
sudo docker run --rm hello-worldВ моём случае после настройки зеркала образ hello-world скачался без заметных задержек, и Docker был готов к дальнейшему использованию.
Промежуточный итог
Проблемы при первом обновлении были связаны с доступностью отдельных репозиториев из условий тестирования. Старые источники Docker и другие проблемные дополнительные репозитории были отключены, после чего основное обновление Debian выполнялось через рабочее зеркало Yandex.
При этом старые конфигурационные файлы не удалялись, а переименовывались или сохранялись в резервных копиях. Это позволяет при необходимости вернуть исходные источники.
После обновления системы и настройки Docker Orange Pi Zero 4 был подготовлен к дальнейшему тестированию.
В следующей части — тест производительности процессора и памяти.
Конфигурация тестового стенда
Прежде чем перейти к нагрузочным тестам, зафиксируем конфигурацию. Это важно для воспроизводимости: результаты SBC сильно зависят от версии ядра, governor, охлаждения и накопителя.
| Компонент | Значение |
|---|---|
| Плата | Orange Pi Zero 4, 4 ГБ LPDDR5 |
| SoC | Allwinner A733 |
| CPU | 6 × Cortex-A55 (до 1794 МГц) + 2 × Cortex-A76 (до 2002 МГц) |
| ОС | Debian GNU/Linux 13 (Trixie), сборка Orange Pi 1.0.0 |
| Ядро | Linux 6.6.98-sun60iw2 (aarch64) |
| Governor | ondemand (A55), schedutil (A76) |
| RAM | 3.7 GiB доступно, zram swap 1.9 GiB |
| Накопитель | microSD 119.1 GB (mmcblk1) |
| Питание | USB Type-C, 5 В / 3 А |
| Охлаждение | пассивный радиатор (без вентилятора) |
Температура в простое после загрузки системы составила ~60 °C по всем пяти thermal-зонам. Это довольно высокий стартовый уровень, что стоит учитывать при оценке нагрева под нагрузкой.
Тест CPU: sysbench (single-core)
Первый тест — sysbench cpu с лимитом простых чисел 20000 на одном потоке. Этот тест показывает производительность одного ядра и хорошо отражает «отзывчивость» системы в однопоточных задачах.
sysbench cpu --cpu-max-prime=20000 --threads=1 run| Параметр | Результат |
|---|---|
| Скорость | 839.37 events/sec |
| Общее время | 10.0011 s |
| Всего событий | 8396 |
| Средняя задержка | 1.19 ms |
| Максимальная задержка | 11.95 ms |
Результат 839 events/sec — хороший показатель для одного ядра Cortex-A76. Для сравнения, Raspberry Pi 5 в этом тесте показывает около 900–1000 events/sec, так что отставание минимальное.
Тест CPU: sysbench (multi-core, 8 потоков)
Второй тест — тот же sysbench, но уже на всех 8 ядрах. Он показывает, насколько хорошо плата масштабирует производительность под полной нагрузкой.
sysbench cpu --cpu-max-prime=20000 --threads=8 run| Параметр | Результат |
|---|---|
| Скорость | 3846.82 events/sec |
| Общее время | 10.0018 s |
| Всего событий | 38481 |
| Средняя задержка | 2.08 ms |
| 95-й процентиль | 2.76 ms |
| Разброс по потокам (stddev) | 2113.61 |
Масштабирование: 3846.82 / 839.37 = 4.58×. Это меньше идеальных 8×, что ожидаемо для гетерогенной архитектуры 2+6: два быстрых ядра A76 и шесть энергоэффективных A55. Разброс по потокам (stddev = 2113.61) объясняется той же причиной — потоки, попавшие на A76, выполнили заметно больше работы.
Температура после теста поднялась до ~71 °C — прирост около +11 °C относительно простоя.
Тест CPU: 7-Zip benchmark
Для независимой оценки производительности в MIPS используем встроенный бенчмарк 7-Zip. Он имитирует реальную работу с данными и даёт более «практичный» результат, чем чистый sysbench.
7z b| Режим | Скорость | Загрузка CPU | MIPS на ядро | Рейтинг |
|---|---|---|---|---|
| Компрессия | 7846 KiB/s | 748% | 1092 | 8173 MIPS |
| Декомпрессия | 110927 KiB/s | 561% | 1724 | 9650 MIPS |
| Итого | 8912 MIPS | |||
Частоты CPU под нагрузкой (из вывода 7-Zip):
| Режим | A76 | A55 |
|---|---|---|
| 1 поток | 2000 МГц (максимум) | 1603–1956 МГц |
| 4 потока | 1806 МГц | 1456 МГц |
| 8 потоков | 1749–1790 МГц | ~757% загрузки (все 6 ядер) |
Это важный результат: A76 действительно разгоняются до заявленных 2000 МГц при однопоточной нагрузке. Под полной 8-поточной нагрузкой частота A76 немного снижается (до ~1750–1790 МГц) — признак того, что система начинает слегка сдерживать частоты из-за температуры или энергопотребления.
Температура после 7-Zip достигла ~80 °C. Это уже серьёзный нагрев для пассивного охлаждения. Для длительных задач это может стать ограничивающим фактором.
Промежуточный итог по CPU
Orange Pi Zero 4 показывает производительность на уровне современных ARM-плат среднего класса. Два ядра Cortex-A76 обеспечивают хорошую однопоточную скорость (839 events/sec в sysbench), а шесть A55 добавляют многопоточную мощность (3846 events/sec, 8912 MIPS в 7-Zip).
Главный вывод: плата греется. Радиатора явно не хватает. Тут необходимо ставить охлаждение и видимо лучше активное а не просто радиатор.
Сетевые тесты
Orange Pi Zero 4 оснащён гигабитным Ethernet и модулем Wi-Fi 6 с Bluetooth 5.4. Проверим оба интерфейса с помощью iperf3 — по одному тесту в каждом направлении, а также измерим задержку через ping.
Gigabit Ethernet
Для теста Ethernet плата подключена кабелем к роутеру Keenetic Giga (KN-1010), второй конец — к основному ПК на CachyOS. Сначала запускаем сервер на Orange Pi:
iperf3 -sЗатем с основного ПК выполняем два теста: прямое направление (ПК → Orange Pi) и обратное (Orange Pi → ПК).
Прямое направление (ПК → Orange Pi):
iperf3 -c 192.168.1.64 -t 30| Параметр | Результат |
|---|---|
| Передано | 3.28 GBytes |
| Скорость | 940 Mbits/sec |
| Retr (повторные передачи) | 0 |
Обратное направление (Orange Pi → ПК):
iperf3 -c 192.168.1.64 -t 30 -R| Параметр | Результат |
|---|---|
| Передано | 3.29 GBytes |
| Скорость | 941 Mbits/sec |
| Retr (повторные передачи) | 0 |
Оба направления показали практически максимальную для гигабитного Ethernet скорость — 940–941 Mbits/sec при нулевом количестве повторных передач. Это означает, что Ethernet-интерфейс с PHY YT8531CA работает без заметных ограничений со стороны сетевого стека Linux 6.6. Такой результат можно считать отличным для SBC этого класса.
Wi-Fi: важное уточнение по тестовой среде
Прежде чем перейти к результатам, сделаю важную оговорку. Мой роутер Keenetic Giga (KN-1010) поддерживает Wi-Fi 5 (802.11ac), а не Wi-Fi 6. Это значит, что все результаты Wi-Fi в этом обзоре отражают работу платы в режиме Wi-Fi 5 — максимально возможном для данной тестовой среды. Полноценно проверить Wi-Fi 6 на Orange Pi Zero 4 можно только с роутером, поддерживающим 802.11ax. Поэтому приведённые ниже цифры характеризуют работу встроенного Wi-Fi-модуля в условиях Wi-Fi 5 и не показывают его максимальных возможностей.
Для теста Wi-Fi плата подключена к той же сети через nmtui. IP-адрес Wi-Fi: 192.168.1.138.
sudo nmtuiЗатем запускаем сервер iperf3 на Orange Pi и выполняем тесты с основного ПК.
Прямое направление (ПК → Orange Pi):
iperf3 -c 192.168.1.138 -t 30| Параметр | Результат |
|---|---|
| Передано | 1.09 GBytes |
| Скорость | 312 Mbits/sec |
| Retr (повторные передачи) | 23 |
Обратное направление (Orange Pi → ПК):
iperf3 -c 192.168.1.138 -t 30 -R| Параметр | Результат |
|---|---|
| Передано | 1.08 GBytes |
| Скорость | 308 Mbits/sec |
| Retr (повторные передачи) | 1 |
Обе стороны показали около 310 Mbits/sec. Это хороший результат для Wi-Fi 5 в реальных условиях. Теоретическая скорость соединения 802.11ac зависит от ширины канала, числа пространственных потоков и используемой модуляции, поэтому напрямую сравнивать полученные 310 Mbits/sec с одной фиксированной теоретической цифрой некорректно.
В прямом направлении зафиксировано 23 повторные передачи, тогда как в обратном — всего одна. Для беспроводной сети это не выглядит критичным и может быть связано с обычными помехами и особенностями радиосреды.
Напомню: с роутером Wi-Fi 6 (802.11ax) можно было бы отдельно проверить работу модуля в режиме Wi-Fi 6 и оценить его производительность с учётом возможностей самого стандарта.
Задержка (ping) по Wi-Fi
ping 192.168.1.138 -c 20| Параметр | Результат |
|---|---|
| Потеря пакетов | 0% |
| Минимальный RTT | 2.515 ms |
| Средний RTT | 5.472 ms |
| Максимальный RTT | 58.167 ms |
| Стандартное отклонение | 12.089 ms |
Средняя задержка 5.5 ms — нормальный показатель для Wi-Fi в локальной сети. При этом зафиксирован один заметный выброс до 58 ms. Вероятнее всего, это единичная задержка, связанная с особенностями беспроводной среды. При этом потери пакетов отсутствуют, а среднее значение RTT остаётся низким.
Промежуточный итог по сети
Гигабитный Ethernet на Orange Pi Zero 4 показал 940–941 Mbits/sec в обоих направлениях при нулевом количестве повторных передач. Это делает плату хорошо подходящей для сетевых серверов, NAS, маршрутизаторов и других задач, где важна стабильная проводная сеть.
Wi-Fi в тестовой среде показал ~310 Mbits/sec. При этом тест проводился с роутером Keenetic Giga, работающим в стандарте Wi-Fi 5, поэтому максимальные возможности установленного на плате Wi-Fi 6-модуля здесь не проверялись. Средняя задержка составила 5.5 ms при отсутствии потерь пакетов.
Накопитель microSD
Orange Pi Zero 4 загружается с карты microSD. В тесте используется SanDisk Ultra на 128 ГБ, произведённая в апреле 2024 года. В системе карта определяется как SDXC и работает в режиме SDR104 — высокоскоростном режиме SD-интерфейса с теоретической пропускной способностью до 104 МБ/с.
dmesg | grep -i "mmc1"| Параметр | Значение |
|---|---|
| Модель | SanDisk Ultra |
| Тип | SDXC |
| Режим работы | SDR104 |
| Номинальный объём | 128 ГБ |
| Доступный объём | 119,1 ГБ |
| Дата производства | 04.2024 |
| Версия прошивки | 0x5 |
| Ревизия железа | 0x8 |
Для проверки скорости чтения используем dd с флагом iflag=direct, чтобы исключить влияние кэша. Читаем 1 ГБ данных непосредственно с карты в /dev/null, поэтому содержимое накопителя не изменяется.
sudo dd if=/dev/mmcblk1 of=/dev/null bs=1M count=1024 iflag=direct| Попытка | Скорость чтения |
|---|---|
| 1 | 66,9 МБ/с |
| 2 | 66,9 МБ/с |
| 3 | 68,4 МБ/с |
Средний результат составляет около 67,4 МБ/с. Это примерно 65% от теоретической пропускной способности SDR104 в 104 МБ/с. Разница между теоретическим максимумом и реальным результатом зависит не только от интерфейса, но и от самой карты, контроллера и условий тестирования.
Таким образом, Orange Pi Zero 4 корректно определяет SanDisk Ultra и использует доступный для неё режим SDR104.
Запись отдельно не тестировалась, поэтому конкретную скорость записи для этой карты по результатам данного теста определить нельзя. Для оценки производительности при записи потребуется отдельный тест.
Для постоянно работающего сервера microSD имеет смысл рассматривать прежде всего как загрузочный и системный накопитель. При интенсивной записи баз данных, логов или данных Docker имеет смысл использовать отдельный более производительный накопитель.
Отдельно стоит отметить команду mmc extcsd read. Она предназначена для работы с eMMC, где используется регистр EXT_CSD, и не применяется для обычных SD-карт. Поэтому отсутствие результата этой команды при работе с microSD является нормальным поведением.
Промежуточный итог
SanDisk Ultra в Orange Pi Zero 4 работает в режиме SDR104 и показывает около 67,4 МБ/с на чтение. Этого достаточно для загрузки системы и обычных задач, однако при переходе к внешнему SSD можно ожидать существенно более высокой скорости работы с накопителем.
USB Type-C 3.1 Gen 2 и внешний SSD
Один из самых интересных интерфейсов Orange Pi Zero 4 — порт USB Type-C, поддерживающий USB 3.1 и DisplayPort. Именно к нему я подключил внешний SSD KEYRON KR2 на 512 ГБ. Цель теста — проверить фактическую скорость работы накопителя и определить, насколько эффективно плата использует высокоскоростной режим USB.
Сначала проверим, на какой скорости система определила подключённый SSD. Для этого используем команду lsusb -t, которая показывает дерево USB-устройств и скорость подключения:
lsusb -t| Параметр | Результат |
|---|---|
| Тип разъёма | USB Type-C |
| Стандарт интерфейса | USB 3.1 |
| Режим подключения SSD | 10 Гбит/с (USB 3.1 Gen 2) |
| Контроллер | xhci-hcd |
| Устройство | External SSD KEYRON KR2, драйвер UAS |
Значение 10000M в выводе lsusb -t означает, что SSD подключён на скорости 10 Гбит/с. Это соответствует режиму USB 3.1 Gen 2, который также обозначается как USB 3.2 Gen 2. Таким образом, в данном тесте используется не 5-гигабитный режим USB 3.0/USB 3.1 Gen 1, а более быстрый режим USB со скоростью 10 Гбит/с.
Накопитель использует драйвер uas (USB Attached SCSI), предназначенный для работы с современными USB-накопителями и эффективной обработки очередей операций ввода-вывода.
После проверки подключения монтируем SSD и проводим тесты через файловую систему. Такой вариант ближе к реальному сценарию использования накопителя, чем работа непосредственно с raw-устройством.
sudo mkdir -p /mnt/ssd
sudo mount /dev/sda1 /mnt/ssdТест записи
Сначала записываем на SSD файл объёмом 1 ГБ. Используем блоки по 4 МБ и флаг oflag=direct, чтобы минимизировать влияние кэша операционной системы:
sudo dd if=/dev/zero of=/mnt/ssd/test.bin bs=4M count=256 oflag=direct| Параметр | Результат |
|---|---|
| Объём | 1,0 ГиБ |
| Время | 1,44 с |
| Скорость записи | 745 МБ/с |
Тест чтения
Теперь читаем созданный файл три раза подряд, также используя прямой ввод-вывод:
sudo dd if=/mnt/ssd/test.bin of=/dev/null bs=4M iflag=direct| Попытка | Скорость чтения |
|---|---|
| 1 | 850 МБ/с |
| 2 | 863 МБ/с |
| 3 | 864 МБ/с |
В трёх последовательных запусках скорость чтения составила 850–864 МБ/с, то есть в среднем около 859 МБ/с. Скорость записи достигла 745 МБ/с. Для одноплатного компьютера это высокий результат и заметный прирост по сравнению с протестированной ранее microSD.
Полученные значения не следует напрямую сравнивать с теоретическими 10 Гбит/с интерфейса. Это скорость передачи данных на уровне USB-интерфейса, тогда как реальная скорость работы с файлами зависит от контроллера USB, USB-моста накопителя, самого SSD, файловой системы и накладных расходов передачи данных.
Важное замечание по методике: первая попытка чтения непосредственно с raw-устройства /dev/sda с использованием прямого ввода-вывода показала крайне низкую скорость и фактически зависла. Поэтому для итоговых замеров использовалось чтение файла на смонтированной файловой системе.
После завершения тестов удаляем временный файл и размонтируем накопитель:
sudo rm /mnt/ssd/test.bin
sudo umount /mnt/ssdПромежуточный итог
Внешний SSD KEYRON KR2 показал до 864 МБ/с на чтение и 745 МБ/с на запись при подключении к USB Type-C в режиме USB 3.1 Gen 2 с пропускной способностью 10 Гбит/с.
В сочетании с гигабитным Ethernet такой накопитель хорошо подходит для внешнего хранилища, файлового сервера и работы с большими файлами.
GPU и аппаратное декодирование видео
Одна из особенностей Allwinner A733 — встроенный GPU Imagination BXM-4-64 и аппаратный видеодекодер с поддержкой современных кодеков, включая H.265, VP9 и AVS2. Заявленная аппаратная поддержка видео достигает разрешения 8K@24. При тестировании серверного образа Debian 13 Trixie Server я отдельно проверил, насколько эти возможности доступны непосредственно в используемом окружении.
Что показала диагностика
Сначала проверим доступные графические устройства и сообщения ядра:
ls -la /dev/dri/
dmesg | grep -i "pvrsrvkm\|powervr\|drm"В выводе dmesg видно, что дисплейный контроллер sunxi-drm успешно инициализирован. HDMI-выход работает и корректно определяет подключённый монитор:
[drm] sunxi-hdmi: drm hdmi mode set: 1920*1080
[drm] Initialized sunxi-drm 3.0.0 20230901 for soc@3000000:sunxi-drm on minor 0
[drm] sunxi_drm_bind okПри этом в проверенном выводе отсутствуют упоминания pvrsrvkm, powervr и bxm. На основании этой диагностики нельзя подтвердить, что аппаратное ускорение GPU доступно приложениям в текущем серверном окружении.
Проверка OpenGL ES
Для дополнительной проверки был установлен glmark2-es2-x11 и выполнена попытка запуска:
glmark2-es2 --off-screenСистема вернула:
Error: main: Could not initialize canvasСоздать графический контекст не удалось, поэтому получить количественный результат для GPU в этом тесте невозможно. Эта ошибка сама по себе не позволяет сделать вывод об аппаратной неисправности GPU: она показывает, что в текущем окружении glmark2 не смог запустить необходимую графическую подсистему.
Аппаратное декодирование видео
Наличие связанных с видеоподсистемой устройств дополнительно проверено через /proc/interrupts:
140: 0 0 0 0 0 0 0 0 wakeupgen 49 Level cedar_dev
144: 0 0 0 0 0 0 0 0 wakeupgen 48 Level cedar_dev_ve2В системе присутствуют устройства cedar_dev и cedar_dev_ve2. Однако по одному только этому выводу нельзя подтвердить фактическую работу аппаратного видеодекодера. Для этого необходим практический тест с реальным видеопотоком и соответствующим программным конвейером.
Особенности серверной сборки
Серверный образ рассчитан прежде всего на headless-сценарии — работу через SSH, консоль, сетевые сервисы и контейнеры. Поэтому полноценное графическое окружение здесь не является основной целью.
Для более полной проверки GPU и аппаратного декодирования потребуется окружение, в котором доступны соответствующие графические и мультимедийные библиотеки. Поэтому для следующего этапа тестирования логично использовать desktop-сборку Orange Pi Zero 4.
Промежуточный итог по GPU и видео
В серверном образе Debian 13 Trixie Server удалось подтвердить работу дисплейного контроллера sunxi-drm и HDMI, а также наличие устройств cedar_dev и cedar_dev_ve2. При этом в рамках проведённых проверок не удалось подтвердить работу аппаратного GPU-ускорения через OpenGL ES и фактическое использование аппаратного видеодекодера. Для окончательной оценки этих возможностей нужен отдельный тест в desktop-окружении.
В следующей части — тест NPU 3 TOPS. Проверим, доступен ли AI-ускоритель на серверной сборке и какие модели можно запустить.
Docker и серверные задачи
Один из практических сценариев для Orange Pi Zero 4 — работа в роли небольшого домашнего сервера с Docker-контейнерами. После обновления системы и настройки зеркала Docker проверим, как плата справляется с одновременной работой нескольких типичных сервисов.
Установка Docker и настройка зеркала
В используемой конфигурации Debian 13 Trixie для работы потребовалась установка пакетов docker.io и docker-cli:
sudo apt install -y docker.io docker-cliЗеркало Docker было настроено ранее в файле /etc/docker/daemon.json. Если необходимо повторить эту настройку, выполняем:
sudo mkdir -p /etc/docker
sudo nano /etc/docker/daemon.jsonСодержимое файла:
{
"registry-mirrors": [
"https://dockerhub.timeweb.cloud"
]
}После сохранения перезапускаем Docker:
sudo systemctl restart docker
sudo systemctl enable dockerПроверить состояние службы:
sudo systemctl status dockerИ проверить загрузку образов:
sudo docker run --rm hello-worldПроверка прошла успешно: тестовый образ hello-world загрузился и контейнер запустился.
Запуск трёх контейнеров
Для проверки серверного сценария я одновременно запустил три контейнера:
- Uptime Kuma — мониторинг доступности сервисов;
- Nginx — веб-сервер;
- AdGuard Home — DNS-фильтр.
Запускаем их последовательно:
sudo docker run -d --restart=unless-stopped -p 3001:3001 --name uptime-kuma louislam/uptime-kuma:1sudo docker run -d --restart=unless-stopped -p 8080:80 --name nginx nginx:alpinesudo docker run -d --restart=unless-stopped --name adguardhome \
-p 5353:53/tcp \
-p 5353:53/udp \
-p 3000:3000 \
adguard/adguardhomeС AdGuard Home возникла небольшая особенность: стандартный DNS-порт 53 уже был занят системным dnsmasq, который используется в Orange Pi OS для локального разрешения имён. Поэтому для этого теста DNS-порт контейнера был опубликован на 5353. Для проверки самого контейнера и его влияния на систему этого достаточно.
После запуска проверяем список контейнеров:
sudo docker psВ результате все три контейнера успешно запустились:
| Контейнер | Образ | Статус | Порты |
|---|---|---|---|
| uptime-kuma | louislam/uptime-kuma:1 | Up (healthy) | 3001 |
| nginx | nginx:alpine | Up | 8080 |
| adguardhome | adguard/adguardhome | Up | 3000, 5353 |
Проверка доступности сервисов
Дополнительно проверяем HTTP-ответы локальных сервисов через curl:
curl -I http://127.0.0.1:3001
curl -I http://127.0.0.1:8080
curl -I http://127.0.0.1:3000Полученные ответы:
| Сервис | HTTP-код |
|---|---|
| Uptime Kuma | 302 — перенаправление на страницу входа |
| Nginx | 200 — OK |
| AdGuard Home | 302 — перенаправление на страницу настройки |
Таким образом, все три HTTP-сервиса отвечали, а контейнеры продолжали работать одновременно.
Нагрузка на систему
После запуска трёх контейнеров я проверил использование оперативной памяти:
free -h| Параметр | Значение |
|---|---|
| Всего RAM | 3,7 ГиБ |
| Использовано | 455 МиБ |
| Свободно | 1,7 ГиБ |
| Buff/cache | 1,7 ГиБ |
| Доступно | 3,3 ГиБ |
| Swap | 0 Б использовано |
В момент измерения использовалось около 455 МиБ оперативной памяти, при этом доступно оставалось 3,3 ГиБ. Swap не использовался.
В htop нагрузка на процессор также оставалась очень небольшой: load average составлял 0,06, 0,25 и 0,21. Для трёх запущенных сервисов это ожидаемо — в данном тесте они практически не создавали постоянной вычислительной нагрузки.
Температура после запуска контейнеров составляла около 59–60 °C, то есть практически вернулась к уровню простоя.
Промежуточный итог по Docker
В тестовой конфигурации Orange Pi Zero 4 с 4 ГБ RAM одновременно запустил Uptime Kuma, Nginx и AdGuard Home. В момент измерения они использовали около 455 МиБ оперативной памяти, swap не был задействован, а температура платы оставалась на уровне около 60 °C.
Этот тест показывает, что плата подходит для нескольких лёгких постоянно работающих Docker-сервисов. При этом более требовательные сценарии — например, базы данных, системы автоматизации, медиасервисы или большое количество контейнеров — требуют отдельного тестирования, поскольку их нагрузка существенно зависит от конкретного приложения и настроек.
Основное ограничение в данной конфигурации связано не с Docker, а с DNS-портом: порт 53 уже занят системным dnsmasq. Если использовать AdGuard Home как основной DNS-сервер, потребуется освободить этот порт или изменить схему работы DNS.
Итоги
Orange Pi Zero 4 — компактная ARM-плата на базе Allwinner A733 с 4 ГБ LPDDR5, гигабитным Ethernet, Wi-Fi 6 и USB Type-C с поддержкой USB 3.1 Gen 2. В тесте использовалась серверная версия Debian 13 Trixie с ядром Linux 6.6.98-sun60iw2.
Результаты тестирования
| Тест | Результат |
|---|---|
| sysbench — CPU, 1 поток | 839 событий/с |
| sysbench — CPU, 8 потоков | 3847 событий/с, масштабирование 4,58× |
| 7-Zip — CPU | 8912 MIPS |
| Тест пропускной способности LPDDR5 | ~13,9 ГиБ/с |
| iperf3 — Gigabit Ethernet | 940–941 Мбит/с в обоих направлениях |
| iperf3 — Wi-Fi | ~310 Мбит/с в условиях теста с Wi-Fi 5 |
| dd — microSD, чтение | ~67,4 МБ/с |
| dd — USB 3.1 Gen 2 + SSD, чтение | ~859 МБ/с |
| dd — USB 3.1 Gen 2 + SSD, запись | 745 МБ/с |
| Температура — простой | ~60 °C |
| Температура — длительная CPU-нагрузка | ~80 °C |
| Docker — 3 контейнера | 455 МиБ RAM, swap не используется |
Сценарии использования
Полученных результатов достаточно, чтобы рассматривать Orange Pi Zero 4 как платформу для домашнего сервера, Docker-сервисов, мониторинга, DNS-фильтрации, небольших веб-приложений и файлового хранилища. Для последнего предпочтительнее использовать внешний SSD: microSD показала около 67,4 МБ/с на чтение, тогда как SSD через USB 3.1 Gen 2 — до 864 МБ/с в отдельных тестах.
Плата также подходит для edge- и IoT-задач благодаря набору периферийных интерфейсов. Мультимедийное применение возможно, но результаты этого теста не позволяют оценить производительность GPU и аппаратного видеодекодирования.
Основные ограничения
- Охлаждение: при длительной CPU-нагрузке температура достигала около 80 °C, поэтому для тяжёлых постоянных задач желательно активное охлаждение.
- Память: в тестируемой версии установлено 4 ГБ RAM. Этого достаточно для нескольких лёгких сервисов, но запас ограничен при увеличении нагрузки.
- Накопитель: microSD удобна для загрузки системы, но для интенсивной работы с данными лучше использовать SSD.
- Wi-Fi: тест проводился с точкой доступа Wi-Fi 5, поэтому максимальные возможности встроенного Wi-Fi 6 не проверялись.
- GPU и видео: полноценное аппаратное ускорение в серверном окружении подтвердить не удалось; для него нужен отдельный тест на desktop-образе.
Заключение
Orange Pi Zero 4 в версии с 4 ГБ RAM представляет собой компактную платформу для серверных, сетевых и периферийных задач. В проведённых тестах она обеспечила высокую для своего формата скорость Ethernet и внешнего SSD, достаточную производительность CPU и возможность запуска нескольких Docker-сервисов.
При этом возможности платы лучше оценивать с учётом конкретной нагрузки: тяжёлые продолжительные вычисления требуют внимания к охлаждению, интенсивная работа с данными — быстрого внешнего накопителя, а ресурсоёмкие приложения — достаточного объёма RAM. GPU и аппаратное декодирование видео в рамках серверного теста требуют дополнительной проверки.
