Китайский MiniPC на Celeron J3160 с четырьмя сетевыми портами Intel — Часть 2, тесты.

Это — вторая часть обзора китайского MiniPC. Первую часть обзора, описательную, смотрите тут.
А здесь — интересующие меня тесты, связанные с криптографией и работой этой железки в качестве домашнего сетевого роутера.

После первичной настройки я загрузил свою сборку FreeBSD 13 (да, я предпочитаю FreeBSD а не Linux) и прогнал интересующие меня тесты.

Низкоуровневый криптотест и странности Turbo Boost.

Первое что меня интересовало — скорость работы AES, а именно алгоритмов AES-128-CBC, AES-256-CBC, AES-128-GCM и AES-256-GCM, основных алгоритмов используемого сейчас для построения VPN.
Начал я с того, что воспользовался встроенным в openssl 1.1.1 тестом производительности «openssl speed -elapsed -evp ».

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc      33528.96k    58171.58k    74272.29k    79745.15k    81530.15k    81675.13k
aes-256-cbc      29110.04k    45079.53k    54794.38k    58049.34k    58811.67k    58918.20k
aes-128-gcm      21963.46k    43909.46k    62528.31k    70778.88k    73405.74k    73292.77k
aes-256-gcm      20278.77k    38984.18k    53549.81k    59340.46k    61005.82k    61139.63k

И вот тут я был шокирован. Очень медленно. Вот, для сравнения, результаты Atom D2500

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc      25740.84k    29077.12k    30214.91k    30470.14k    30517.36k    30594.39k
aes-256-cbc      19336.53k    20934.06k    21482.33k    21542.11k    21733.38k    21708.80k
aes-128-gcm      17743.67k    22049.71k    49689.34k    54126.27k    55028.39k    55268.69k
aes-256-gcm      14585.27k    17392.47k    42018.56k    45814.60k    46818.24k    46859.94k

