LINUX.ORG.RU

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


0

0

Это планировщик сетевых пакетов для операционной системы linux с ядрами 2.4 и 2.6. Его целью является просто равномерное распределение ресурсов отведенной полосы между ее потребителями. Работает он следующим образом: внутреняя очередь планировщика разделяется на заданное количество виртуальных очередей (слотов). Каждый слот, в свою очередь, имеет жестко заданный предел количества находящихся в нем пакетов. Внутренний классификатор распределяет поступающие в планировщик пакеты по слотам, основываясь либо на ip адресе получателя, либо на ip адресе отправителя. При выборе пакета из планировщика, слоты будут обрабатываться циклически, что обеспечит более или менее равномерное распределение.

>>> Подробности



Проверено: BaT ()

Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от madman

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

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

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

fagot ★★★★★
()
Ответ на: комментарий от avatar

>Round Robin - это зло!

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

fagot ★★★★★
()
Ответ на: комментарий от Sun-ch

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

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

anonymous
()
Ответ на: комментарий от fagot

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

fagot ★★★★★
()

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

rtc ★★
()
Ответ на: комментарий от anonymous

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

мне можно :-)

anonymous
()
Ответ на: комментарий от rtc

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

fagot ★★★★★
()
Ответ на: комментарий от anonymous

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

a1s2d3
()

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


McMCC ★★★
()
Ответ на: комментарий от madman

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

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

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

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

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

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

> madman (09.12.2005 19:46:45)

rtc ★★
()

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

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

SKYRiDER ★★★
()
Ответ на: комментарий от SKYRiDER

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

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

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

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

rtc ★★
()
Ответ на: комментарий от madman

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

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

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

fagot ★★★★★
()
Ответ на: комментарий от SKYRiDER

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

Честный дележ канала - понятие растяжимое :) Стандартный 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 например.

fagot ★★★★★
()
Ответ на: комментарий от fagot

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

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

avatar
()
Ответ на: комментарий от avatar

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

fagot ★★★★★
()
Ответ на: комментарий от Sun-ch

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

fagot ★★★★★
()
Ответ на: комментарий от anonymous

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

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

fagot ★★★★★
()
Ответ на: комментарий от fagot

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

fagot ★★★★★
()
Ответ на: комментарий от fagot

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

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

anonymous
()
Ответ на: комментарий от fagot

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

fagot ★★★★★
()
Ответ на: комментарий от fagot

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

fagot ★★★★★
()
Ответ на: комментарий от fagot

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

Именно.

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

>Именно.

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

fagot ★★★★★
()
Ответ на: комментарий от fagot

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

fagot ★★★★★
()
Ответ на: комментарий от fagot

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

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

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

avl@strace.net или icq: 122212949

anonymous
()
Ответ на: комментарий от anonymous

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

fagot ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.