+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Использование процессора в FQ_Codel и Mikrotik CCR

Использование процессора в FQ_Codel и Mikrotik CCR, RouterOS

discoengineer

Guest

10.02.2023 12:12:00

Привет, ребята! Недавно обновил один из своих CCR1036-2S+ до версии 7, он используется в роли роутера для моих клиентов. Я применяю политику трафика через simple queues (в основном CIR Connections) для каждого клиента. Примерно 350-400 simple queues на устройстве. Проверял fq_codel на 4 simple queues, чтобы бороться с буферблоатом, и всё работает как надо, но немного сомневаюсь, стоит ли включать это для всех очередей, потому что не уверен, как поведёт себя CPU CCR, если включить алгоритм fq_codel во все simple queues. Может, кто-то делился опытом использования этого алгоритма на таком большом количестве очередей и может рассказать, как это влияет на загрузку CPU CCR? PPPoE-сессий на этом CCR нет, только SVIs для каждого клиента, и в simple queues цель ставится на IP каждого клиента. Не поднимет ли использование этого алгоритма на таком количестве очередей загрузку CPU или не забьёт ли какой-то из ядер при пиковом трафике (максимум 2 Гбит/с в сумме)?

dtaht Guest	#2 0 25.02.2023 18:28:00 Кстати, я довольно уверен, что немало интернет-провайдеров с каналами выше 1 гбит/с ведут себя примерно так же плохо: https://blog.cerowrt.org/post/juniper/

sirbryan

Guest

27.02.2023 03:43:00

Я настроил всего пару очередей на своём CCR1036. Изначально все они были с Cake, выделялось от 600 Мбит до 2 Гбит на каждую очередь, всего штук 6 или 7. Сегодня, когда суммарная нагрузка приблизилась к 2 Гбит/с, загрузка CPU подпрыгнула до 100%. При этом все пакеты были помечены и распределены по одной из полдюжины очередей. Я сменил основную очередь на fq-codel, и загрузка упала до 18-20%. Нужно будет попробовать на ARM-маршрутизаторе (CCR2116), посмотреть, справится ли он с Cake лучше, чем 1036.

sirbryan

Guest

28.02.2023 19:28:00

Обновление: Я тоже настроил правила на RB4011 с версией 7.4.1, изначально использовал Cake для управления всем трафиком, который шел ко шести точкам доступа, каждая на своей VLAN через один и тот же Ethernet-порт в коммутаторе AP. Каждая очередь была настроена на Cake с параметрами Internet RTT, Ethernet overhead, Ack-filtering и diffserv4 (все остальные — по умолчанию). Очереди редко достигали нагрузки выше 50-70% (только одна доходила до 90%). Загрузка CPU была около 20%. Сегодня мне позвонил клиент и пожаловался, что последние четыре дня у него наблюдаются потери пакетов, хотя он на своем конце никаких изменений не вносил. Я запустил mtr, чтобы проследить путь до его радиоустройства, и обнаружил потерю пакетов прямо на маршрутизаторе. После нескольких минут настройки магистрального канала, чтобы исключить его, я отключил очереди на маршрутизаторе. Сразу же увидел улучшение — и на самом роутере, и на радиоустройстве клиента. Он тоже отметил улучшения в инструментах, которыми проверял ситуацию с ПК. Я изменил очередь на fq-codel — нагрузка на CPU уменьшилась, но потери пакетов через роутер все еще были, просто в меньшем количестве. Сейчас я отключил все очереди на RB4011, включил fasttrack, и у нас стабильно работает с нагрузкой около 6% и постоянным трафиком 200-300 Мбит/с.

sirbryan

Guest

28.02.2023 19:49:00

Обновление: и на 1036, и на 4011 я отключил очереди с шейпером и создал обычные очереди для интерфейсов. Загрузка CPU вызывала больше проблем, чем давала ощутимых преимуществ на обоих роутерах. Даже при базовых настройках Cake на 4011 я заметил рост потерь пакетов. С fq_codel на интерфейсах всё работает как положено. На 1036 Cake besteffort на двух SFP+ интерфейсах, разгоне которых примерно 1 Гбит/с, загружает CPU всего на 2-3%. С fq_codel на интерфейсах загрузка CPU около 0%. Потерь заметных нет в обоих случаях.

syadnom

Guest

28.02.2023 21:45:00

CCR2116 заметно лучше платформы Tile. Tile очень медленный для вычислений общего назначения. Много слабых процессоров – это нормально… Но ядра ARMv8 в CCR2116 должны быть примерно в 10 раз быстрее каждое для вычислений общего назначения.
Я могу получить более 8 Гбит/с в одном направлении на одном шейпере cake между двумя CCR2116 с помощью встроенного speed test от Mikrotik.

dtaht

Guest

01.03.2023 00:25:00

