fq_codel или cake в v7

Эти функции уже присутствуют в ядре, которое они выбрали для v7. Что нужно сделать, так это «интегрировать» их в RouterOS и Winbox. На самом деле, существует МНОГО функций в новых ядрах, которые пересекаются со старыми функциями v6, которые Микротик должен был реализовать самостоятельно. В зависимости от того, хотят ли они сохранить свою собственную реализацию или нет, мне кажется, что большая часть работы в v7 заключается в удалении реализаций Микротик и использовании нативных функций ядра. Я ожидаю, что cake и fq_codel появятся со временем. =) Будьте терпеливы! По крайней мере, они УЖЕ НАЧАЛИ работать над v7.

Реализация Fq_codel была бы отличным улучшением. Конечно, мы не можем ничего обещать насчет новых функций, но ваши пожелания учтены!

Ну, если ты используешь PCQ, у тебя есть несколько параметров для настройки. Я улучшил отзывчивость ADSL2+ с помощью PCQ в простых очередях, сделав буферы меньше, чем по умолчанию (которые, в противном случае, хорошо работают на скоростях 50+ Мбит). Например, на линии ADSL2 annex m с max-limit=1400k/16500k эти очереди позволяют веб-серфингу быть достаточно быстрым, даже когда загрузка (особенно) и скачивание загружены. /queue type add kind=pcq name=pcq-upload-adsl pcq-classifier=src-address,src-port pcq-limit=2KiB pcq-total-limit=1000KiB add kind=pcq name=pcq-download-adsl pcq-classifier=dst-address,dst-port pcq-limit=20KiB Насколько я понимаю, fq-codel имеет некоторое понимание (поскольку он встроен в ядро) о том, как быстро данные перемещаются через каждое следимое соединение и может соответственно регулировать буферы, чтобы минимизировать время их ожидания. С помощью PCQ ты можешь настроить размеры буферов, но я не могу придумать, как можно использовать скрипт для динамической настройки. Способ настройки это: Установи максимальные лимиты очереди на 90-95% от твоей измеренной насыщенной скорости (например, используя тест скорости и беря пиковые значения, которые ты видишь на графиках трафика в Winbox, а не то, что говорит Speedtest). Уменьшай свои pcq-limits постепенно, пока не заметишь, что отзывчивость или пинги становятся приемлемыми, когда загрузка и скачивание насыщены.

+1 за fq_codel и/или CAKE в ROS v7, как только это будет raisonnablement возможно. Спасибо, что слушаете!

+1 за fq_codel/cake

Я бы очень хотел увидеть: CoDel FQ_CoDel Cake Pie FQ_Pie и все остальные полные реализации очередей. Они не займут много места, но очень помогут в поддержании низкого уровня буферов.

