Системный журнал может использовать не более одного ядра, поэтому скорость ограничивается. Возможно, это ошибка, связанная с вводом-выводом, поэтому, когда запросов слишком много, журнал не успевает обрабатывать их.

Небольшое обновление по текущему вопросу. У меня было много переписки с техподдержкой UI. Это закончилось примерно неделю назад. После всех тестов прошивки, перезагрузок устройства, повторных проверок они пришли к выводу, что проблема у моего провайдера. Потому что при режиме NAT на роутере я мог получить практически полную скорость с UDM Pro. Оказалось, что когда роутер стоит в режиме IP Pass-through, UDM Pro не справляется с нагрузкой: скорость срезается и не достигает максимально возможной линии. А в режиме NAT, даже с включённым IPS, проблем практически нет. Они говорят, что, видимо, проблема на стороне провайдера и посоветовали проверить, обновлен ли у них MAC-адрес UDM Pro. Но это странно — ведь между провайдером и UDM Pro стоит их модем. IP-адрес выдается через DHCP провайдерскому роутеру и если тот в режиме IP Pass-through, IP всё равно через DHCP выдается на UDM Pro. Если я правильно понял, мне надо сообщить провайдеру MAC-адрес UDM Pro, хотя им вообще всё равно — ведь DHCP работает независимо. И IP у меня даже не статический, иногда меняется каждый день.

Так что если оставить режим NAT, появляется небольшая задержка и джиттер, зато скорость почти максимальная. Если же отключить NAT на роутере провайдера, скорость падает до 400–500 Мбит/с из 600 доступных.

Я по-прежнему считаю, что с UDM Pro такой проблемы быть не должно, потому что если просто поставить простой свитч после модема провайдера, то даже в режиме IP Pass-through я получаю полные 72 МБ/с (600 Мбит/с) на скачивание. Проблема только в UDM Pro — он не справляется с этим трафиком.

Да, на самом деле у меня получается гораздо хуже (в основном нестабильно), потому что при таком запуске пропускается локальный тест UDM. Редко удаётся получить больше 900/900 Мбит/с на большинстве браузерных тестов (возможно, это проблема Edge, Firefox работает чуть получше, но всё равно не так хорошо, как в приложениях). Самые стабильные результаты у меня получаются с помощью теста Ookla в приложении на ПК или приложения WiFiMan на планшете/смартфоне. Запуск iPerf или LAN-speed-test (тоже приложения) для проверки скорости с NAS тоже довольно надёжен, на мой опыт.

Я могу стабильно получать 910-940/930-950 Мбит/с (конечно, тесты скорости WAN не совсем точные, но достаточно близко для наших целей) через проводное соединение, весь день напролёт, используя приложение speedtest.net. Аналогично получаю результаты при LAN-тесте на свой NAS. По сравнению с этим, с моим WiFi6 точкой доступа и быстрым планшетом через WiFiMan скорость достигает 600-700 Мбит/с. Было бы классно, если бы существовала версия этого инструмента для Windows, чтобы можно было проводить проводные тесты с большей стабильностью, учитывая, что он проверяет и скорость WAN, и локального хранилища на UDM.  

Такой тест с одним клиентом едва нагружает процессор — около 20%. Если же подключить два или три клиента (два с нагрузочным тестом и один, который постоянно пингует, чтобы следить за задержками), загрузка CPU поднимается до примерно 40%, при этом WAN у меня полностью загружен. С тестами на NAS нагрузка на процессор не превышает 25-30%, даже при нескольких нагрузочных клиентах.

Хотя это может и не помочь автору темы, это показывает, что UXG способен выдавать почти гигабитную скорость при включенных всех настройках (@mhatle прав — отключайте smart queues и проверяйте корректность настроек провайдера), но при этом, похоже, есть проблема с тем, как интерфейс обрабатывает тесты скорости, и результаты меняются по какой-то неизвестной причине. Хотел поделиться своим опытом.

Сначала уточню, это НЕ про PPPoE — я много раз писал об этой проблеме в другой теме. Вот ссылка для ясности, но на всякий случай: этот пост показывает, что тесты с нативным PPPoE на UXG (без роутера CTL спереди) дают такие же результаты, как на скриншотах ниже (подробнее в той теме с iperf и прочим): https://community.ui.com/tracker/UDM-Throughput-Degradation/1c94f307-0519-4c65-94bd-58b2f9fb65a9#comment/cbf44ee4-edb1-4a91-b653-54ac6c34830b

Хочу поделиться новыми тестами. У меня есть и 1 гигабитный CenturyLink через оптику, и 1G/40M Comcast. Сейчас я использую роутер от CTL перед UXG Pro, чтобы разгрузить PPPoE (эта тема не про PPPoE, по ней уже много постов, включая мои — публикую здесь, потому что связано). И, кстати, для всех тестов включен полный IPS (уровень 5).

