Планировщик пакетов SRR (Simple Round Robin)

Ура!
Заново изобретён freebsd'шный DUMMYNET!

А чем это лучше ESFQ?

А что DUMMYNET гарантирует равномерное распределение потока?

Графическая консоль администратора политик там есть?

Чем оно лучше готовых планировщиков, встроенных в iproute2?

вообще-то в iproute2 встроенных планировщиков нет. это не его задача планировать пакеты. это просто юзерспейс а насчет того, что чем он лучше - он ни лучше ни хуже, он просто предоставляют то, что не делают другие планировщики. по крайней мере в 2.4 кернелах

это не лучше ESFQ, это альтернатива.

Round Robin - это зло!

>это не лучше ESFQ, это альтернатива.

Ок, а зачем нужна менее функциональная (см. README по esfq) альтернатива хорошо известному и работающему планировщику?

И могу ли я доверять автору, не забросит ли он проект через месяц?

>Round Robin - это зло!

аргументы в студию. Только не надо про то, что это долго, ничего другого под Linux и нет, кажется.

> Графическая консоль администратора политик там есть?

А расписанная под хохлому не нужна?

>Ок, а зачем нужна менее функциональная (см. README по esfq) >альтернатива хорошо известному и работающему планировщику?

А кто говорит, что она нужна? Как любая альтернатива ее либо можно пользоваться, либо нет. Это дело личного выбора.

>И могу ли я доверять автору, не забросит ли он проект через месяц?

Может стоит через месяц посмотреть?

В мире вообще, и в open source в частности, доверять нельзя никому. Даже себе :)

Увы, это я знаю :)

В принципе, по сабжу все более-менее ясно, жаль правда что нету ничего новенького.

Ух, еще один Round Robin, теперь их уже как минимум 3 :)
Чего только люди не делают, чтобы документацию не читать...

>В мире вообще, и в open source в частности, доверять нельзя никому. Даже себе :)

мне можно :-)

>Ух, еще один Round Robin, теперь их уже как минимум 3 :)

Плюс еще нужно патчить iproute2 ради него. Фтоппку!

>Плюс еще нужно патчить iproute2 ради него. Фтоппку!

Для поддержки ESFQ тоже надо

Не знаю, не знаю... У меня ядро от ASPLinux - там esfq уже есть.

Такой планировщик для embedded будет кстати, что бы тут другие не орали
про документацию и прочее, это позволит упростить настройку, что не маловажно для embedded устройств и не использовать более тяжеловесные
решения... Вообщем, автор молодец и какраз вовремя, такой модуль нужен,
покрайней мере мне точно и сейчас...

Хоть один позитивный отклик.

А то обосрать каждый может, а свое придложить мозга не хватает.

> Хоть один позитивный отклик.

> А то обосрать каждый может, а свое придложить мозга не хватает.

Да ладно тебе, я тоже очень люблю изобретать велосипеды.

Но скажи, чем это отличается от WRR (Weighted Round Robin) с одинаковыми весами?

http://lartc.org/howto/lartc.adv-qdisc.wrr.html

Любое действие похвально, если не несет вреда.

> madman (09.12.2005 19:46:45)

Уважаемые, подскажите пожалуйста чем лучше пользоваться для "честного" разделения канала на нескольких юзеров. В принципе должен подходить стандартный SFQ или что-то подобное, но тут неоднократно встречал упоминания о всяких WRR, ESFQ и т.п. Неужели они настолько лучше? Чем? И ещё вопрос - если они настолько лучше, то почему ни один из них не попал в стандартное ядро? Ради каждого из них надо патчить ядро и/или iproute2. :(

Буду благодарен если подкинете ссылок на related ресурсы с доками, патчами и т.п.

>Уважаемые, подскажите пожалуйста чем лучше пользоваться для "честного" разделения канала на нескольких юзеров. В принципе должен подходить стандартный SFQ или что-то подобное, но тут неоднократно встречал упоминания о всяких WRR, ESFQ и т.п. Неужели они настолько лучше? Чем? И ещё вопрос - если они настолько лучше, то почему ни один из них не попал в стандартное ядро? Ради каждого из них надо патчить ядро и/или iproute2. :-(

>Буду благодарен если подкинете ссылок на related ресурсы с доками, патчами и т.п.

Лучшая документация по этой теме: http://www.lartc.org/

>SKYRiDER ** (09.12.2005 19:58:07)

Свое прИдложить можно, но не всегда в этом есть потребность.

Я просил, зачем оно надо - мне, по сути, ответили "а чтоб было". Если это "проба пера" автора, то так и скажи. А почему был написан этот патч, какие его сильные стороны, ни на сайте, ни тут не написано.

Спрашиваю не для того, чтобы пофлеймить, меня эта тема интересует. И что в нем такого хорошего для embedded-устройств, (мне) тоже не ясно - SFQ под очередь надо 4кб памяти и ресурсов не жрет особо (ну, ESFQ больше конечно).

>Уважаемые, подскажите пожалуйста чем лучше пользоваться для "честного" разделения канала на нескольких юзеров.

Честный дележ канала - понятие растяжимое :) Стандартный SFQ не позволяет отдельному потоку преобладать над другими. Но если одно приложение работает в несколько потоков, то естественно, получает больше, чем другие. ESFQ может делить канал не по потокам, а по потокам с/до IP-адреса, поэтому как бы лучше. Но и этого для "честного" деления недостаточно, если трафик делить на классы - можно одновременно работать с несколькими приложениями, которые генерируют трафик разного типа, и таки получать преимущество :)