Я всё еще надеюсь на fq_codel или cake в mikrotik. Однако это не совсем выбор "или", а скорее обоснованный подход. Wifi: fq_codel для 3 чипсетов wifi (mt76, ath9k и ath10k) существует уже несколько лет (https://lwn.net/Articles/705884/), но ключевая функция для ath10k (“ограничения времени передачи”) только что появилась в основной версии после нескольких лет тестирования в wifi и chromebook’ах от Google (http://flent-newark.bufferbloat.net/~d/Airtime%20based%20queue%20limit%20for%20FQ_CoDel%20in­%20wireless%20interface.pdf). Эта реализация находится на уровне mac80211 в ядре и не является qdisc, как таковым. Мы надеялись, что методы, которые мы разработали и задокументировали для этой реализации, будут использоваться в гораздо большем количестве wifi, 5g и ethernet over powerline. В других местах: fq_codel лёгкий и работает на "линейной скорости" на ethernet, wifi — практически на всем, и в настоящее время лишь несколько производителей внедрили его в прошивку ethernet или wifi. fq_codel (rfc8290) сейчас фактически является стандартом на большинстве систем linux и также есть на всех продуктах Apple. Необходима какая-то форма ограничения буферизации на уровне самой низкой прошивки (согласно BQL в linux или сейчас, AQL), и более чем у нескольких производителей и пользователей включен fq_codel с сотнями миллисекунд буферизации, всё еще застрявшими в драйвере, ожидания лучшего результата. BQL сейчас стандарт в linux, поддерживающий - я потерял счёт - более 50 ethernet-драйверов, но не обязательно тех, которые использует mikrotik. Добавление BQL в ethernet-драйвер занимает около 6 строк кода... что касается fq_pie, pie, codel и т.д., в общем, мы не рекомендуем запускать codel в одиночку. Если хотите сконструировать что-то вроде sfq + codel, ок... но серьёзно, используйте fq_codel даже с этим. Я не «только одна трюк» — мне хотелось бы, чтобы у всех был высокоскоростной интернет с низкой задержкой и без bufferbloat — давно поддерживаю разработку pie. Его можно считать (если ecn отключен) лучшим одноканальным AQM, чем codel. Pie легче, чем fq_codel, но не достигает той же глубины очереди (16 мс), которую может обеспечить codel (5 мс). Pie продолжает улучшаться: много нового появляется в более свежих ядрах, включая fq_pie, который только что появился в linux 5.5. Некоторые производители (кашляю, кабельные модемы) столкнулись с трудностями при реализации fq_codel в своих устройствах, и, надеюсь, fq_pie станет жизнеспособной альтернативой. Я бы действительно хотел независимого тестирования fq_pie по сравнению с cake и fq_codel, не только на линейной скорости, но и в режимах с формированием трафика. Cake, в частности, поддерживает DOCSIS, что кабельная индустрия до сих пор пытается игнорировать... что касается cake... после 5 лет разработки, ориентированной на пользователей, он был добавлен в linux 4.19, а версия "вне дерева" восходит к 3.10. По умолчанию cake примерно в 2.5 раза более требовательный к ЦП, чем fq_codel, но он делает намного больше — справедливость для хоста и потока, даже через NAT, фильтрация подтверждений, лучший алгоритм, похожий на codel и т.д. Мне нравится думать, что это текущий золотой стандарт для формирования трафика sqm-software, но снова, независимые тесты были бы просто отличными. Cake также является нашим исследовательским инструментом для ещё больших улучшений в дизайне sqm. Попробуйте его на линейной скорости в качестве формирователя, если можете выделить ЦП, но будьте готовы вернуться к более простому htb + fq_codel, если не можете. Главная цель cake заключалась в том, чтобы его можно было легко настраивать, и для этого требуется всего одна строка кода tc для включения на выходе, 3 на входе, в отличие от скриптов sqm или более сложных решений... а некоторые дополнительные детали можно найти в статье здесь: https://arxiv.org/pdf/1804.07617.pdf. Я думаю, что все эти алгоритмы будут полезны для пользователей mikrotik, и люди с bufferbloat.net всегда готовы помочь. Но оставлю вам немного юмора: на своей недавней речи на linux.conf.au я использовал людей, как пакеты, чтобы попытаться лучше объяснить поведение TCP и ценность этих алгоритмов. https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/. Где-то в этих обсуждениях упоминался fq_codel_fast... это экспериментальная версия с поддержкой экспериментального “SCE” (https://tools.ietf.org/html/draft-morton-tsvwg-sce-01), и я бы не стал поддерживать отправку этого в mikrotik. Существует конкурирующая попытка стандарта под названием L4S, которая работает иначе, и я действительно не знаю, куда это всё движется на данный момент. fq_codel_fast без этой функции оказывается примерно на 5% быстрее, чем fq_codel в настоящее время, но в общем это довольно незначительно. В итоге - внедряйте fq_codel для wifi, убедитесь, что у вас есть поддержка BQL и AQL, внедряйте fq_codel и cake, и не стесняйтесь экспериментировать с fq_pie и pie. С нетерпением ожидаю возможности поиграть с реализациями mikrotik в ближайшее время.