http://mikrotik.moscow Новое в теме Небольшие быстрые заметки по настройке Cake форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Mon, 03 Aug 2026 07:51:25 -0400 Небольшие быстрые заметки по настройке Cake RouterOS в форуме RouterOS.
В прямом ответе на ваш вопрос: я не знаю ни одного драйвера устройств для Linux mainline, который бы делал что-то умное с LTE, вроде BQL или AQL. Большинство таких драйверов вне основного древа разработки, и я надеюсь, что где-то в какой-то ОС, будь то Android или iOS, там есть разумная логика. Когда-нибудь кто-то проведёт исследование реальной задержки очередей в обычных телефонах… У Apple есть новый инструмент (командная версия называется networkQuality, iOS-версия находится в настройках разработчика). Я давно измеряю худшую задержку под нагрузкой для своего LTE-соединения на лодке и настраиваю cake под это. Мне не важна пропускная способность, меня волнует, чтобы видеоконференции шли гладко. Я экспериментировал с серией подкастов, постепенно усложняя параметры cake, чтобы понять, как это действительно воспринимают пользователи — и предсказуемо последние пару получились ужасными. Следующая серия подкастов будет с чем-то вроде этого скрипта для OpenWrt.
14.11.2021 17:55:00, dtaht.]]> http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425867 http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425867 Sun, 14 Nov 2021 17:55:00 -0500 RouterOS Небольшие быстрые заметки по настройке Cake RouterOS в форуме RouterOS.
Одно из обсуждаемых на том форуме openwrt вопросов — использование инструмента, похожего на tcptrace, а ещё — глубокий анализ раздутого tcp rtt с помощью ebpf и одной из инноваций Kathie Nichol, pping. Вот информация по ссылке: https://lists.bufferbloat.net/pipermail/bloat/2020-June/015772.html Однако у Mikrotik с поддержкой ebpf всё очень, очень плохо. Инструмент, похожий на tcptrace, я называю wtbb, но он не развивается активно и страдает от нехватки финансирования. Для меня ужасные проблемы с очередями в lte — вопрос номер один, но похоже, что в 5g-мире, где все хвастаются низкой задержкой, почти никто не занимается исследованием или решением проблем с задержками в очереди. И знаешь, я терпеть не могу работать бесплатно, лучше займусь вайфаем.
14.11.2021 17:50:00, dtaht.]]> http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425866 http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425866 Sun, 14 Nov 2021 17:50:00 -0500 RouterOS Небольшие быстрые заметки по настройке Cake RouterOS в форуме RouterOS.
re - mpls. Я понятия не имею, достаточно ли хороший flow dissector в Linux, чтобы так глубоко разбирать пакет и получить пользу от этого (могу проверить). Он справляется с ppp-oe. Если он не сможет определить «потоки», а, судя по всему, в MikroTik нет способа получить статистику, то в итоге у вас будет одна очередь, независимо от того, насколько разнообразен ваш трафик — это можно увидеть с помощью (в fq_codel или sfq) команды tc -s class show. В противном случае вы можете попробовать закинуть кучу пакетов из разных потоков и посмотреть, выходят ли они в том же порядке. Если fq окажется невозможным, я бы попробовал использовать pie или codel AQM отдельно, чтобы держать размеры очередей под контролем. Вы вполне можете использовать cake с опцией flowblind, и, возможно, получить какую-то дифференциацию сервиса через diffserv, но по нагрузке на процессор будет дешевле попробовать htb + aqm.
14.11.2021 17:45:00, dtaht.]]> http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425865 http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425865 Sun, 14 Nov 2021 17:45:00 -0500 RouterOS Небольшие быстрые заметки по настройке Cake RouterOS в форуме RouterOS.
Насколько я понял, они проводят тестирование с помощью shell-скриптов и icmp (ping). Есть ли более надёжный метод, в котором эта логика встроена непосредственно в драйвер устройства? Мне очень хочется, чтобы это работало со всеми типами беспроводных технологий, которые страдают от сильных колебаний пропускной способности, а в моём случае особенно для LTE и его "приятелей".

