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

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


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

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

В том-то и вся проблема, что сложно отличить торрент-траффик от остального. Он может идти по разным портам. Один из вариантов - собирать собственный iptables с модулем, умеющим класифицировать траффик по содержимому пакетов. Но патч этот уже несколько лет не выходит из бета-теста, насколько мне известно.
Я бы сделал так. Создать отдельные классы для web, почты и других нужных протоколов. Им дать повышенный приоритет, а весь неклассифицированный траффик(куда попадёт и торрент) завернуть в общий класс с самым низким приоритетом. В итоге в обычном режиме торрент отъест весь канал, но как только вы откроете, к примеру, браузер, торрент-траффик будет потеснён и освободятся нужные для веба скорости.
На tc это реализуется примерно так:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

# ==== Корневая дисциплина 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.

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

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