[MainFrm]

Дано:

Входящий канал 256к

Кол-во юЗверей 6

 

Описание:

Пользователи колотятся к серверу через pptpd, идея в том чтобы разделить скорость между пользователями. То есть если качает один то на полной скорости, двое соотвественно скорость поровну делиться и тыды.

 

htb тут не помогает, потому как каждый раз интерфейс разный, просто порезать 256 на 6 человек поровну, слишком маленькая скорость...

 

Идеи?

[anclbob]

ipfw пробовали?

[MainFrm]

А по подробнее?

Может примерчик есть?

[MainFrm]

ipfw пробовали?

И опять же не ясно, если интерфейсы разные как разделить скорость...

К тому же у меня Linux а не FreeBSD

Изменено 5 февраля, 2007 пользователем MainFrm

[anclbob]

ipfw пробовали?

И опять же не ясно, если интерфейсы разные как разделить скорость...

К тому же у меня Linux а не FreeBSD

ну если честно никогда не имел дело с другими фаерволами отличными от ipfw, и деление скорости будет происходить не по интерфейсам а по ИП адресам

 

${fw} pipe 1 config mask dst-ip 0x0000ffff bw 256Kbit/s

${fw} queue 1 config pipe 1 weight 16

${fw} add 40 queue 1 all from not 192.168.0.0/16 to ${clients_256}

 

 

может быть так?

[Kirya]

Копай в сторону IMQ или IFB.

http://www.linuximq.net и http://linux-net.osdl.org/index.php/IFB

Изменено 5 февраля, 2007 пользователем Kirya

[EvilShadow]

Дано:

Входящий канал 256к

Кол-во юЗверей 6

 

Описание:

Пользователи колотятся к серверу через pptpd, идея в том чтобы разделить скорость между пользователями. То есть если качает один то на полной скорости, двое соотвественно скорость поровну делиться и тыды.

 

htb тут не помогает, потому как каждый раз интерфейс разный, просто порезать 256 на 6 человек поровну, слишком маленькая скорость...

 

Идеи?

Интерфейс разный, но /etc/ppp/ip-up еще никто не отменял, там и нарезаете полосу на ппп-интерфейс. Насчет деления - обратите внимание, что в htb есть параметр rate, а есть параметр ceil.

[MainFrm]

/etc/ppp/ip-up - Фигня это все.

Вы не поняли задачу.

Канал узкий и делить его на равные части мне не нужно.

Поделить 256 на 6 я и так смогу.

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

Например один слушает радио в интернете и занимает 64 килобита при этом другой качает и занимает весь остальной канал.

 

При использовании HTB и прописывании скрипта в /etc/ppp/ip-up я могу только поровну поделить канал. Потому что при использовании HTB я должен писать:

 

# добавить корневую дисциплину HTB

tc qdisc add dev $DEV root handle 1: htb default 26

# добавить общее ограничение скорости по классу

tc class add dev $DEV parent 1: classid 1:1 htb rate ${RATEUP}kbit

 

То есть я должен добаить DEV. В случае соединения другого пользователя DEV будет уже другой и тыды.

 

Тоесть распределить загрузку не получиться!!!

 

По поводу ipfw... Linux у меня а не FreeBSD!!!!!

[MainFrm]

По поводу IMQ советую почитать умные статьи, потому что при таком низком канале и использовании IMQ я должен буду задать скорость на 30% меньше реальной, что при таком узком канале очень критично!!! IMQ просто отбрасывает часть пакетов КОТОРЫЕ УЖЕ ПРОШЛИ ПУТЬ И ЗАНЯЛИ КАНАЛ!

[MainFrm]

Может как вариант:

Прозрачный прокси и весь трафик через него. Но можно ли в нем все честно резать? Delay_pools эт конечно хорошо, но опять же динамически делить не понятно как.

[GENiUS]

Вижу только один вариант решения задачи.

Узнать у системы авторизации число подключившихся пользователей и при каждом событии logon или logoff выполнять скрипт делящий канал по авторизовавшимся IP.

[EvilShadow]

/etc/ppp/ip-up - Фигня это все.

Вы не поняли задачу.

Канал узкий и делить его на равные части мне не нужно.

Поделить 256 на 6 я и так смогу.

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

Например один слушает радио в интернете и занимает 64 килобита при этом другой качает и занимает весь остальной канал.

 

При использовании HTB и прописывании скрипта в /etc/ppp/ip-up я могу только поровну поделить канал. Потому что при использовании HTB я должен писать:

 

# добавить корневую дисциплину HTB

tc qdisc add dev $DEV root handle 1: htb default 26

# добавить общее ограничение скорости по классу

tc class add dev $DEV parent 1: classid 1:1 htb rate ${RATEUP}kbit

 

То есть я должен добаить DEV. В случае соединения другого пользователя DEV будет уже другой и тыды.

 

Тоесть распределить загрузку не получиться!!!

 

По поводу ipfw... Linux у меня а не FreeBSD!!!!!

Да нет, это Вы меня не поняли :)

Допустим, подключен один пользователь. Вы ему нарезаете полосу с rate=42, ceil=256. Т.о. Он получит 256 кбит. Подключились еще 5, получили такие же полосы. Теперь, если тянуть будут одновременно 6 человек, ни один из них не получит канала больше 42, а если один - то все 256 будут в его распоряжении.

Насчет dev - имя интерфейса передается в ip-up в кач-ве аргумента.

[MainFrm]

Нельзя так!

Я на каждый DEV ставлю Rate и Сeil но делиться по интерфейсам скорость не будет! На каждом DEV висит один IP адрес, соответсвенно каждому будет выдаваться максимальная скорость!

Есть конечно вариант ограничить скорость на исходящем Eth... но насамом деле это не выход потому что в сети IP выдаются по DHCP... в общем это тоже достаточно проблематично.

[EvilShadow]

Верно, оплошал :)

Дайте, пожалуйста, ссылочек на "умные статьи по IMQ", где написано о 30 процентах.

[MainFrm]

Opennet.ru тебе в помощь.

[EvilShadow]

Opennet.ru тебе в помощь.

1. Не припомню, чтоб мы на "ты" переходили.

2. Именно Вы отвергаете предложенный Вам IMQ, ссылаясь на какие-то загадочные 30%, при этом предлагаете мне самому искать доказательства против этого предложения? :)

[Kirya]

Opennet.ru тебе в помощь.

1. Не припомню, чтоб мы на "ты" переходили.

2. Именно Вы отвергаете предложенный Вам IMQ, ссылаясь на какие-то загадочные 30%, при этом предлагаете мне самому искать доказательства против этого предложения? :)

+1 :)

[Nicholas_M]

---

# добавить корневую дисциплину HTB

tc qdisc add dev $DEV root handle 1: htb default 26

# добавить общее ограничение скорости по классу

tc class add dev $DEV parent 1: classid 1:1 htb rate ${RATEUP}kbit

То есть я должен добаить DEV. В случае соединения другого пользователя DEV будет уже другой и тыды.

---

 

С помощью htb вы только нарезаете полосы (с возможностью "делиться" шириной канала), а раскидываете по

этим каналам пакеты с разными dst и src уже с помощью tc или (что тоже самое) iptables.

 

Для htb root нужен один, а parentов можно много наделать - по количеству ip.

Если кому-то выдается постоянный ip (а это можно сделать с помощью dhcp) то этому клиенту можно

выделить, например, бОльшую полосу...

 

В чем проблема ?

 

Исходящий трафик можно направлять в виртуальный интерфейс балансировщика, он есть в ядре по дефолту:

 

http://www.opennet.ru/docs/RUS/LARTC/c1389.html

" Распределение выполняется устройством 'TEQL'. Вот необходимые команды (куда уж проще):

 

# tc qdisc add dev eth1 root teql0

# tc qdisc add dev eth2 root teql0

# ip link set dev teql0 up "

 

Хотя, если честно, на практике не тестировал...

 

Удачи.

[user_anonymous]

Дано:

Входящий канал 256к

Кол-во юЗверей 6

 

Описание:

Пользователи колотятся к серверу через pptpd, идея в том чтобы разделить скорость между пользователями. То есть если качает один то на полной скорости, двое соотвественно скорость поровну делиться и тыды.

 

htb тут не помогает, потому как каждый раз интерфейс разный, просто порезать 256 на 6 человек поровну, слишком маленькая скорость...

 

Идеи?

Вот цитата из LARTC

9.2.3. Stochastic Fairness Queueing.

 

Stochastic Fairness Queueing (SFQ) -- простая реализация семейства алгоритмов справедливой очередизации. Она не так точна, как другие дисциплины, но требует меньше рассчетов, и при этом поровну распределяет доступную полосу пропускания между сеансами.

 

Ключевым понятием в SFQ является диалог (или поток), который приблизительно соответствует сеансу TCP или потоку UDP. Трафик делится на достаточное количество очередей типа FIFO, по одной на каждый диалог. После этого, все очереди обрабатываются в циклическом порядке, тем самым обеспечивая каждому сеансу равные шансы на передачу данных.

 

Благодаря этому достигается очень ровное поведение, которое не позволяет какому-либо диалогу подавлять остальные. SFQ называется "стохастической", т.к. на самом деле для каждого сеанса очередь не формируется, а трафик делится на ограниченое количество очередей на основе хеш-алгоритма.

 

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

 

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

 

В частности, применение SFQ на ethernet интерфейсе к которому подключен кабельный модем или DSL маршрутизатор совершенно бессмыслено без органичения полосы пропускания!

Может вам это поможет?

[Pe3ucTop]

Дано:

Входящий канал 256к

Кол-во юЗверей 6

 

Описание:

Пользователи колотятся к серверу через pptpd, идея в том чтобы разделить скорость между пользователями. То есть если качает один то на полной скорости, двое соотвественно скорость поровну делиться и тыды.

 

htb тут не помогает, потому как каждый раз интерфейс разный, просто порезать 256 на 6 человек поровну, слишком маленькая скорость...

 

Идеи?

Интерфейс разный, но /etc/ppp/ip-up еще никто не отменял, там и нарезаете полосу на ппп-интерфейс. Насчет деления - обратите внимание, что в htb есть параметр rate, а есть параметр ceil.

Может конечно и коряво, но можно ведь и при поднятии интерфеиса его прописывать и в firewall (mark table) помечать и после ограничивать скорость, исходящий от клиента можно на входном интерфеисе ограничивать, а то что к клиенту трафик наверное всетаки гнать в IMQ и тоже ограничивать, и все правила в TC по MARK флагу, HTB вполне пригодится. А на TC leaf - посоветую ESFQ вместо SFQ распределение скорости уже по IP, а не по коннекциям.