P.S. И IEEE 802.11, и LTE (RAN) имеют множество показателей производительности в реальном времени, которые отлично подойдут для настройки.
14.11.2021 13:03:00, Larsa.]]> http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425864 http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425864 Sun, 14 Nov 2021 13:03:00 -0500 RouterOS Небольшие быстрые заметки по настройке Cake RouterOS в форуме RouterOS.
У меня вопрос по приоритетному QoS в cake. Пакеты IP наших клиентов инкапсулируются в PPPoE-кадры, затем в Ethernet-кадры (туннель VPLS), к которым добавляются два MPLS-лейбла, а сверху прикрепляется VLAN-заголовок как внешний слой. Может ли cake прочитать DSCP из IP-пакета при таком многослойном инкапсулировании? Сейчас на внешнем VLAN-заголовке выставлен правильный приоритет VLAN для нужного нам приоритета обработки пакета, но, насколько я понимаю, cake не умеет читать VLAN-priority (PCP)? Кратко по ситуации: это WISP, в бэколе примерно 90% трафика — VPLS с MPLS-лейблами (около 400 клиентов), и тег VLAN настроен с приоритетом, по которому надо обрабатывать пакеты. У нас восемь классов приоритетов, в зависимости от типа клиента (retail или enterprise) и вида трафика, и мы используем HTB, чтобы распределять пакеты по нужным очередям на основе VLAN-priority в этом бэколе. Сейчас на RouterOS v6 мы находим полезными только fifo и red, но с ними уже при нагрузке около 850 Мбит/с на 1 Гбит/с линке начинают теряться retail-пакеты, хотя канал полностью не загружен. Надеюсь, что в RouterOS v7 что-то из codel, fq_codel или cake поможет добиться скорости близкой к максимальным 1 Гбит/с. Я пробовал использовать sfq на RouterOS v6 для этого бэкола, но производительность сильно упала, скорее всего, потому, что sfq запутался из-за MPLS-лейблов и поместил весь MPLS-трафик (90% всего) в один поток. В интернете мало информации о том, как люди очередуют пакеты с MPLS-лейблами с помощью codel/fq_codel/cake.
12.11.2021 22:40:00, mducharme.]]> http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425863 http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425863 Fri, 12 Nov 2021 22:40:00 -0500 RouterOS Небольшие быстрые заметки по настройке Cake RouterOS в форуме RouterOS.
Хорошее замечание. Параметр bandwidth должен быть опциональным для cake. Что касается того, можно ли разумно запустить LTE-интерфейс на полной скорости, большая часть драйверов Linux для этого была ужасно переизбыточно буферизирована, поэтому обратное давление приходило слишком поздно. Надеюсь, что что-то вроде AQL или BQL появится для LTE-интерфейсов, и в openwrt-пространстве сейчас идёт много многообещающей работы по активному определению пропускной способности LTE: https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848/482. Аналогично, fq_codel для Wi-Fi поддерживался только на 5 чипсетах, везде, где его можно использовать вместо шейпера, это большой плюс. (https://lwn.net/Articles/705884/). Что касается установки шейпера типа cake перед этим, насколько я понимаю, рынок mikrotik — это в основном провайдеры, а провайдеры продают сервисы по уровням, так что в этом случае cake будет кстати.

Что касается noqueue, offload-функции обычно «забирают» все пакеты, и их просто не видно. Было бы здорово, если бы команду очередей улучшили, чтобы она использовала статистику tc -s qdisc — показывала бы потерю пакетов, накопление и статистику ECN. Статистика по Wi-Fi спрятана глубоко в /sys/kernel/debug/iee*/phy*/aqm и в нескольких других файлах aqm на каждого клиента.

Немного о себе: я был оператором WISP в Никарагуа, обновил магистраль до wireless-n, но она ломалась (до 30 секунд задержки) во время дождей, а в Никарагуа они длятся больше двух месяцев. Поэтому моя изначальная мотивация в борьбе с bufferbloat была починить фиксированную беспроводную связь, а потом вернуться на ту гору, серфить и купаться, как только исправления попадут в ядро Linux. Но мои попытки уйти на покой всё время срывались — последний раз, когда я пытался завязать, в Никарагуа почти переворот случился, и казалось проще и безопаснее просто продолжать чинить весь интернет для всех… и стараться быть впереди новых развертываний вроде этого, чтобы они сделали всё правильно... Я часто скучаю по той горе. Видеть, как Comcast сделал всё правильно, было круто (https://arxiv.org/abs/2107.13968), а наблюдать, как Starlink ошибается (https://www.youtube.com/watch?v=c9gLo6Xrwgw), — совсем нет. Так что уйти на пенсию я уже не могу. Но, судя по всему, mikrotik уверенно движется к правильному решению — и это радует.
12.11.2021 22:34:00, dtaht.]]> http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425862 http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425862 Fri, 12 Nov 2021 22:34:00 -0500 RouterOS Небольшие быстрые заметки по настройке Cake RouterOS в форуме RouterOS.
Привет, Дейв (dtaht)!

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

