- Цена: $152.39 + доставка $38.37
Это — вторая часть обзора китайского MiniPC. Первую часть обзора, описательную, смотрите тут.
А здесь — интересующие меня тесты, связанные с криптографией и работой этой железки в качестве домашнего сетевого роутера.
После первичной настройки я загрузил свою сборку FreeBSD 13 (да, я предпочитаю FreeBSD а не Linux) и прогнал интересующие меня тесты.
Начал я с того, что воспользовался встроенным в openssl 1.1.1 тестом производительности «openssl speed -elapsed -evp ».
И вот тут я был шокирован. Очень медленно. Вот, для сравнения, результаты Atom D2500
Огорчился. Решил понаблюдать за частотами в процессе теста с помощью утилиты turbostat, которая показывает честные частоты, включая те, что устанавливаются контроллером Turbo Boost. И увидел, что частоты ведут себя странно и редко поднимаются даже до 1.6GHz (напомню, Turbo Boost должен разгонять процессор до 2.24GHz). Подумав, я выдвинул гипотезу, что это может быть сочетание FreeBSD (не самая распространённая система, вряд ли китайские производители тестируют BIOS'ы на FreeBSD) и Braswell (так же не самая распространённая платформа, может быть это первый раз когда на ней запускают FreeBSD). Для проверки гипотезы я отключил Turbo Boost в BIOS. Скорости сразу выросли до ожидаемых значений:
Более того, 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’а. Если вы знаете что-то про это — сообщите в комментариях.
Именно эти тесты заняли очень много времени и привели к откладыванию обзора в долгий ящик, так как в процессе я нашёл и помог разработчикам исправить несколько узких мест в ядре FreeBSD — так что тесты переделывались много раз, а полный цикл тестирования занимал двое суток для одного устройства, или четыре для двух. А потом я просто отвлёкся на новый год, а потом… В общем, вот обзор и пролежал 9 месяцев.
Результаты.
Все результаты можно увидеть вот в этом Google Doc’е, а я подведу здесь краткий итог:
Выводы из синтетических тестов.
По тестам получается, что, во-первых, для обычного кода (не шифрования) каждое ядро нового процессора примерно равно ядру старого. Но ядер вдвое больше. Так же гораздо лучше сетевые карты — они грамотно распределяют нагрузку по ядрам процессора в гораздо большем числе случаев, создают меньшее число прерываний, лучше работают на передачу. Плюс к этому, на новом процессоре инструкции AES-NI позволяют практически бесплатно получить сильное шифрование: на скорость обработки трафика в гораздо большей степени сказывается само наличие шифрования и файрволлов, а не конкретные алгоритмы. В общем, всё это можно было предсказать глядя просто на спецификации оборудования, но приятно подтвердить и практическое подтверждение этим выводам. Ну и в очередной раз я убедился, что реализация NAT у FreeBSD мягко говоря не самая оптимальная.
Через пол-часа такой нагрузки температура радиатора была в 36⁰C а температура ядер 49- 55⁰C. Следующие пол-часа температура не росла. Мне кажется, это отличный результат.
Спасибо за внимание. Это был мойпервый уже второй обзор, но всё равно не судите строго.
Первое впечатление оказалось правильным — отличный девайс для моих задач.
А здесь — интересующие меня тесты, связанные с криптографией и работой этой железки в качестве домашнего сетевого роутера.
После первичной настройки я загрузил свою сборку 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, то разница ещё больше.
Выводы из синтетических тестов.
По тестам получается, что, во-первых, для обычного кода (не шифрования) каждое ядро нового процессора примерно равно ядру старого. Но ядер вдвое больше. Так же гораздо лучше сетевые карты — они грамотно распределяют нагрузку по ядрам процессора в гораздо большем числе случаев, создают меньшее число прерываний, лучше работают на передачу. Плюс к этому, на новом процессоре инструкции 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.
- Дорогая доставка.
Итого
В общем, если вы знаете, зачем вам 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-совместимую платформу.