Огорчился. Решил понаблюдать за частотами в процессе теста с помощью утилиты turbostat, которая показывает честные частоты, включая те, что устанавливаются контроллером Turbo Boost. И увидел, что частоты ведут себя странно и редко поднимаются даже до 1.6GHz (напомню, Turbo Boost должен разгонять процессор до 2.24GHz). Подумав, я выдвинул гипотезу, что это может быть сочетание FreeBSD (не самая распространённая система, вряд ли китайские производители тестируют BIOS'ы на FreeBSD) и Braswell (так же не самая распространённая платформа, может быть это первый раз когда на ней запускают FreeBSD). Для проверки гипотезы я отключил Turbo Boost в BIOS. Скорости сразу выросли до ожидаемых значений:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc     112995.52k   194942.16k   249308.27k   267746.28k   273186.25k   274103.58k
aes-256-cbc      97447.76k   151024.61k   183555.87k   194196.82k   197210.66k   197483.59k
aes-128-gcm      73681.81k   146982.29k   210065.24k   237331.46k   245448.70k   246109.53k
aes-256-gcm      67862.66k   130581.22k   179230.15k   198887.12k   204639.88k   205225.98k

Более того, turbostat стал показывать что процессор регулярно работает на частоте 2.24GHz. И при этом тот же turbostat показывал что Turbo Boost выключен, т. е. ситуация сложнее чем просто перепутанная настройка в BIOS.
Я не поленился и запустил Linux (Debian 9.5.0) и в нём поведение в точности повторилось — все числа в openssl были очень похожи на числа, полученные во FreeBSD, как с включённым так и с выключенным Turbo Boost. Более того, так как Live CD Debian загружает графическую оболочку, то я мог засечь время её запуска. И оно заметно отличалось, не в пользу включённого Turbo Boost.
Я не знаю, как это объяснить, но факт остаётся фактом — с одной стороны Turbo Boost в этой системе сломан, но, с другой, когда он выключен процессор разгоняется до частот больших, чем должен поддерживать по спецификации. Видимо, в BIOS есть какие-то ошибки, так как Turbo Boost связан с реализацией ACPI.
Учитывая производителя системы я не думаю, что кто-то будет выпускать обновления этого BIOS’а. Если вы знаете что-то про это — сообщите в комментариях.

Тесты сетевой производительности.

Дальше я стал гонять разные сетевые тесты и сравнивать результаты с предыдущим моим роутером на Atom D2500 и Intel 82574L.
Именно эти тесты заняли очень много времени и привели к откладыванию обзора в долгий ящик, так как в процессе я нашёл и помог разработчикам исправить несколько узких мест в ядре FreeBSD — так что тесты переделывались много раз, а полный цикл тестирования занимал двое суток для одного устройства, или четыре для двух. А потом я просто отвлёкся на новый год, а потом… В общем, вот обзор и пролежал 9 месяцев.

Синтетические тесты.

Описание тестового стенда.
Все сетевые эксперименты были построены по схеме, предложенной авторами проекта BSD Router Project. Для тех кому лень читать по-английски, схема выглядит так: собирается кольцо из двух мощных систем (заметно более мощных, чем тестируемое устройство), управляемого свитча и тестируемого устройства по вот по такой схеме:

При этом управляемый свитч используется как дополнительное средство контроля, что пакеты не теряются. Система GEN в этой схеме имитирует внутреннюю сеть, а система MIRROR — интернет. DUT значит «device under test» и, собственно, это и есть тестируемый роутер. GEN генерирует с помощью низкоуровневой утилиты netmap (аналог более известной библиотеки Intel DPDK) тестовый UDP-трафик, уходящий через свитч в тестируемое устройство, тестируемое устройство пересылает трафик в систему MIRROR (со всеми настроенными обработками — шифрованием, туннелированием, и так далее) а MIRROR возвращает трафик в GEN по прямому проводу. GEN сравнивает количество отосланных и принятых пакетов и подбирает максимальную скорость на которой нет потерь с точностью в 0.1%.
В моей схеме система GEN — Xeon E3-1120v2 с сетевыми картами Intel I210 и Intel X520-DA1, а система MIRROR — Xeon E3-1120v3 с сетевыми картами Intel I210 и Intel X520-DA2. Свитч — HP ProCurve 1810G-8 (J9449A). Обратный канал между MIRROR и GEN, таким образом, получается десятигигабитным и точно не является «узким местом».
Я прогнал тесты множества конфигураций — с прямым подключением к «провайдеру», с использованием GRE и IPinIP инкапсуляции, с IPSec в туннельном и в транспортном режимах. Так же я проверил 4 настройки файрволла — от его полного отсутствия (off), с фарйволлом из одного правила (open), со сложным файрволлом имитирующим мой реальный файрволл (direct) и cо сложным файрволлом c NAT (самая реалистичная ситуация). Все конфигурации были проверены в четырёх режимах: во-первых, проверялась нагрузка двумя видами трафика:

• Нагрузка, ориентированная на пропускную способность (пакеты по 512 байт).
• Нагрузка ориентированная на скорость обработки (пакеты по 64 байта)

И, во вторых, трафик посылался в одном из двух направлений:

• Трафик с небольшого числа систем «внутри» сети на множество «внешних» адресов: 4 адреса-источника по 5 портов на каждом посылают трафик во внешний мир, на 128 адресов по 7 портов на каждом, в случае включённого файрволла/NAT трафик идёт «изнутри».
• Трафик с большого числа систем «в интернете» на один «внутренний» адрес: с 253 адресов-источников на один адрес-получатель, в случае включённого файрволла/NAT трафик идёт «снаружи» через специально разрешённое перенаправление порта с внешнего адреса на «внутренний» — по сути это имитация DMZ.

Результаты.
Все результаты можно увидеть вот в этом Google Doc’е, а я подведу здесь краткий итог:

• (phy, none, off) Прямое физическое соединение, без файрволлов и шифрований. Здесь мы по скорости паритет, фактически оба девайса обеспечивают гигабит пакетами по 512 байт в любом направлении (минус накладные расходы). А вот при использовании мелких пакетов (что случается при использовании, например, протокола uTP) старое устройство обеспечивает всего ¼ максимума (375KPps когда максимум — 1488KPps), а новое — 95% от максимума когда трафик распределяется по многим получателям (1400KPps) и 80% от максимума когда трафик предназначен одному получателю (1176KPps).
  Практическая значимость этого результата не очень велика, так как такой сценарий подключения малореален при использовании этих устройств в качестве средства подключения небольшой сети к интернету. Но он показывает важное преимущество нового оборудования: там, где старая сетевая карта упирается в количество прерываний в секунду, новая живёт без проблем, особенно если трафик разнообразный и может быть распределён по нескольким очередям приёма.
• (phy, nat, off) Это реалистичный сценарий подключения к обычному домашнему провайдеру — прямое физическое подключение, использование файрволла и NAT. Здесь становится видно, как важна поддержка нескольких очередей обработки входящего трафика у новых сетевых адапетеров и как полезно иметь четыре физических ядра.
  
  Старое устройство обеспечивает 458Mbit/s и 107KPps, а новое — 880Mbit/s и 168KPps на выход. На вход разница ещё более драматична — 352Mbit/s против 792Mbit/s и, что важнее, 85KPps против 188KPps.
  В общем-то, вы можете сказать, что и старого устройства достаточно для подключения в 100-200-300 мегабит. Но это не совсем так. 85KPps — это всего 100 мегабит пакетами по 128 байтов. Так как некоторые известные протоколы реально используют такие маленькие пакеты, то вот вам и ограничение на скорость скачивания. На реальные данные, а не синтетику, мы посмотрим ниже.
• (gre, none, nat) Некоторые провайдеры требуют использования протоколов типа PPTP для подключения. Посмотрим что добавляет дополнительный слой инкапсуляции. Я выбрал GRE но вообще-то, при ядерной реализации разницы между разными вариантами инкапсуляции не видно, что и неудивительно. Опять же, посмотрим на вариант с NAT как более жизненный.
  На выход всё не так плохо — двухкратное превосходство нового оборудования сохраняется, а скорость в 533Mbit/s да и 124KPps скорее всего будет достаточно не только для дома, но и для небольшого офиса. С входящим трафиком же всё не так радужно — разница всего в треть, скорость увеличилась с 132Mbit/s до 167Mbit/s а пропускная способность с 30KPps до 40KPps.
  Декапсуляция входящего трафика ожидаемо оказывается узким местом — так как весь инкапсулированный трафик является строго трафиком точка-точка, то не работают механизмы распределения обработки по разным ядрам процессора. Весь прирост входящей скорости — это прирост скорости одного ядра процессора. Если вам предлагают подключиться на 200Mbit и выше и при этом требуют использование протоколов типа PPTP или L2TP — скорее всего ни от какого роутера за разумные деньги вы эти скорости не получите ни в каких случаях кроме скачивания больших файлов по TCP (HTTP, FTP).
• (ipsec, aes-128-cbc, direct) и (ipsec, aes-256-gcn, direct) Это сценарий VPN когда файрволл есть, а NAT вынесен на другой конец VPN — что довольно типично.
  Здесь я рассматриваю конфигурацию с двумя разными алгоритмами шифрования — уже нерекомендуемым но самым лёгким aes-128-cbc для старой системы и рекомендуемым aes-256-gcn для новой.
  Старая система упирается в скорость программного шифрования в 170Mbit/s, новая же снижает скорость всего лишь вдвое, до 500Mbit/s. С входящим трафиком в этом режиме та же проблема что и в предыдущем случае — но всё равно видно, что AES-NI позволяет удвоить скорость при использовании больших пакетов! А если не включать параною и не переходить на aes-256-gcn, то разница ещё больше.

Я не стал тестировать OpenVPN потому что по опыту знаю, что он «дороже» чем любая ядерная инкапсуляция. В случае с OpenVPN всё будет упираться не только и не столько в шифрование, как в передачу трафика из ядра к самой openvpn и обратно. Я попробовал одну конфигурацию — и даже без файрволла openvpn был медленней, чем IPSec-туннель с файрволлом.

Выводы из синтетических тестов.
По тестам получается, что, во-первых, для обычного кода (не шифрования) каждое ядро нового процессора примерно равно ядру старого. Но ядер вдвое больше. Так же гораздо лучше сетевые карты — они грамотно распределяют нагрузку по ядрам процессора в гораздо большем числе случаев, создают меньшее число прерываний, лучше работают на передачу. Плюс к этому, на новом процессоре инструкции AES-NI позволяют практически бесплатно получить сильное шифрование: на скорость обработки трафика в гораздо большей степени сказывается само наличие шифрования и файрволлов, а не конкретные алгоритмы. В общем, всё это можно было предсказать глядя просто на спецификации оборудования, но приятно подтвердить и практическое подтверждение этим выводам. Ну и в очередной раз я убедился, что реализация NAT у FreeBSD мягко говоря не самая оптимальная.

Практическая проверка.

И, наконец, практический тест: скачивание файла с помощью протокола, который использует множество UDP-пакетов. Клиент запущен на систсеме, которая во время синтетических тестов служила MIRROR’ом (вообще-то это мой NAS), а MiniPC используется как роутер. Старый роутер не позволял получить скорость больше 4.5MB/s, при этом больше роутер не мог больше ничего, даже DNS переставал работать — ядро роутера полностью загружено, и система выглядит зависшей. Попробуем с новым роутером. 8.5MB/s! И при этом новый роутер имеет двухкратный запас по мощности, все ядра загружены на 45-50%. Отлично!

Температурный режим.

Температурный режим я тестировал следующим образом: запустил openssl speed -multi 4 -seconds 3600 -evp aes-256-cgm и воткнул в радиатор (он же верхняя поверхность корпуса) кухонный термометр. Одновременно с этим я контролировал температуру ядер процессора по встроенным датчикам. Всё это происходило в комнате без сквозняков и с температурой воздуха в 22⁰C.
Через пол-часа такой нагрузки температура радиатора была в 36⁰C а температура ядер 49- 55⁰C. Следующие пол-часа температура не росла. Мне кажется, это отличный результат.

Выводы

Плюсы и минусы, конечно, субъективны.

Плюсы

• Качество изготовления — я был приятно удивлён.
• Неожиданный подарок в виде поддержки последовательного порта в BIOS.
• Все характеристики заявленные продавцом соответствуют действительности.

Минусы

• Всего два USB порта.
• 2 HDMI порта
• Странность поведения Turbo Boost.
• Дорогая доставка.

В общем-то, с первыми двумя минусам я смирился ещё до покупки. Лучше было бы иметь 4 USB порта и 1 HDMI (я не понимаю, зачем может быть надо 2xHDMI порта у устройства явно специализированного для работы с сетью), а совсем идеально — 4xUSB и 1xVGA, но такого не предлагают. А вот странности с Turbo Boost — это, пожалуй, единственная неприятная неожиданность данной покупки.

Итого

В общем, если вы знаете, зачем вам x86-совместимая коробочка с четырьмя великолепными сетевыми адаптерами — я могу смело рекомендовать данное устройство к покупке.
Спасибо за внимание. Это был мой первый уже второй обзор, но всё равно не судите строго.

Добавление через 9 месяцев после покупки и через 5 после написания основной части обзора

В общем, этот обзор мог быть готов 5-6 месяцев назад, всё уже было понятно тогда. Сейчас, когда я его редактирую и публикую, я уже пол-года живу с данным роутером в рабочем режиме. И моё мнение никак не изменилось — всё работает отлично, роутер не перегреватеся, за всё это время не было ни одной перезагрузки или краша системы или каких-то других аномалий. Устройство просто работает, управляя всеми моими домашними сетями, которых вообще-то 4, не считая подключения к провайдеру. Так же на устройстве крутится UniFi Controller, написанный на Java (!), и это не вызывает никаких пробелм с производительностью.
Первое впечатление оказалось правильным — отличный девайс для моих задач.

Замечание про мой выбор.

Да, я знаю, что за такие деньги я могу купить очень мощный (по меркам таких устройств) SOHO-роутер на архитектуре MIPS или ARM (Qualcomm/Atheros), и в нём была бы поддержка WiFi, или даже Б/У младшую модель Cisco или Juniper (но уже без WiFi).
Но как-то так сложилось, что я никогда не использовал SOHO-роутеры дома. Сначала это был модем, подключённый прямо к компьютеру, потом этот компьютер переехал под стол а рабочим стал новый, потом обычный модем поменялся на ADSL, затем вместо ADSL-модема появился Ethernet-кабель прямо от провайдера, а затем старенький и громоздкий i486 был заменен на «промышленный» Soekris Net5501, который хоть выглядел как роутер, но был внутри всё тем же PC на базе архитектуры x86. Когда мощности Soekris Net5501 стало не хватать была собрана та самая MiniITX-коробочка на базе материнской платы Intel D2500CC. Это ещё всё «осложняется» тем, что я предпочитаю FreeBSD а не Linux, так что возиться с DD-WRT и подобными прошивками мне не интересно. В общем, я знал за что я плачу и хотел именно x86-совместимую платформу.