Современная версия CAKE поддерживает новый код точек diffserv LE. Очень хотелось бы увидеть поддержку этого в Mikrotik, учитывая, насколько проблемным оказался CS1, и это же совсем маленькое исправление +1! Было бы здорово, если бы ты мог оформить запрос на https://help.mikrotik.com, чтобы всё было официально.

Было бы здорово, если бы в Mikrotik появился какой-то способ опрашивать и отображать статистику из fq_codel — полностью согласен. В качестве первого шага Mikrotik мог бы поправить счётчики очередей, например, при включении CAKE для всех исходящих WiFi-очередей в RouterOS 7 (/queue type set wireless-default cake-diffserv=diffserv4 cake-flowmode=dual-dsthost kind=cake) мы всегда видим: /queue monitor queued-packets: 0 queued-bytes: 0

Начиная с RouterOS 7.1rc5, параметр «cake-bandwidth» по-прежнему обязателен для LTE-интерфейсов. Ты считаешь, что всё ещё есть смысл использовать CAKE AQM без ограничения пропускной способности? Возможно, Mikrotik об этом просто не знает.

Спасибо, Дэн
12.11.2021 07:10:00, DanielJB.]]> http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425861 http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425861 Fri, 12 Nov 2021 07:10:00 -0500 RouterOS Небольшие быстрые заметки по настройке Cake RouterOS в форуме RouterOS.
Этот патч улучшает работу cake с локально завершённым VPN: https://lists.bufferbloat.net/pipermail/cake/2020-May/005257.html
31.10.2021 10:12:00, dtaht.]]> http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425860 http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425860 Sun, 31 Oct 2021 10:12:00 -0400 RouterOS Небольшие быстрые заметки по настройке Cake RouterOS в форуме RouterOS.
Привет, один из участников разработки cake здесь. Рад, что вы наконец-то начали его использовать, но у меня есть несколько замечаний: современная версия cake поддерживает новый diffserv LE кодпоинт. Мне очень хотелось бы видеть поддержку этого в Mikrotik, учитывая, насколько проблемным оказался CS1, и патч для этого совсем небольшой. Одна из особенностей cake — он работает одинаково хорошо как на полной пропускной способности, так и с включённым шейпером, так что можно получить классификацию fq по хостам/потокам, diffserv и т.д. Мне очень интересно узнать результаты, когда вы попробуете запустить его или fq_codel на полной скорости, а не с шейпером. fq_codel сейчас по умолчанию стоит на всех интерфейсах вместо pfifo_fast в большинстве современных Linux. Было бы здорово, если бы кто-то проверил cake через серию тестов flent rrul или нагрузочных iperf-тестов, сделал дампы трафика и построил графики RTT, особенно на топовом железе Mikrotik. Он особенно полезен с работающим BQL в драйвере устройства.

https://help.mikrotik.com/docs/display/ROS/Queues не поддерживает опцию gso-splitting. При использовании шейпера ниже 1 Гбит gro "суперпакеты" автоматически разбиваются обратно на пакеты (и затем перемешиваются с другими потоками), а при отсутствии шейпера или скорости выше 1 Гбит — нет. Если у вас достаточно CPU — разбивайте суперпакеты. Если маршрутизатор выполняет NAT, попробуйте опцию nat. Однако она не работает с некоторыми типами offloaded NAT. Если у вас сильная асимметрия по пропускной способности (больше 10 к 1), попробуйте опцию ack-filter на более медленной стороне канала. Это становится крайне необходимым при таких больших пропорциях, подробнее: https://blog.cerowrt.org/post/ack_filtering/