WRR - более требовательный к ресурсам аналог и предшественник SFQ, насколько я понимаю (поправьте меня, кто знает точно).

>И ещё вопрос - если они настолько лучше, то почему ни один из них не попал в стандартное ядро?

SFQ и WRR в ядре есть. А вот автору ESFQ, мне кажется, это без разницы (если он вообще еще интересуется судьбой своего детища).

>ссылок на related ресурсы с доками, патчами и т.п.

Вся дока на lartc.org, конечно, хотя

http://www.docum.org
http://diffserv.sourceforge.net/
http://tcng.sourceforge.net/
http://gazette.linux.ru.net/rus/articles/taleLinuxTC.html (рус)
http://sourceforge.net/projects/htbinit
http://sourceforge.net/projects/cbqinit/
http://lartc.org/wondershaper/
http://www.tldp.org/HOWTO/ADSL-Bandwidth-Management-HOWTO/implementation.html
http://www.digriz.org.uk/jdg-qos-script/
http://www.knowplace.org/pages/howtos/traffic_shaping_with_linux/resources.php

Патч-сеты - http://relaks.info/linux/mq/stable/ , http://kem.p.lodz.pl/~peter/qnet/ , http://fine.kalinovka.net/?q=node/13 например.

Зачем аргументы?

Балансировщики должны быть логичные, а не тупые. Еще в 80 годах пытались создать логические устройстав, а теперь выясняется что тупые технологии "спасут мир" - докатились! Сила никгода не была лучше ума.

Аргументы затем, чтобы я не удалил твои сообщения как флуд. Хотя надо бы.

>Графическая консоль администратора политик там есть?

сестра несите галоперидол, уссаныч в кваку переиграл

Спасибо, fagot.

удачи

Поясните мне, чем плох шейпер, построенный на встроенном в ядре HTB qdisc?

>Поясните мне, чем плох шейпер, построенный на встроенном в ядре HTB qdisc?

Вопрос некорректен.

1. HTB не совсем (не только) не шейпер.

2. SFQ/ESFQ/SRR не шейперы (не могут использоваться для профилирования - shaping - трафика).

3. HTB делает СОВЕРШЕННО не то, что SFQ/ESFQ/SRR.

Однако задачу выполняет?

Речь об HTB? Да, свою задачу HTB выполняет.

Но, ничего общего эта задача с обсуждаемым SRR не имеет.

>Спрашиваю не для того, чтобы пофлеймить, меня эта тема интересует. >И что в нем такого хорошего для embedded-устройств, (мне) тоже не >ясно - SFQ под очередь надо 4кб памяти и ресурсов не жрет особо (ну, >ESFQ больше конечно).

Не совсем так. В SFQ при дефолтовых настройках приватные данные помещаются в 4K, но никак не очередь. В ESFQ приватные данные еще меньше, чем в SFQ, но в свою очередь память под связные списки выделяется отдельно, что не гарантирует ее попадание в ту же страницу, где находятся приватная часть. К томе же и SFQ и ESFQ при dequery переключатся на другой слот только после посылки quantum байт из текущего слота. Получается, что если, например, есть две очереди: в 1-й три пакета по 128 байт, а во второй - один 100 байт и quantum=mtu=1500, то SFQ/ESFQ сначала пошлет все пакеты из первой очереди, а только затем переключится на вторую. Не совсем равномерно получается.

>В SFQ при дефолтовых настройках приватные данные помещаются в 4K, но никак не очередь.

Сморозил, это я уже понял.

