Поддержка CoDel?

Кодел + опция "без пропадания" части наших пакетов – этого вполне достаточно, чтобы начать и сохранить простоту.

Если тебе нужна поддержка CoDel, лучше используй OpenWrt вместо Mikrotik OS на твоём Routerboard, работает отлично!

Микротик, чтобы улучшить очереди, когда они могут. В чем преимущество Codel по сравнению с <аппаратной очередью + очередью PCQ для равенства>? Спасибо.

Я вот думала, что PCQ вроде как это и делает? Но, может, я не так поняла? CoDel, конечно, звучит хорошо для беспроводной связи, когда пропускная способность постоянно немного варьируется...

Привет, поддержка Mikrotik! Вы видели этот запрос или посмотрели вторую половину http://twit.tv/show/security-now/359 или прочитали PDF по адресу http://delivery.acm.org/10.1145/2210000/2209336/p20-nichols.pdf?ip=41.135.100.141&acc=OPEN&CFID=189498739&CFTOKEN=48011506&__acm__=1351671966_2dc291d86f9fb0bd15ae0598d7f53cc6? Было бы просто замечательно, если бы появилась такая система управления очередями (AQM). Кстати, очереди Codel и очереди, основанные на "процентах" (меняющиеся в зависимости от ответа Codel), были бы просто супервыигрышным вариантом, и, вероятно, взвисят спрос на Mikrotik до небес. Ван Джейкобсон снова спасает мир Интернета!

С уважением.

— РЕДАКТИРОВАНИЕ: Mikrotik ответили и сказали, что собираются рассмотреть вопрос подробнее. Пожалуйста, напишите здесь, если вы понимаете преимущества Codel и хотели бы увидеть его внедрение. Посмотрите видео и прочитайте PDF, чтобы понять, насколько это улучшит управление очередями.

Очереди, основанные на процентах, изначально запрашивали здесь: http://forum.mikrotik.com/t/2009-and-mikrotik/25631/5

Очереди с факторами также невероятно полезны, когда у вас уже есть очередь Codel, смотрите мой пост с примером использования здесь: http://forum.mikrotik.com/t/vpns-overhead-and-queus/59228/1

Да, они могли бы дать нам представление о том, что они делают, но спрашивать об этом в нынешней обстановке не очень вежливо, если честно.

Дорогой Mikrotik, надеюсь, вы нас поразите анонсом развития очереди в ближайшее время. Чтобы поддерживать эту тему живой! С уважением!

Пожалуйста, не используйте опции `static limit-at` и `max-limit`. Это не совсем правильное решение на будущее, когда все снова (пере)откроют для себя bufferbloat. Однако, похоже, ведётся работа над добавлением CoDel в ядро Linux.

Несколько заметок: codel и fq_codel – это не слова, описывающие одно и то же. Codel – это стратегия отбрасывания пакетов, которая поддерживает более короткие очереди и общую меньшую задержку. Fq_codel сочетает в себе планирование пакетов в стиле DRR с несколькими дополнениями, чтобы дать приоритет более редким потокам (например, DNS, VoIP и игровые пакеты) в очереди по сравнению с потоками (большими загрузками), которые формируют очередь. Он использует codel для поддержания коротких потоков. В общем случае на домашнем роутере используйте fq_codel, а не codel. Его можно рассматривать как замену sfq, которая хорошо работает на более высоких скоростях, или как замену RED, которая не требует мучительной настройки, но он лучше, чем любой из них по отдельности или вместе. Fq_codel является частью пакета linux wireless-backports, который был перенесен в linux 2.6.32. Надеюсь, это достаточно для того, чтобы больше дистрибутивов его приняли. Он есть в ядре с версии 3.5 и постоянно улучшается. Codel или fq_codel НЕ требуют BQL в своем наиболее распространенном варианте использования, а именно в системе QoS с ограниченной скоростью поступления/исходящего трафика. Когда, например, используется htb или hfsc для контроля доступной полосы пропускания, fq_codel присоединяется под ним вместо qdisc по умолчанию, pfifo_fast. Сейчас много продуктов используют его в своих системах QoS. Поддержка BQL желательна, если присоединить его как сырой qdisc к устройству Ethernet. BQL не применим к устройствам Wi-Fi, и хотя fq_codel можно присоединить к mq qdisc, который используют большинство устройств Wi-Fi, работа над обеспечением его хорошей работы с избыточным буферированием, присутствующим в большинстве драйверов устройств Wi-Fi, все еще продолжается. Хотя openwrt сделал fq_codel своим стандартом для всего, пока что преждевременно выпускать продукты Wi-Fi AP, основанные на fq_codel, без тестирования поведения на загруженных каналах и тщательного анализа задействованных драйверов устройств. Fq_codel работает довольно хорошо на клиентах с одним интерфейсом Wi-Fi очереди (например, Android или ваш ноутбук). Наконец, есть новое оборудование, которое полностью обходит структуры qdisc в Linux (вещи для octeon), и у меня НЕТ данных о том, как или даже если fq_codel может быть там применим. У меня сложилось впечатление, что octeons делают RED аппаратно, и если вы можете это настроить, делайте это… и я бы очень хотел, чтобы fq_codel также был добавлен в эту прошивку однажды. Я был бы очень рад, если бы он появился в продуктах MikroTik, где это могло бы быть полезно, и желаю вам удачи в его тестировании. По вопросам о том, как он работает, спрашивайте на коде или ietf "aqm"l mailing list, ищите в Google ‘bloat-videos’, читайте сайт bufferbloat, смотрите ‘rrul rogues gallery’. Для статуса внедрения (например, в кабельной отрасли) ищите в Google “active queue management algorithms for docsis 3.0”. Конечно, есть гораздо больше, что нужно исправить, и потребуется некоторое время, чтобы отрасль и ietf пришли к соглашению о стандартах, но, учитывая, что код в целом доступен, я надеюсь, что вы воспользуетесь этой возможностью.