Было бы неплохо, если бы Mikrotik смог опрашивать и отображать статистику fq_codel по очередь загрузки, переназначениям, потерям и меткам, а также аналогичную статистику для cake. Открытие этой информации для пользователей повысит понимание роли потери пакетов (и маркировки) в контроле сетевой задержки. tc поддерживает вывод в формате JSON, и множество инструментов могут это парсить. Взгляните на энтузиазм сообщества Starlink по сбору таких данных... Очень хотелось бы видеть хотя бы статистику drop у пользователей Mikrotik.

При шейпинге DSL особенно важно правильно настраивать тип "фрейминга" линии, но также полезно для кабельных модемов выставлять параметр docsis. Так вы максимально приблизитесь к реальной скорости кабельного модема, а не будете терять 5-15%. В случае DSL без правильной настройки получить стабильную заданную скорость невозможно, или, по крайней мере, очень сложно — именно это я и имею в виду. Если не собираетесь использовать diffserv, применяйте режим cake besteffort, чтобы экономить память и CPU. Чтобы ещё больше снизить нагрузку на CPU, не используйте опции ack-filter и nat.

Существует множество опций fq по хостам и потокам, зависящих от вашей задачи регулировки трафика между IP-адресами и портами. На входе используйте wash, если не доверяете diffserv маркировке со стороны провайдера. Это достаточно жёсткий инструмент, и лучше, чтобы вы заранее общались с пользователями о том, как вы обрабатываете diffserv, и давали им возможность настраивать трафик самостоятельно, меняя маркировку с 0 (besteffort) только при необходимости. Есть опубликованный гайд по трафику Zoom и другим приложениям. Wash на выходе используйте, если вы не соблюдаете соответствующие RFC. Cake старается следовать множеству конфликтующих diffserv RFC, и в эпоху популярности видеоконференций модель cake diffserv4 ближе к тому, как это делает Wi-Fi роутер. Подробнее: https://www.w3.org/TR/webrtc-priority/ — малоиспользуемая возможность в webrtc.

Несмотря на все эти разговоры о diffserv, по эффективности он обычно оказывается на последнем месте по сравнению с более продвинутой статистической мультиплексией FQ и короткими очередями от AQM. Хочу подчеркнуть, что всё это — опционально, кроме правильно настроенной компенсации DSL-соединения, дефолтные настройки cake достаточно хороши.

Ещё пара заметок: расскажывайте вашим клиентам, как улучшить Wi-Fi дома! В большинстве случаев буферблоут начинает проявляться на домашнем Wi-Fi при скорости выше 40 Мбит, и несмотря на все ухищрения по управлению полосой у провайдера, всем выгоднее иметь лучшие домашние роутеры с SQM на линии и fq_codel на Wi-Fi: https://blog.linuxplumbersconf.org/2016/ocw/system/presentations/3963/original/linuxplumber­s_wifi_latency-3Nov.pdf

Мейлинг-лист cake — лучшее место для вопросов и запросов новых функций: https://lists.bufferbloat.net/listinfo/cake — смотрите также архивы там и на связанной рассылке “Bloat”. Cake — самая продвинутая система интеллектуального управления очередями (SQM), которую нам пока удалось создать: https://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/. Изначально мы ориентировались на оборудование типа CPE и домашних шлюзов, но cake уже эффективно применяется и внутри сетей провайдеров.

Нам очень важно получать обратную связь, как улучшить cake или что-то похожее для ISP. Один пример (я не имею ни малейшего понятия, как это запустить на Mikrotik) тут: https://github.com/rchac/LibreQoS.

Существует множество академических статей о том, как на самом деле работают fq_codel и cake. Лучшее обобщение наших наработок по борьбе с bufferbloat в Linux собрано в онлайн-книге https://bufferbloat-and-beyond.net/ — но можете также гуглить "bufferbloat" и cobalt AQM через Google Scholar. Мне нравится объяснять не только как, но и почему (см. выше), иногда даже в увлекательной форме, например тут: https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/
10.10.2021 12:29:00, dtaht.]]> http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425859 http://mikrotik.moscow/forum/forum57/88338-nebolshie-bystrye-zametki-po-nastroyke-cake/message425859 Sun, 10 Oct 2021 12:29:00 -0400 RouterOS