>К томе же и SFQ и ESFQ при dequery переключатся на другой слот только после посылки quantum байт из текущего слота. Получается, что если, например, есть две очереди: в 1-й три пакета по 128 байт, а во второй - один 100 байт и quantum=mtu=1500, то SFQ/ESFQ сначала пошлет все пакеты из первой очереди, а только затем переключится на вторую. Не совсем равномерно получается.

Хм, а как работает SRR?

>Хм, а как работает SRR?

SRR при dequery выберет sk_buff из текущего слота и при последующем вызове dequery переключится на обработку следующего непустого слота. Ессно, следующим непустым слотом может оказаться и предыдущий слот и вообще не оказаться непустых слотов. В посследнем случае вернется NULL

ОК, а что есть sk_buff, размер первого в "подочереди" пакета?

>ОК, а что есть sk_buff, размер первого в "подочереди" пакета?

sk_buff - грубо говоря, представление пакета в кернеле а размер пакета есть поле len структуры sk_buff

Т.е., я понял более-менее правильно, "аналогом" quantum в SRR является размер пакета?

Если да, то это разве не выходит тем же боком, только наоборот? То есть не будет равномерного (относительно, конечно) распределения потока в байтах, если в первой "подочереди" будет один пакет 1500байт, а в другой - три по 100 байт?

>Т.е., я понял более-менее правильно, "аналогом" quantum в SRR >является размер пакета?

Нет. Аналога quantum в SRR вообще нет. Вместо этого после посылки одного пакета из текущей подочереди просходит переключение на обработку следующей подочереди.

То есть, если рассмотреть пример с друмя очередями: в одной очеред 3 пакета по 100 байт, а во второй - один 1500 байт и mtu 1500. То в случаеSFQ/ESFQ вначале уйдут 3 апкета по 100 байт, а лишь после этого один пакетк 1500 байт из второй подочереди. Если учесть, что большинство драйверов останавливат обработку очереди пакетов до подтверждения отправки в hadirq, то может весьма увеличиться латенси отправки пакета в случае с SFQ/ESFQ.

>Вместо этого после посылки одного пакета из текущей подочереди просходит переключение на обработку следующей подочереди.

Без учета размера пакета?

>то может весьма увеличиться латенси отправки пакета в случае с SFQ/ESFQ.

А о каких величинах идет речь, приблизительно? Я не знаком с этой темой на таком уровне :(

>Без учета размера пакета?

Именно.

>А о каких величинах идет речь, приблизительно? Я не знаком с этой >темой на таком уровне :(

Это уже скорее от каждого конкретного устройства зависит. К примеру для радиокарт можно прикинуть: карта посылает пакет и ждет подтверждения с принимающей стороны как минимум 10 микросекунд. Если оно не пришло, то идет простой некотрое время опять перепосылается тот-же фрейм и опять-же происходит ожидание подтверждения от получателя. Это повторяется заданное количество раз. Если подтверждение получено, то карточка через аппаратное прерывание генерит соответствующий евент и лишь тогда драйвер включит обработку очереди пакетов. Получается, что задержа может быть от нескольких десятков микросекунд, для нескольких десятков милисекунд.

Про задержки понял, спасибо.

>>Без учета размера пакета?

>Именно.

Значит поток большИх пакетов получит больше полосы в единицу времени, чем поток маленьких, разве нет? Т.е. количество обработанных пакетов будет более-менее равно, но байт - нет?

>Значит поток большИх пакетов получит больше полосы в единицу >времени, чем поток маленьких, разве нет? Т.е. количество >обработанных пакетов будет более-менее равно, но байт - нет?

В данной ситуации, когда количисто пакетов о подочередях будет болии или менее равно - да.

Ясно, спасибо.

Я тут подумал по поводу задержек, вносимых драйверами оборудования. Речь шла только об использовании SFQ/ESFQ как корневой дисциплины, или это относится и к случаю, когда они используются как дисциплины leaf-классов?

И другой вопрос. Я нигде не нашел ни контактной ни общей информации о Dmitry Labutcky. Это единственный "публичный" его проект? Как с ним можно связаться?

>Я тут подумал по поводу задержек, вносимых драйверами >оборудования. Речь шла только об использовании SFQ/ESFQ как >корневой дисциплины, или это относится и к случаю, когда они >используются как дисциплины leaf-классов?

Думаю, что в обоих случаях. К тому-же саму задержку (шейпинг) может вносить еще и leaf-класс.

>И другой вопрос. Я нигде не нашел ни контактной ни общей >информации о Dmitry Labutcky. Это единственный "публичный" его >проект? Как с ним можно связаться?

avl@strace.net или icq: 122212949

Ясно. Спасибо большое. Пока наверное все :)