Версии и прочее (учтите: использую Ubiquiti SFP, и чтобы его распознал, надо вручную задать скорость и дуплекс и отключить autoneg, не уверен, можно ли этот режим сохранить принудительным обновлением UXG, потому что результаты меняются и нужно дальше тестировать):

Firmware: 1.9.0-2.3484

Версия сети: 6.2.17

CloudKey G2 (не plus): 2.1.7

# ip a | grep eth0

4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc mq state UP group default qlen 1000

   inet 192.168.0.3/24 scope global dynamic eth0

Для подкрепления, вот скриншот с настройками MSS на WAN1 (CTL):

Скоростные тесты с ноутбука (1 гиг) напрямую, подключенного в LAN1 на UXG, через CTL и speedtest.net (с серверами CTL) стабильно показывают 920–930 Мбит/с по обе линии. Тесты по Comcast (WAN2), подключенному через мой DOCSIS 3.1 модем в режиме моста по витой паре, показывают примерно 930 Мбит/с скачка и ~40 Мбит/с отдачи.

Когда тестирую скорость с панели управления UniFi (старой или новой), на CTL всегда вижу не более 600 Мбит/с скачать и около 930 Мбит/с отдача. На Comcast — около 930 Мбит/с скачать и 40 Мбит/с отдача. Повторю: PPPoE не обрабатывается на UXG.

Я вручную выставил MTU на WAN1 (eth0) 1492, MSS clamping на авто, 1452 и выключал — ничего не меняется. Очень странно, почему результаты такие разные. По сути, UXG «думает», что оба канала — это Ethernet с DHCP-IP. Единственное отличие — это потеря 8 байт, но это никак не объясняет разницу в скорости, а при фиксированном MTU 1492 байта фрагментации вообще не должно быть, но честно говоря, такие же результаты получаю даже без изменения MTU, при этом скорость отдачи в порядке.

Вот скриншоты тестов CTL и Comcast в панели управления и на speedtest.net, MSS на авто (но смена настроек не влияет), MTU принудительно 1492 на WAN1 (eth0):

В панели управления, CTL

В панели управления, Comcast

Speedtest.net CTL, прямое подключение ПК к UXG LAN1 на 1 гигабит

Speedtest.net Comcast, прямое подключение ПК к UXG LAN1 на 1 гигабит

Хорошая новость — переключение на резервный канал (failover) работает вполне нормально (потеря 3–5 пакетов). Было бы круто добавить балансировку нагрузки, но это уже другая история...

Небольшое обновление по этому поводу: когда заходишь в unifi-os shell и запускаешь top, процессor просто уходит в разнос — systemd-journal вылетает на 100%, при этом node тоже сильно загружен, а java на третьем месте. Похоже, что каждый раз, когда systemd-journal достигает пика в 100%, скорость сети начинает тормозить. Опять же, если просто подключить мой ПК напрямую к роутеру, проблем с падением скорости нет. Всё ещё общаюсь со службой поддержки, они посоветовали обновиться с версии 1.9.2 до 1.9.3, но эффекта это не дало.

@kjambuna, когда пользуешься соединением, зайди по ssh на свой udm pro, введи команду unifi-os shell и посмотри загрузку CPU. Запусти top, затем нажми s, чтобы изменить задержку обновления, и введи, например, 0.5, чтобы видеть, если что-то резко нагружается за короткое время, а не каждые 3 секунды, как по умолчанию.

В эти графики и виджеты UI особо не верю, особенно на данном этапе. Похоже, они сейчас в каком-то "переходном состоянии" — между новым UI, который всё ещё в альфе (но при этом стоит по умолчанию, интересно, да?), и старым UI, по которому некоторые из команды писали в обсуждениях, что "почти ничего не исправляют".

Мониторю через SSH (top, htop, да что угодно) — вижу загрузку CPU от 14 до 36%, когда запускаю два одновременных нагрузочных теста по 1Гбит/с каждый. У меня основной канал — оптика на 1 Гбит, а дополнительный кабель (250/5, с гораздо большим пингом) работает в режиме полупереключения нагрузки, в основном для IPv6 (поставщик оптики с тормозами с этим распространением). Я провёл три таких теста, результаты одинаковые — максимум 36%, но обычно CPU висит в районе 15-20%, при этом я гонял немалый объём данных (примерно 900-960 Мбит/с в обе стороны).

Похоже, что offload у вас работает как-то не совсем правильно, по крайней мере на первый взгляд. Вникать, что именно жрёт эти циклы, я бы отдал специалистам по Linux-ядру (я в этом плане не спец, я больше по Windows-ядру). Без этой экспертизы сложно понять, баг это или осознанное решение для некоторых схем offload (PPPoE — самый любимый народом на форуме вариант).

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