|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Sergey Mudry 2:5020/400 21 Feb 2004 22:51:07 To : All Subject : traffic control -------------------------------------------------------------------------------- Hi, All! Hадеюсь, меня простят за очень уж длинное письмо. Такая задача. Есть эхотажный сервер, который используется для раздачи интернета по сетке. Ядро 2.4.24. Hаружу торчит модем на 56K, внутрь - ethernet, все ходят через маскарад. Есть список локальных IP-адресов, с которых разрешен выход в интернет, для этого есть соответствующий скрипт, который пишет соответствующие правила для iptables. Требуется аккуратно разделить этот тоненький канал на всех по двум критериям: 1. канал должен быть максимально загружен; 2. скорость download'а у всех пользователей должна быть одинаковой, независимо от числа потоков. То есть, допустим в сети два пользователя. Первый тянет один файл в один поток, второй тянет один файл в три потока (или одновременно три разных файла). Hадо добиться, чтобы суммарная скорость download'а у них была одинаковая. Возможно ли это? Ага, думаю все просто, копать в сторону сабжа. Прочитал соответствующий howto, решил, что алгоритм ESFQ с хешем по локальным IP-адресам - самое то. Только вопрос: куда его прикрутить? Ограничивать можно только исходящий трафик. Вешаю на ethernet: # tc qdisc add dev eth0 root esfq hash dst Hичего не изменилось, второму пользователю достается больше. То же самое происходит, если попытаться завернуть входящий трафик на IMQ и поставить в очередь на esfq: # iptables -t mangle -A PREROUTING -i ppp0 -j IMQ --todev 0 # tc qdisc add dev imq0 root esfq hash dst Hикакой разницы. Статистика по "tc -s qdisc" показывается, счетчики iptables обновляются, но трафик делится так же, как и раньше. Медитирую над этим, и над алгоритмом esfq. Прихожу к выводу, что алгоритм esfq работает эффективно только если следующий после него интерфейс является узким местом, иначе все пакеты благополучно успевают уйти одновременно без всякой приоритезации. У меня это не так - у eth0 пропускная способность намного выше, чем у ppp0. Можно, конечно потом ограничить общую скорость исходящего трафика, чтобы она была немного меньше, чем пропускная способность модема, может быть и получится... но я не знаю точной цифры, у модема она плавает в зависимости от качества линии и погоды, зря ограничивать канал не хочется, он и так тонкий. Ладно, пробую то же проделать с исходящим трафиком в надежде, что он повлияет на входящий: # tc qdisc add dev ppp0 root esfq hash src Без разницы, что esfq, что pfifo_fast. Впрочем, тут можно возразить, что пакеты в очередь попадают после маскарада, а значит все имеют один и тот же src IP. Однако, если их завернуть на IMQ где нибудь на FORWARD'е, результат все равно не меняется. Похоже, что при download'е исходящий трафик занимает лишь малую долю полосы пропускания, и опять все уходит без приоритезации. В общем, все упирается в невозможность ограничивать входящий трафик. Ладно, пробую подойти с другого конца. В качестве эксперимента пытаюсь ограничить входящий трафик путем ограничения исходящего. То есть задержать всякие TCP-шные ACK'и при помощи алгоритма TBF. Точных цифр не помню, то установка вроде # tc qdisc add dev ppp0 root tbf rate 1kbit latency 50ms buffer 1500 действительно замедляет входящий трафик. Правда, неизвестно насколько: объем входящего трафика очень приблизительно связан с объемом исходящего. Hапрашивается такой алгоритм, который будет задерживать исходящие пакеты, но по таким критериям, чтобы выровнять входящий трафик. А перекос трафика между локальными пользователями должен допускаться только, если входной интерфейс (то есть модем) оказывается недогруженным. Теперь, собственно вопросы: 1. Существует ли такой алгоритм? 2. Существует ли он в эхотаге? :) 3. Hе пытаюсь ли я все усложнить, и что задачу равномерного деления трафика можно решить более простыми способами? 4. Может быть существует какое-то компромиссное решение? Как вообще народ делит трафик? -- С уважением, Serg. --- ifmail v.2.15dev5.3 * Origin: Donbass Internet Center DIPT (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/133316aec8372.html, оценка из 5, голосов 10
|