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

CAKE, FQ-codel и прочее — какой очередь в ROS7 у вас в тестах показала себя лучше всего?

CAKE, FQ-codel и прочее — какой очередь в ROS7 у вас в тестах показала себя лучше всего?, RouterOS

WeWiNet

Guest

23.09.2021 07:12:00

С учетом всех новых и теперь немного более надежных функций ROS7 я начинаю задумываться о возвращении к его использованию на некоторых своих устройствах. И одним из больших шагов вперед, который, надеюсь, будет мне полезен, являются новые доступные типы очередей для миграции большой очередной структуры на R7 и использования этих улучшений. Каков ваш опыт с новыми типами очередей и какой вы предпочитаете (и в каких случаях)? На мой взгляд, они выглядят хорошо, и на бумаге кажется, что все они значительно лучше “старых” очередей ROS6. По моим поискам в интернете, CAKE сейчас должен быть лучше всех? Но может, это всего лишь хороший маркетинг? Пожалуйста, поделитесь своим мнением, думаю, это поможет многим в такой же ситуации, как у меня.

friesedraad

Guest

21.06.2022 09:07:00

Привет, ребята! У меня нет жалоб от клиентов на медленный интернет (у меня сотни пользователей) из-за того, что какое-то одно устройство качает и забирает всю доступную скорость. Всё потому, что я использую роутер клиента на базе Mikrotik версии 6.x с комбинированным QoS через Mangle для VoIP и общей очередью total Queue, которая динамически и равномерно распределяет всю разрешённую клиенту пропускную способность по миллисекундам. Кроме того, я обеспечиваю бесплатную лицензию на супербыструю радиосвязь с задержкой 2 мс (не Mikrotik) до сектора точек доступа на вышке. Благодаря тому, что очередь настроена на роутере клиента, загрузка процессора основного роутера WISP отсутствует. Поэтому не требуется дополнительное ПО вроде Cake или CoDel.

anserk

Guest

24.06.2022 02:13:00

@WeWiNet Эта тема тоже мне интересна. Согласен, было бы здорово увидеть больше примеров из реальной жизни и отзывов о том, как очереди работают у разных людей. Я новичок в MikroTik, и чтобы лучше понять очереди, пришлось пописать на форумах, изучать документацию и собирать кусочки информации из разных источников. Конечно, это не так просто, как гайды по OpenWRT (хотя я их и не юзал), где подают готовое решение. С Моба тоже согласен — навряд ли можно просто сказать «это лучшее, остальные в топку». Общепринятое мнение, что cake лучше fq-codel, поскольку он новее и продвинутее. Но большинство пользовательских тестов онлайн сделаны на OpenWRT, а это другая платформа. Например, cake в RouterOS нельзя использовать без HTB, хотя у самого cake есть свой шейпер. Влияет ли это на итог — вопрос открытый. При всех моих тестах с Waveform и Flent cake так и не показал лучшие результаты, чем fq-codel, поэтому пока отдаю предпочтение второму. Только скорость загрузки была немного лучше, а задержки под нагрузкой — хуже. Способов настройки очередей уйма, так что результаты могут отличаться в зависимости от конфигурации и сценариев. Отмечу, что я использую интерфейс HTB (а не глобальный), чтобы можно было оставить включённый fasttrack. Само по себе очередь сильно CPU не грузит (для моего канала), а вот fasttrack — включён или выключен — меняет нагрузку на процессор кардинально. В приложении — графики из Flent, который позволяет смотреть результаты в сравнении. Было бы круто увидеть больше результатов от других пользователей, примеры из других тем мне очень помогли при экспериментах. Конфигурация Cake:
/queue type
add cake-ack-filter=filter cake-flowmode=dual-srchost cake-mpu=64 cake-nat=yes cake-overhead=18 cake-overhead-scheme=docsis kind=cake name=cake-up
add cake-diffserv=besteffort cake-flowmode=dual-dsthost cake-mpu=64 cake-overhead=18 cake-overhead-scheme=docsis kind=cake name=cake-down
/queue tree
add bucket-size=0.01 max-limit=118M name=download packet-mark=no-mark parent=bridge1 queue=cake-down
add bucket-size=0.01 max-limit=11M name=upload packet-mark=no-mark parent=ether1 queue=cake-up
Cake 2 на графиках — та же конфигурация, только flowmode установлен в triple-isolate для обоих направлений. Конфигурация fq-codel:
/queue type
add fq-codel-limit=1000 fq-codel-quantum=300 fq-codel-target=12ms kind=fq-codel name=fq-codel
/queue tree
add bucket-size=0.01 max-limit=118M name=download packet-mark=no-mark parent=bridge1 queue=fq-codel
add bucket-size=0.01 max-limit=11M name=upload packet-mark=no-mark parent=ether1 queue=fq-codel

dtaht

Guest

24.06.2022 16:59:00

Очень хороший пост. Но причина того, почему у вас наблюдается худшая задержка ping UDP BK и худшее среднее время задержки в тесте rrul cdf для cake, в том, что приоритет у трафика TCP на переднем плане выше, чем у фонового трафика, а именно этого вы и хотите добиться. Тест rrul_be или использование cake в режиме besteffort, скорее всего, покажут эквивалентные результаты. Интегральный шейпер cake лучше, чем htb + fq_codel, но в этой среде его сложно применить. Основные особенности cake — это справедливое распределение по хостам, фильтрация ACK, интегральный шейпер и поддержка diffserv. Если вам это не нужно (а во многих случаях не нужно), используйте fq_codel. Тестирование справедливого распределения по хостам проводится в тестах flent rtt_fair_var. -H A -H B -H A -H A покажет, что машина «B» получает примерно такой же объем пропускной способности, как и машина A. Ирония в том, что режим фильтрации ACK даёт вам примерно на 15% больше пропускной способности при загрузке на уровне такой асимметрии, но это происходит за счет измеренной задержки в этом тесте (потому что меньше мелких пакетов для перемешивания). Фильтрация ACK становится всё более важной при соотношениях выше 10x1, и абсолютно необходима при 20x1 или выше для соотношений загрузки/выгрузки. fq_codel и cake в целом используют одинаковые базовые алгоритмы FQ и AQM. Cobalt (производный codel в cake) чуть более точен и имеет некоторые защиты от неотзывчивого трафика, которыми fq_codel не обладает. Моя главная задача обычно заключалась в том, чтобы заменить все FIFO, RED и SFQ в мире на алгоритмы, основанные на fq_codel, и мне даже приятно, что вы считаете, что борьба идет между fq_codel и cake. Мне действительно хотелось бы, чтобы больше людей попробовали fq_codel или cake, работающие напрямую на интерфейсе без параметра пропускной способности или шейпера… и на более простых тестах, чем rrul или rtt_fair.

dtaht

Guest

24.06.2022 17:05:00

График cake_2 выше, похоже, показывает, что во время теста что-то пошло не так дважды — либо был какой-то другой трафик, либо где-то произошёл сбой. Сравнительный график этого теста покажет ниже пропускную способность и выше задержку — поэтому мы сначала показываем подробные результаты, а уже затем сводные CDF или графики с колонками. cake требует больше ресурсов процессора, чем fq_codel, так что вполне возможно, что и у него случился сбой! Если он постоянно зависает, а fq_codel нет — это тоже важный факт. Пытаться разобраться или улучшить ситуацию со своей стороны сложно, и мне очень нравится, что всё больше людей делают всё больше тестов с flent.

dtaht Guest	#6 0 24.06.2022 17:15:00 fq-codel-target=12ms не должен быть нужен при скоростях выше 4 Мбит. По умолчанию стоит 5 мс. Но изменяется ли из-за этого у вас пропускная способность?

anserk

Guest

25.06.2022 15:48:00

Вот ещё тесты. Я разобью их на несколько постов для лучшей организации. Графики были созданы на 4K-мониторе с высоким DPI, так что не уверен, как они будут выглядеть на экранах с меньшим DPI. Шрифт может показаться немного мелким, но в целом разрешение лучше, так что графики можно увеличить. Значение 12 мс для fq-codel взято из рекомендации, которую я где-то читал. Мои незагруженные пинги до шлюза ISP по умолчанию составляют 9–11 мс, поэтому цель по более низкой задержке не имела смысла. По крайней мере, так я это понял, хотя могу и ошибаться. Похоже, особой разницы нет. Настройки fq-codel для всех тестов ниже. Цель 5 мс указана на графиках.

/queue type
add fq-codel-limit=1000 fq-codel-quantum=300 fq-codel-target=12ms kind=fq-codel name=fq-codel

/queue tree
add bucket-size=0.01 max-limit=118M name=download packet-mark=no-mark parent=bridge1 queue=fq-codel
add bucket-size=0.01 max-limit=11M name=upload packet-mark=no-mark parent=ether1 queue=fq-codel

rrul-2022-06-25T134216.270710.fq-codel-12ms.flent.gz (114 KB)
rrul-2022-06-25T134535.470270.fq-codel-5ms.flent.gz (115 KB)

anserk

Guest

25.06.2022 15:51:00

Сравнение между fq-codel и cake. Я не использовал стандартный overhead для docsis (как в предыдущих тестах), потому что читал, что он может быть 22, а не 18. Установить его выше, чем нужно, не так критично, а занижать может привести к проблемам. Это основано на том, что я нашёл в интернете. Поэтому я выставил вручную 22. Настройки cake для всех тестов. Besteffort для загрузок в обоих тестах, diffserv3 или besteffort для выгрузок, как указано на графиках.

/queue type
add cake-ack-filter=filter cake-flowmode=dual-srchost cake-mpu=64 cake-nat=yes cake-overhead=22 kind=cake name=cake-up
add cake-diffserv=besteffort cake-flowmode=dual-dsthost cake-mpu=64 cake-overhead=22 kind=cake name=cake-down

/queue tree
add bucket-size=0.01 max-limit=118M name=download packet-mark=no-mark parent=bridge1 queue=cake-down
add bucket-size=0.01 max-limit=11M name=upload packet-mark=no-mark parent=ether1 queue=cake-up

rrul-2022-06-25T135148.045882.cake_up_diffserv3.flent.gz (118 KB)
rrul-2022-06-25T135344.229643.cake_up_besteffort.flent.gz (118 KB)

anserk

Guest

25.06.2022 15:55:00

Сравнение с использованием теста rtt_fair_var. Я использовал серверы West и EU, как вы и советовали: 3 -H переключателя для одного сервера и 1 -H переключатель для другого. Наверное, я что-то сделал не так, потому что сервер EU получает такую же пропускную способность, как и каждый из серверов West. Я ожидал, что 3 потока West вместе будут иметь такую же пропускную способность, как один EU.

rtt_fair_var-2022-06-25T135839.408470.cake_be_fair_var.flent.gz (84.3 KB)
rtt_fair_var-2022-06-25T140500.637023.fq-codel_fair_var.flent.gz (82.4 KB)

anserk

Guest

#10

25.06.2022 16:01:00

