Ты таким макаром torrent не отдетектишь. Тебе нужен ipp2p из patch-o-matic. Им детектишь torrent, маркируешь пакеты и соединения, а с помощью tc уже шейпишь на основе меток.

И забудь о шифровании torrent'а. Иначе ipp2p ловить torrent не сможет.

-=:=-

Эм...как это не отдетектишь?
Как только я зажимаю DOWNLOAD/10 - кач торрентом сразу падает до 1.2 мбайт/c. Тоесть «$ifb root handle 1: htb default 50» реально кидает траффик в «/tc class add dev $ifb parent 1:1 classid 1:50 htb rat****» класс.

Вопрос в том, как правильно шейпить? Чтобы любой класс с приоритетом Выше ниже лежащего оттягивал на себя максимум, что может.

Хз, когда я пробовал, оно создавало кучу related соединений на других портах, и без ipp2p их детектить было не судьба. Для себя нашёл единственный рабочий вариант с ipp2p.

А, я понял. Вопрос в том, что ты не хочешь указывать максимальный предел, и спрашиваешь, как сделать без него? Никак. Ты должен знать пропускную способность канала.

-=:=-

Эм...ну так я знаю. $[$сотка-5мбит].
То есть тупо Резать по живому? Вариантов «отжать по приоритету» не существует?

Шейпер что, не может на автомате уменьшать рейт или цел для менее важных приоритетов???

Ну не может такого быть, наф тогда вообще шейпинг есть?

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

Шейпер что, не может на автомате уменьшать рейт или цел для менее важных приоритетов???

Не понял, а на основе чего он должен это делать? Пока есть свободные тикеты, пакеты будут передаваться. Тикетов нет - пакеты дропаются. Вся логика основана на известной полосе пропускания канала. Если она указана неверно, логика ломается.

Не совсем разбирался в вопросе, но, вероятно, проблема в следующем: торрент не фиксирован на определенном порту (исходящий - можно зафиксировать, входящий зависит от сидов). Насколько я вижу, шейпинг настроен по портам, стало быть если рабочий порт не указан в списке, на него распространяется только ограничение всего интерфейса. То есть совет про ipp2p - наиболее подходящее решение.

Да дело в другом. Указана завышенная полоса. Ну либо не все пакеты подпадают под условия фильтрации.

-=:=-

Нет. в том то и дело, торрент шейпится дефолтом 1:50.
Другое дело, что его можно только жестко фиксировать. Не могу заставить шейпер ужимать его динамически.

Погоди, а каким фильтром ты помещаешь torrent-трафик в класс? А то я сейчас попытался разобраться в скрипте и не увидел фильтра для torrent.

Вот и я о том же. Я там увидел только фильтры по конкретным портам.

-=:=-

Без разницы. Специально добавил
tc filter add dev $ifb parent 1:0 protocol ip prio 7 u32 match ip dst 172.16.81.97/32 flowid 1:50

Как торрент попадал в 1:50 так и попадает.

А вот прикол в том, что speedtest успешно отжимает у торрента канал.
P.S. ОБновил пасту.

а 172.16.81.97/32 - это пир, с которого ты качаешь?

Всё, понял. 1:50 у тебя дефолтный класс.

-=:=-

Это eth0. Дырко во вне.

-=:=-

wget -O /dev/null http://speedtest.tele2.net/10GB.zip выдает сейчас 10.5 мбайт/c.

Если торрент запустит - его поджимает до 500-800 кбайт/с

То есть реально не 95 мегабит, а меньше

Что будет если UPLOAD и DOWNLOAD поставить 80?

И что ты хочешь?

1. Вруби sfq_codel
2. Шейпить трафик на принимающей стороне - глупо даже в теории.

2. Шейпить трафик на принимающей стороне - глупо даже в теории.

Не совсем. Можно дропать часть пакетов, заставляя отправляющую сторону снижать скорость.

-=:=-

Что будет если UPLOAD и DOWNLOAD поставить 80?

Поставил 85.

Торрент около 8500 кбайт жмет.
http://speedtest.tele2.net/10GB.zip прыгает от 900 кбайт до 1.5 мбайт.

Можно дропать часть пакетов, заставляя отправляющую сторону снижать скорость.

Насколько я понимаю, довольно фиговое решение IRL.

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

Причём, возможно что временами его будет больше, чем 100 Мбит и на оборудовании провайдера может возникать очередь пакетов. Очередь — задержка в передачи, когда задержка большая, то на скорость работы tcp уже будет влиять размер окна и другие параметры tcp-соединения и тут уже сравнивать скорость с разных серверов не корректно. Чудес не бывает, хорошего полосования без резревирования части полосы нет.