Одно из преимуществ работы на компанию, занимающуюся производством программ, заключается в том, что вам часто представляется возможность протестировать прототипы нового железа. Однако не в данном случае – я купил себе Raspberry Pi4 потому, что она очень дешёвая!
На Raspberry Pi4 стоит четырёхъядерный ARM Cortex A72, до 4 ГБ памяти и гигабитный порт Ethernet – и всё это всего за $35.
На Raspberry Pi4 есть ОС Raspbian (на основе Debian), и готовая библиотека продуктов, поэтому я вставил в неё SD-карточку, чтобы побыстрее загрузиться. Я искал syslog и заметил, что и ядро, и все пользовательские программы скомплированы как armv7 – то есть, для 32-битной памяти.
Я знаю, что Raspberry Pi4 поддерживает 64 бита, поэтому я не захотел запускать на ней 32-битную ОС. Я взял другую карту памяти и поставил на неё Debian. Debian, не содержащий ничего лишнего, скомпилированный как aarch64 – что означает 64-битную память.
Загрузив 64-битную ОС, я заинтересовался, насколько лучше она работает 32-битной, поэтому провёл несколько тестов.
Синтетические тесты скорости
Первое, что пришло мне в голову, был старый тест drystone, существующий с начала времён. Эту программу написали в 1988 году, и она занимается математическими вычислениями. Она вряд ли способна симулировать современную нагрузку, и мы можем использовать её только для того, чтобы сохранить некую связность со старым железом и программами.
Современное приложение, обрабатывающее цифры, лучше симулировать вычислением хэшей, поэтому я захотел провести тест с SHA1. К сожалению, утилита sha1sum скомпилирована без поддержки libssl или криптографических функций ядра, поэтому мне пришлось компилировать её из исходников.
Чтобы избежать узких мест в I/O, я подсчитываю хэш файла размером 2 Гб с опцией truncate -s 2GB, так что никакого ввода и вывода данных с карты не было:
SHA1 – более реалистичный тест, чем dhrystone, поскольку этот алгоритм используется в большом количестве приложений – торрентах, git, и т.п.
RAM
64-битная система обеспечивает доступ к памяти по 8 байт на одно чтение/запись. Я написал простую программу, размещающую большой буфер – она его пишет, а потом читает. Чтобы гарантировать реальное выделение памяти я использовал mlock(). В данном тесте объём буфера равен 2 ГБ: буфер в 3 ГБ работал в 64-битном режиме, а в 32-битном выдавал ошибку «недостаточно памяти».
Кодирование аудио
Я обратил внимание на то, что многие пользователи Raspberry Pi4 используют компьютер в качестве медиацентра, поэтому я запустил задачи на кодирование аудио с двумя самыми популярными кодеками.
Я кодировал композицию Pink Floyd «Echoes», потому что это довольно длинный трек, и с него можно получить измеряемые значения. Чтобы избежать I/O задержек, исходник и конечный файл хранились на ramfs:
Сетевые замеры скорости
Ещё один вариант использования Raspberry Pi4 – в качестве VPN или файервола. Не рекомендую использовать такие системы в подобных целях, но у многих людей всё ещё есть медленное подключение к интернету (менее 100 Мб), поэтому они могут не обращать внимания на медленную работу Raspberry Pi4.
Первый вопрос: сколько трафика способна обработать Raspberry Pi4? Нам нужно измерить чистую сетевую мощность компьютера, без ограничений физических интерфейсов, поэтому я запустил сессию iperf3 между двумя контейнерами. Однако контейнеры обмениваются данными через пару veth, а veth ускоряет трафик посредством ложных разгрузок.
Разгрузка подсчёта контрольной суммы IP осуществляется просто отказом от её подсчёта, а разгрузка сегментации TCP – отказом от сегментации и повторной сборки трафика: большой кусок данных на 64К просто передаётся в память как есть.
Чтобы избежать таких моментов, я запретил разгрузку командой
ethtool -K veth0 tx off rx off tso off gro off gso off
Firewall
Самое быстрое, на что способно сетевое оборудование – отбрасывать часть трафика, а быстрее всего это делать через правило TC. Чтобы не доходить до максимально возможной скорости, я использовал минимальный размер фрейма Ethernet, 64б.
Хотя обе системы не дошли до максимальной скорости передачи (1,5 Мб/с), 64-битно ядро показало чуть большую скорость, чем 32-битное. Если вы хотите использовать Raspberry Pi4 в качестве файервола, обязательно используйте ядро на 64 бита.
VPN
Ещё один частый вариант использования Raspberry Pi4 – VPN-сервер, а точнее, OpenVPN. Я же предпочитаю WireGuard, поэтому я проверил обе программы, поскольку они обе отличаются простотой установки:
Как и ожидалось, OpenVPN в 10 раз медленнее WireGuard. Чего не ожидалось, так это того, что OpenVPN работает с одинаковой скоростью на 32 и 64 б. WireGuard почти насыщает гигабитный порт в обоих случаях – возможно, мы достигли предела NIC.
Чтобы узнать, не может ли WireGuard работать ещё быстрее, я провёл ещё один тест с двумя контейнерами, не задействующий физический Ethernety. Единственная проблема была в том, что и клиент, и сервер iperf3 работали на Raspberry Pi4, загружая два ядра.
Как и ожидалось, OpenVPN и 32-битный WireGuard, ограниченный CPU, отработали хуже, а 64-битный WireGuard отработал лучше.
Заключения
Я часто читаю заявления типа «оно того не стоит», «ты выиграешь несколько миллисекунд», и т.д., просто из-за того, что Raspberry Pi4 не особо мощный компьютер. Это не так! Как знает любой человек, занимающийся встраиваемым оборудованием, на медленном железе оптимизация софта ещё важнее, чем на быстром.
Я уже знал, что 64-битная ОС будет лучше работать на Raspberry Pi4, но я не знал, насколько лучше. Поэтому я провёл все эти тесты. Надеюсь, вам понравилось!
Автор: Вячеслав Голованов