Деревья очередей отключены, лимитов по полосе пропускания нет. Используются прямые очереди интерфейсов. Для загрузки — ether1. Для скачивания я пытался использовать bridge (обращённый к моей локальной сети), но RouterOS выдал ошибку «failure: non rate limit queues are useless on this interface». Поэтому для этого теста очередь была поставлена на ether2, к которому был подключён тестовый ПК (через неуправляемый коммутатор). В реальной жизни это, наверное, работать не будет, так как все потоки скачивания обрабатывались бы отдельно на каждом интерфейсе ether. Так что это скорее для академических целей. В этом тесте cake использовал значительно больше процессорных ресурсов, чем fq-codel — в 2,5–3 раза больше, хотя в целом нагрузка была всё ещё невысокой, около 10%. Также я добавил данные теста fq-codel для сравнения. Конфигурация без ограничений ведёт себя так, будто никакие технологии очередей вообще не применяются, задержки зашкаливают.
rrul-2022-06-25T141256.677726.cake_no_limits.flent.gz (120 KB)
rrul-2022-06-25T141018.542465.fq-codel_no_limits.flent.gz (120 KB)

dtaht

Guest

#11

26.06.2022 17:01:00

–socket-stats будет напрямую отслеживать tcp rtt для загрузок и предоставит варианты графиков, чтобы, например, посмотреть разницу между целевыми 5 мс и 12 мс. Хотя может показаться, что хочется чуть больше пропускной способности, чем есть, меньшие очереди ведут к лучшему поведению при возникновении коллизий хэша. Цель codel — задержка в очереди, а не задержка на маршруте. Интервал codel должен быть установлен примерно на 98% от максимальной наблюдаемой задержки на маршруте, стандартные 100 мс хорошо подходят для задержек по всему миру (240 мс), но начинают хуже работать при > 280 мс. cake ack-filter на загрузке покажет больший пинг и большую пропускную способность, как я и говорил, при вашем соотношении 10 к 1. Ситуации, когда я надеялся на тест с полной скоростью канала, — это на самом деле тест от устройства с такой же полной скоростью канала, а не через вашу ужасную (но типичную) линию от провайдера. Спасибо за сравнительные графики! Это сильно облегчает жизнь, правда? Сходите в местное кафе или гостиницу и посмотрите, насколько там плохой вайфай…

dtaht Guest	#12 0 26.06.2022 17:05:00 Что касается отсутствия справедливого распределения по хостам, не пройдёте ли вы через NAT на этом роутере? Если да, используйте опцию nat. Также сделайте тройную изоляцию.

dtaht Guest	#13 0 26.06.2022 18:23:00 Мне понравилось видеть стабильную и улучшенную пропускную способность на спуске по сравнению с перезагруженными тестами при подъёме.

shaw627

Guest

#14

08.09.2022 03:28:00

Думаю, вот правильный способ использовать CAKE. Нужно просто добавить CAKE на ether1 для исходящего трафика и на ether2 для входящего.

Я не могу настроить CAKE на виртуальном мосту для загрузки, но, возможно, добавление свитча на физический ether2 сработает. Это может работать лучше, чем HTB+FQ_CODEL.

Моя пропускная способность 500M/250M (FTTH EPON PPPoE MTU=1492), upload = cake, download = queue tree + fq_codel↓↓

Я заметил, что время реакции CAKE на снижение задержек в самом начале всегда было быстрее, чем у htb+fq_codel. Тестировал на AC2 с включённым Fasttrack.

anserk Guest	#15 0 14.09.2022 21:38:00 Спасибо за информацию, действительно, можно использовать разные типы очередей для загрузки и скачивания.

donkeyKong

Guest

#16

22.09.2022 20:35:00

Согласен. Насколько я понимаю, CAKE должен использоваться самостоятельно, так задумано, и у него есть встроенный планировщик пакетов. У меня интернет 2000 Мбит/с на скачивание и 600 на отдачу, и я использую только CAKE в качестве очереди интерфейса — вижу намного лучшие результаты (меньше буферной задержки), чем без него. К тому же, меньше нагрузка на процессор: на CCR2004-16G при тесте на отдачу (600 Мбит/с) потребляется около 15% ресурсов CPU, тогда как с простыми очередями загрузка процессора поднимается примерно до 19%.

matices Guest	#17 0 24.10.2022 02:55:00 Спасибо за информацию. Пинг уменьшился, всё работает отлично.

Читают тему

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