Потеря пакетов — не самый лучший способ оценивать работу cake или fq_codel, ведь они используют потерю пакетов для контроля перегрузки, если на концах соединения не включён RFC3168. В обмен на уменьшение задержек вы получите больше потерянных пакетов. Поэтому при использовании fq_codel и cake вы должны были заметить увеличение потерь пакетов и улучшение сетевой задержки. Вопросы, которые стоит задавать: стала ли сеть «чувствоваться» лучше? Стала ли видеосвязь и VoIP работать лучше? Если же cake действительно работает некорректно из-за нагрузки на процессор или по другой причине, и случайно вызывает потерю пакетов вместо того, чтобы разумно сбрасывать потоки, тогда вы правы, отключая его. В подобных случаях я стараюсь захватить несколько тестовых потоков и проанализировать их через wireshark. Может получиться так, что в вашем случае с включённым быстрым путем очереди, offload и приложения работают лучше, или есть баг, связанный с offload и cake, либо клиент считает текущие колебания задержек приемлемыми.

syadnom

Guest

01.03.2023 01:08:00

Дэйв, я вижу заметно меньше потерь пакетов с Cake. Cake может сбрасывать пакеты как часть управления трафиком, но за счёт контроля перегрузки другие потоки теряют гораздо меньше. Но вернёмся к теме — по моему мнению, у CCR1036 слишком слабая производительность одного ядра, чтобы работать с большими шейперами. Для автора темы: если шейперы отдельные и нет верхнеуровневого шейпера, то CCR1036 распределит шейперы по разным ядрам. Если же использовать верхнеуровневый шейпер, то всё дерево шейперов будет заблокировано на одном ядре.

chechito

Guest

01.03.2023 03:40:00

Согласен с ограниченной однопоточной производительностью архитектуры Tile, но в тесте, проведённом sirbryan, он воспроизвёл ситуацию на rb4011, который имеет гораздо лучшую однопоточную производительность (там установлен OoO CPU A15) и показывал скорость, обычную для этого роутера, делая shaping на 200-300 Мбит/с.

syadnom

Guest

#10

01.03.2023 04:14:00

Rb4011 не намного быстрее. Это 32-битный ARM v7. Тем не менее, у меня rb4011 стабильно выдает до 650 Мбит/с суммарно с cake. Я могу рассчитывать на такую скорость. Использую их для резервных каналов связи, поэтому у меня fq-codel или cake занимаются контролем перегрузки.

sirbryan

Guest

#11

01.03.2023 21:52:00

Для клиента ситуация была просто ужасной, так как он больше не мог нормально играть в свои игры. Он четыре дня подряд тестировал всё с друзьями, обновлял драйверы, возился с настройками на ПК и так далее — без результата. Задержка пинга прыгала постоянно, и в моих тестах пинга мы теряли по одному-два пакета каждые 10-15 секунд. MTR показывал 6-8% потери пакетов до роутера и 4-5% до радио. Я перенастроил очередь на 4011 и потом расскажу, как дела. После дополнительного изучения понял, что изначально я «перенастроил» систему, нагружая процессор ненужными задачами.

syadnom

Guest

#12

01.03.2023 21:55:00

Не стесняйтесь выкладывать очищенную конфигурацию. Также учтите, что использовать fasttrack вместе с ограничением трафика нельзя. Я не раз видел, как кто-то настраивал правило fasttrack в фаерволе вместе с ограничением трафика, и это работало не так, как ожидалось: ограничение применялось только к тому трафику, который проходил через другие правила фаервола, и так далее.

sirbryan Guest	#13 0 01.03.2023 22:03:00 Вот к чему я пришёл: /queue type add fq-codel-flows=10240 fq-codel-limit=1024 fq-codel-memlimit=320.0MiB fq-codel-quantum=300 kind=fq-codel name=fq-codel add cake-diffserv=besteffort cake-mpu=84 cake-overhead=38 cake-overhead-scheme=ethernet cake-rtt-scheme=internet kind=cake name=cake-interface /queue tree add limit-at=180M max-limit=180M name="LTU 192" packet-mark=no-mark parent=vlan4001 queue=cake-interface add limit-at=180M max-limit=180M name="LTU 203" packet-mark=no-mark parent=vlan4002 queue=cake-interface add limit-at=180M max-limit=180M name="LTU 110" packet-mark=no-mark parent=vlan4004 queue=cake-interface add limit-at=200M max-limit=200M name="LTU 227" packet-mark=no-mark parent=vlan4003 queue=cake-interface add limit-at=150M max-limit=150M name=Airmax packet-mark=no-mark parent=vlan4010 queue=cake-interface Сейчас есть только одно правило файрвола — сбрасывать весь трафик, который идёт на публичные IP-адреса роутера, если он приходит с не внутренних IP. Очереди показывают одинаковый объём трафика, включён fasttrack или нет. Поскольку эти очереди не привязаны к «global», предполагаю, что fasttrack должен работать. В любом случае, на загрузку процессора это особо не влияет, так как трафик сейчас чуть меньше 100 Мбит/с. (Для ясности: эта конкретная конфигурация работает без потерь пакетов пока что. Так что проблема, которую я наблюдал раньше, скорее всего была из-за того, что всё входящее на роутер как-то неправильно обрабатывалось.)

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры