Я уже крепко задумывался. Умные люди советовали так
http://www.gentoo.ru/node/15512

Вам скорее всего подойдет trickle, а мне вот не понравилось.
В общем, люди! Есть разбирающиеся в tc??

Пользую deluge и там это штатная функция. Правда не в процентах а в килобитах. В трансмиссии тоже самое
На крайняк заюзай трикле - о нем тут уже писали

Нет интереснее изменять эти параметры походу и автоматом:)

Именно!

rtorrent тоже умеет канал себе ограничивать килобитами.
С tc можно заморочиться, если знать отличительную особенность торрент-трафика. Тогда в iptables вешаем mark, а дальше фильтрами в tc классифицируем трафик. Геморно настраивать и я уже не помню синтаксис tc (а он там вообще ни разу не простой), так чот оптимально - использовать возможности самого торрент-клиента :)

Теперь Вам отвечу я


Я понимаю, чтобы достичь результа, когда торренты и качалки занимают РОВНО столько от канала, сколько осталось от браузера и пр. - это подаваться в kernel team

Но Боже мой, изменить приоритет PID для процессора и жд можно, ну а сеть-то почему? (Я даж согласен, чтоб оно всех полностью "фризило" качалку на время с браузером. И "отпускало" когда его активности нет...)

В том-то и вся проблема, что сложно отличить торрент-траффик от остального. Он может идти по разным портам. Один из вариантов - собирать собственный iptables с модулем, умеющим класифицировать траффик по содержимому пакетов. Но патч этот уже несколько лет не выходит из бета-теста, насколько мне известно.
Я бы сделал так. Создать отдельные классы для web, почты и других нужных протоколов. Им дать повышенный приоритет, а весь неклассифицированный траффик(куда попадёт и торрент) завернуть в общий класс с самым низким приоритетом. В итоге в обычном режиме торрент отъест весь канал, но как только вы откроете, к примеру, браузер, торрент-траффик будет потеснён и освободятся нужные для веба скорости.
На tc это реализуется примерно так:
# ==== Корневая дисциплина 1:0. Тут же указано, что по умолчанию всё заворачивается в подкласс 100.
tc qdisc add dev eth0 root handle 1:0 htb default 100
# ==== Корневой класс 1:1. Эта команда для канала в 1 мбит.
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 1024kbit ceil 1024kbit burst 15k
# ==== Подкласс 1:5. В него заворачиваем неторрент-траффик(к примеру, всё, что идёт на 80,25,110 порты tcp и 53 udp - веб, почта и dns). В этом классе мы гарантируем 512 кбит в секунду.
tc class add dev eth0 parent 1:1 classid 1:5 htb rate 512kbit ceil 512kbit burst 5k prio 1
# ==== Дефолтовый подкласс 1:100, с самым низким приоритетом и гарантированной скоростью в 256 кбит в секунду.
tc class add dev eth0 parent 1:1 classid 1:100 htb rate 256kbit ceil 780kbit burst 15k prio 5
# Собственно правило заворота траффика в класс с повышенным приоритетом.
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 80 flowid 1:5
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 25 flowid 1:5
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 110 flowid 1:5
tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip dport 53 flowid 1:5
# И в конце подключаем дисциплину обработки очереди для равномерного и плавного распределения нагрузки.
tc qdisc add dev eth0 parent 1:5 handle 5: sfq
tc qdisc add dev eth0 parent 1:100 handle 100: sfq

Но учтите, что это только очень поверхностный пример. tc - очень гибкая, а потому сложная в освоении утилита. Она умеет всё. :)
Чтобы настроить управление траффиком под свои нужды рекомендую почитать Linux Advanced Routing & Traffic Control HOWTO. В сети было на русском. Ну или стучите в личку, скину по почте переведённый вариант.
Ну и само собой man tc.
А так же можно посмотреть на wondershaper(есть во многих дистрах или на сайте lartc.org).

Огромное спасибо!
Проверю.

Просветите __хотя бы одну__ строку для страждущих:

Не смейтесь, но какое слово здесь указывает на сии порты?

Почувствовал себя школяром)))

Пардон, понял) не дочитал)
А есть какие альтернативы sfq из двух последних строк?

Да, есть. Потробнее в man tc. Тут уж я не смогу внятно объяснить различия.
Сам я использую именно sfq обычно. Скорее дело привычки, нежели осознанный выбор.

tc class add - Создаём класс
dev eth0 - на интерфейсе eth0
parent 1:1 - у родительского класса 1:1
classid 1:5 - назначаем идентификатор для этого класса - 1:5
htb - назначаем дисциплину управления траффиком
rate 512kbit - максимальная скорость для этого класса
ceil 512kbit - минимальная скорость для этого класса
burst 5k - размеры фрагментов очереди
prio 1 - приоритет
Это примерный пересказ.
Но повторюсь, что лучше LARTC HOWTO и маны. Там всё объяснено понятнее. :)

Вы знаете, у меня немного другие взгляды на обучение) От того, что посоветовали на генту.ру (с опеннета, честно прочитанное) у меня эта тема надолго вызвала отвращение. Примеры странны показались. Да и немного их...

Т.е. имхо обучение надо базировать на решении таких вот КАЖДОДНЕВНЫХ проблем, разжевывая слова.
Ибо мозг, поставленный лицом перед теорией до практики - мгновенно засыпает.

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

Согласен. В случае с шейпером по одним манам разобраться ооочень тяжело. Как я и говорил выше tc - утилита сложная.
Но я потому и советую всем LARTC HOWTO. Там на примерах рассказывается, как решать различные задачи по управлению маршрутизацией и шейпингом.
Ну и конечно практика. Если не пробовать - ничего не получится. Главное не пугаться. Я понимаю, что выложенные мной команды выглядят довольно пугающе для человека, далёкого от системного администрирования. Однако на самом деле они вполне логичны и понятны. К примеру, этот пост я писал по памяти лишь пару раз заглянув в ман, а не копипастил из какой-то рабочей схемы(кстати, из-за этого может выскочить пара ошибок ;)).
В общем, повторю старую добрую фразу из vimtutor.

А на порты указывают правила filter

Попробуй xtables-addons, пересобирать ничего не придется, в ядре поддержка есть. Содержит матч ipp2p - как раз то, что надо.

Не изобретая велосипеда: уменьшить число соединений на одну загрузку и общее, нагрузка на канал уменьшиться!

Вопрос был не в этом

transmission тоже умеет

Вопрос был не в том чтобы руками ограничивать скорость.

Задать приоритет можно только для исходящего трафика, т.к. только в этом случае комп может расставить приоритет какой пакет отправить первым, а какой за ним.
А вот со входящим каналом всё намного хуже - пакеты присылает компу шлюз (или там ещё кто-нибудь кто выше стоит), а у компа остаётся только возможность его принять или отвергнуть. Не приняв он не узнает что это за пакет, а приняв - забьёт канал.
Соответственно и предугадать какой пакет сейчас придёт и какая будет максимальная скорость закачки пакетов - нельзя.
Поэтому контролировать скорость можно только чисто догадками, например если идёт закач в 500 кбит/сек, то в следующую секунду заказываем тока 250кбит/сек, оставшиеся 250 оставляем остальным. Но тут мешает тот факт что скорость часто гуляет, и с разных ресурсов скорость закачки разная. Поэтому либо задавать жестко максимальную скорость руками либо устраивать пляски с бубном.

Да. Тут есть проблема, но тоже отчасти решается шейпером, который не сразу пускает пакеты, а прогоняет их через буффер. И отдаёт их в соответствии с приоритетом. Для этого как праз и служат дисциплины типа sfq.

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

Ребята, у o default city наверное?
у меня канал 256кбит/с. торретс.ру такой забивает всегда на максимум...)

Мы тут с cppmm посовещались.
Тема была неплохо раскрыта здесь

Для страждущих подулюсь своими наработками: http://shilov.homeip.net/rc.shaper
за основу взят Wonder Shaper

О параметрах:
UPLINK -- реальная исходящая скорость kbit/sec, лучше чуть меньше.
ACK1 -- скорость ACK для обычного траффика, для регулирования входящей скорости. эксперементально было определено, что входящая скорость == ACK * 40
ACK2 -- это регулятор всего остального, некласифицируемого трафика. фактически это весь P2P.

Готов ответить на любые вопросы по своему "творению".

Как оно может работать с торрент клиентом?
Решает ли оно поставленную задачу в топике?

Может Вы создадите новый топик в блоге "мой опенсурс проект"?

Скрипт смотрел?
шейпер вешается на инте-интерфейс.
грубо говоря -- в нём три полосы:
1 - icmp, ssh -- интерактив
2 - телнет, веб, почта, фтп. можно оставить только веб.
3 - самый низкоприоритетный трафик, в котором всё остальное и торренты тоже.

ещё есть две полосы для ACK-пакетов -- с их помощью регулируется скорость скачки, и достаточно эффективно. скорость скачки нужно уменьшать до такого состояния, что-бы на графике скорости (я смотрю collectd, можно mrtg или подобное) небыло "полочки" -- только лёгкая "пила". это, в свою очередь, уберёт очередь на стороне провайдера, а это уже позволит получать в первую очередь более приоритетные пакеты.

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

в блоге "мой опенсурс проект" оно точно не нужно.

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