Привет, один из участников разработки cake здесь. Рад, что вы наконец-то начали его использовать, но у меня есть несколько замечаний: современная версия cake поддерживает новый diffserv LE кодпоинт. Мне очень хотелось бы видеть поддержку этого в Mikrotik, учитывая, насколько проблемным оказался CS1, и патч для этого совсем небольшой. Одна из особенностей cake — он работает одинаково хорошо как на полной пропускной способности, так и с включённым шейпером, так что можно получить классификацию fq по хостам/потокам, diffserv и т.д. Мне очень интересно узнать результаты, когда вы попробуете запустить его или fq_codel на полной скорости, а не с шейпером. fq_codel сейчас по умолчанию стоит на всех интерфейсах вместо pfifo_fast в большинстве современных Linux. Было бы здорово, если бы кто-то проверил cake через серию тестов flent rrul или нагрузочных iperf-тестов, сделал дампы трафика и построил графики RTT, особенно на топовом железе Mikrotik. Он особенно полезен с работающим BQL в драйвере устройства.
не поддерживает опцию gso-splitting. При использовании шейпера ниже 1 Гбит gro "суперпакеты" автоматически разбиваются обратно на пакеты (и затем перемешиваются с другими потоками), а при отсутствии шейпера или скорости выше 1 Гбит — нет. Если у вас достаточно CPU — разбивайте суперпакеты. Если маршрутизатор выполняет NAT, попробуйте опцию nat. Однако она не работает с некоторыми типами offloaded NAT. Если у вас сильная асимметрия по пропускной способности (больше 10 к 1), попробуйте опцию ack-filter на более медленной стороне канала. Это становится крайне необходимым при таких больших пропорциях, подробнее:
Было бы неплохо, если бы 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 роутер. Подробнее: — малоиспользуемая возможность в webrtc.
Несмотря на все эти разговоры о diffserv, по эффективности он обычно оказывается на последнем месте по сравнению с более продвинутой статистической мультиплексией FQ и короткими очередями от AQM. Хочу подчеркнуть, что всё это — опционально, кроме правильно настроенной компенсации DSL-соединения, дефолтные настройки cake достаточно хороши.
Ещё пара заметок: расскажывайте вашим клиентам, как улучшить Wi-Fi дома! В большинстве случаев буферблоут начинает проявляться на домашнем Wi-Fi при скорости выше 40 Мбит, и несмотря на все ухищрения по управлению полосой у провайдера, всем выгоднее иметь лучшие домашние роутеры с SQM на линии и fq_codel на Wi-Fi:
Мейлинг-лист cake — лучшее место для вопросов и запросов новых функций: — смотрите также архивы там и на связанной рассылке “Bloat”. Cake — самая продвинутая система интеллектуального управления очередями (SQM), которую нам пока удалось создать: . Изначально мы ориентировались на оборудование типа CPE и домашних шлюзов, но cake уже эффективно применяется и внутри сетей провайдеров.
Нам очень важно получать обратную связь, как улучшить cake или что-то похожее для ISP. Один пример (я не имею ни малейшего понятия, как это запустить на Mikrotik) тут: .
Существует множество академических статей о том, как на самом деле работают fq_codel и cake. Лучшее обобщение наших наработок по борьбе с bufferbloat в Linux собрано в онлайн-книге — но можете также гуглить "bufferbloat" и cobalt AQM через Google Scholar. Мне нравится объяснять не только как, но и почему (см. выше), иногда даже в увлекательной форме, например тут:
не поддерживает опцию gso-splitting. При использовании шейпера ниже 1 Гбит gro "суперпакеты" автоматически разбиваются обратно на пакеты (и затем перемешиваются с другими потоками), а при отсутствии шейпера или скорости выше 1 Гбит — нет. Если у вас достаточно CPU — разбивайте суперпакеты. Если маршрутизатор выполняет NAT, попробуйте опцию nat. Однако она не работает с некоторыми типами offloaded NAT. Если у вас сильная асимметрия по пропускной способности (больше 10 к 1), попробуйте опцию ack-filter на более медленной стороне канала. Это становится крайне необходимым при таких больших пропорциях, подробнее:
Было бы неплохо, если бы 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 роутер. Подробнее: — малоиспользуемая возможность в webrtc.
Несмотря на все эти разговоры о diffserv, по эффективности он обычно оказывается на последнем месте по сравнению с более продвинутой статистической мультиплексией FQ и короткими очередями от AQM. Хочу подчеркнуть, что всё это — опционально, кроме правильно настроенной компенсации DSL-соединения, дефолтные настройки cake достаточно хороши.
Ещё пара заметок: расскажывайте вашим клиентам, как улучшить Wi-Fi дома! В большинстве случаев буферблоут начинает проявляться на домашнем Wi-Fi при скорости выше 40 Мбит, и несмотря на все ухищрения по управлению полосой у провайдера, всем выгоднее иметь лучшие домашние роутеры с SQM на линии и fq_codel на Wi-Fi:
Мейлинг-лист cake — лучшее место для вопросов и запросов новых функций: — смотрите также архивы там и на связанной рассылке “Bloat”. Cake — самая продвинутая система интеллектуального управления очередями (SQM), которую нам пока удалось создать: . Изначально мы ориентировались на оборудование типа CPE и домашних шлюзов, но cake уже эффективно применяется и внутри сетей провайдеров.
Нам очень важно получать обратную связь, как улучшить cake или что-то похожее для ISP. Один пример (я не имею ни малейшего понятия, как это запустить на Mikrotik) тут: .
Существует множество академических статей о том, как на самом деле работают fq_codel и cake. Лучшее обобщение наших наработок по борьбе с bufferbloat в Linux собрано в онлайн-книге — но можете также гуглить "bufferbloat" и cobalt AQM через Google Scholar. Мне нравится объяснять не только как, но и почему (см. выше), иногда даже в увлекательной форме, например тут:
