htb и 1000 пользователей

Сумма скоростей подклассов должна быть  <= скорости корневого класса.
В вышеприведённом конфиге 16*96 > 256 (предполагаю что ceil равно rate для класса 1:1)


А вообще
1. Понизить скорость на корневом классе. Насколько понижать подбирать эксперементально. Я делал на системе с сотней pptp клиентов примерно 90% канала
2. Можно снизить quantum до mtu (или как альтернативный вариант поменять r2q). Вариант через quantum для данной задачи предподчительнее.
3. Нормально htb будет работать при скоростях дочерних классов rate >= (mtu*8/1024)kbit. Если mtu=1500, то соответвено  всё нормально: 16kbit >= 12 kbit

>Сумма скоростей подклассов должна быть <= скорости корневого класса.
Меньше, но для htb это не обязательно. Если канал 100 Мбит и в нём шейпаются 1000 юзеров по мегабиту, в случае одновременной активности каждый получит по 100 Кбит.

>1. Понизить скорость на корневом классе. Насколько понижать подбирать эксперементально. Я делал на системе с сотней pptp клиентов примерно 90% канала
Вам это помогало по одной причине - у вас шейпер был после шейпера вашего магистрального провайдера, то есть после узкого места. У нас узкое место после шейпера, то есть достаточно оставить 1-2 Мбит из 100. Понижение сказывается ещё более отрицательно.

>2. Можно снизить quantum до mtu (или как альтернативный вариант поменять r2q). Вариант через quantum для данной задачи предподчительнее.
>3. Нормально htb будет работать при скоростях дочерних классов rate >= (mtu*8/1024)kbit. Если mtu=1500, то соответвено всё нормально: 16kbit >= 12 kbit
Попробую :).

Спасибо.

Зачем же все так усложнять... Не проще ли на интерфейс повесить ESFQ, который умеет балансировать по src и dsc ?

> Меньше, но для htb это не обязательно. Если канал 100 Мбит и в нём шейпаются 1000 юзеров по мегабиту, в случае одновременной активности каждый получит по 100 Кбит.

Получит то может и получат но пинг возрастёт - дочерние классы будут между собой конкурировать http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#prio

> Зачем же все так усложнять... Не проще ли на интерфейс повесить ESFQ, который умеет балансировать по src и dsc ?

С точки зрения уменьшения latency для канала совсем не прощё.

>Зачем же все так усложнять... Не проще ли на интерфейс повесить ESFQ, который умеет балансировать по src и dsc ?
ESFQ уже вешается на поток пользователя. Шейпить им весь потом не ационально, да и медленно.

>Получит то может и получат но пинг возрастёт - дочерние классы будут между собой конкурировать http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm#prio
Конкуренция не должна приводить к росту задержек - каждый плюхается в своём виртуальном потоке. Да и я написал, что при 10-20 активных пользователях с той же конкуренцией проблем с задержками нет.

>С точки зрения уменьшения latency для канала совсем не прощё.

Ну почему же? Создали корневой класс с ceil на 10% меньне реальной пропускной способности канала, и повесили на этот класс ESFQ, балансируем по dst (т.е. по получателю). Даже при пиковых нагрузках не должно быть перегрузок.

З.Ы: Если у аффтара анлим, то не пойму, зачем на каждого юзера клепать дисциплину? Наверно сам фильтр создает перегрузки, из за большой цепочки.

>Ну почему же? Создали корневой класс с ceil на 10% меньне реальной пропускной способности канала, и повесили на этот класс ESFQ, балансируем по dst (т.е. по получателю). Даже при пиковых нагрузках не должно быть перегрузок.
Канал загружен постоянно, что делать, если кому-то нужно дать в этот момент в 2 раза больше, чем другому?

>З.Ы: Если у аффтара анлим, то не пойму, зачем на каждого юзера клепать дисциплину? Наверно сам фильтр создает перегрузки, из за большой цепочки.
Анлим, но это не означает, что полосу распределять не нужно.

Выяснил в чём проблема: htb делает lookup по активным правилам, поэтому пинг растёт только тогда, когда кол-во активных пользователей очень много.

Варианта решения два: 1. хэш-листы. 2. переписывать модуль htb под свой случай для более быстрого поиска.

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

>Канал загружен постоянно, что делать, если кому-то нужно дать в этот момент в 2 раза больше, чем другому?

Без проблем... Создаешь два (или столько, сколько нужно) подклассов. На первый вешаешь всех остальных пользователей (с балансировкой через ESFQ). Потом добавляешь подклассы для каждого конкретного пользователя. Потом можешь еще прописать авто-отрезалку, типа ceil на корневом класе 90Mb/sec, на первый подкласс гарантировано 40Mb/sec, не гарантировано 80Mb/sec и prio 7. На второй подкласс 10Mb/sec гарантировано и 10Mb/sec не гарантировано, поставить prio 2, чтоб когда юзер второго подкласса начинает качать на свои положенные 10Mb/sec, на первом подклассе скорость падала. Чтоб не считать cail-ы вручную, можно написать считалку, чтоб ты только прописал что у тебя появился user3, которому от общего класса нужно отрезать гарантировано 5Mb/sec. Самое главное тут правильно просчитать cail-ы, и тогда не будет перегрузок даже при пиковых нагрузках.

З.Ы: Мне кажется что это решение довольно легко в реализации, и в производительности.

>Конкуренция не должна приводить к росту задержек - каждый плюхается в своём виртуальном потоке.

Блин но каждый поток будет пытаться получить свой гарантированый rate.

> Да и я написал, что при 10-20 активных пользователях с той же конкуренцией проблем с задержками нет.

Естественно. Если предположить что rate для класса 1:1 равен 256kbit, то 256kbit/(10-20)=(26-13)kbit что применрно равно 16kbit - каждый класс получает свой гарантированый rate.

> Ну почему же? Создали корневой класс с ceil на 10% меньне реальной пропускной способности канала, и повесили на этот класс ESFQ, балансируем по dst (т.е. по получателю). Даже при пиковых нагрузках не должно быть перегрузок.

Потому что уже возился с этим esfq. Сделано было так: корневой htb qdisc, к нему присоеденён один htb класс, к нему в свою очередь присоеденён esfq qdisc. Делил нормально поровну, но задержки (точнее пинг) были порядка 500ms, при чистом htb задержки были равны задержкам на пустом канале. Делал на htb классе rate равной от 90% до 60% канала (канал естествено был в это время нагружен другими пользователми) - для задержек не помогало. Менял все параметры esfq (quantum, limit, depth, divisor) - тоже не помогло.

>Выяснил в чём проблема: htb делает lookup по активным правилам, >поэтому пинг растёт только тогда, когда кол-во активных пользователей >очень много. >Варианта решения два: 1. хэш-листы

Как вариант можно использовать IPMARK из patch-o-matic:

IPMARK Allows you to mark a received packet basing on its IP address. This can replace many mangle/mark entries with only one, if you use firewall based classifier.

This target is to be used inside the mangle table, in the PREROUTING, POSTROUTING or FORWARD hooks.

--addr src/dst Use source or destination IP address.

--and-mask mask Perform bitwise `and' on the IP address and this mask.

--or-mask mask Perform bitwise `or' on the IP address and this mask.

The order of IP address bytes is reversed to meet "human order of bytes": 192.168.0.1 is 0xc0a80001. At first the `and' operation is performed, then `or'.

Examples:

We create a queue for each user, the queue number is adequate to the IP address of the user, e.g.: all packets going to/from 192.168.5.2 are directed to 1:0502 queue, 192.168.5.12 -> 1:050c etc.

We have one classifier rule:

tc filter add dev eth3 parent 1:0 protocol ip fw

Earlier we had many rules just like below:

iptables -t mangle -A POSTROUTING -o eth3 -d 192.168.5.2 -j MARK --set-mark 0x10502

iptables -t mangle -A POSTROUTING -o eth3 -d 192.168.5.3 -j MARK --set-mark 0x10503

Using IPMARK target we can replace all the mangle/mark rules with only one:

iptables -t mangle -A POSTROUTING -o eth3 -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000

On the routers with hundreds of users there should be significant load decrease (e.g. twice).

>Блин но каждый поток будет пытаться получить свой гарантированый rate.

>Естественно. Если предположить что rate для класса 1:1 равен 256kbit, то 256kbit/(10-20)=(26-13)kbit что применрно равно 16kbit - каждый класс получает свой гарантированый rate.

Вы не правы, когда я писал "с той же конкуренцией проблем с задержками нет", то я имел ввиду, что rate был поднят в соответствующее кол-во раз, чтобы никто него не получал.

Проблема была в поиске правила для каждого пакета, переписал модуль htb всё работает очень быстро.