Всем не хворать!

Имеется slackware 12 + tc+htb шейпер, и локалка, ходящая через него в инет.
В течение большинства времени шейпер должен не вмешиваться в проходящий трафик.
Но как только устанавливается соединение по определенному порту (например радмин) - максимально быстро сузить занимаемую полосу и освободить половину канала для радмина.

имеется вот така поделка:

#!/bin/sh

TC="/sbin/tc"
IPT="/usr/sbin/iptables"

IFACE="eth0"
RATE="100" # kbit

$TC qdisc del dev $IFACE root
$TC qdisc add dev $IFACE root handle 1:0 htb default 50

$TC class add dev $IFACE parent 1:0 classid 1:1 htb rate ${RATE}kbit ceil ${RATE}kbit

$TC class add dev $IFACE parent 1:1 classid 1:10 htb rate $[$RATE/2]kbit ceil ${RATE}kbit burst 512kb
$TC class add dev $IFACE parent 1:1 classid 1:50 htb rate $[$RATE/5]kbit ceil ${RATE}kbit

$TC filter add dev $IFACE protocol ip parent 1:0 prio 1 handle 10 fw flowid 1:1

. ./common/ipt-flush.sh
$IPT -t mangle -A PREROUTING -i $IFACE -p tcp --sport 4899 -j MARK --set-mark 10
$IPT -t mangle -A PREROUTING -o $IFACE -p tcp --dport 4899 -j MARK --set-mark 10

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

Кому-нить приходилось сталкиваться?
Это как-нить лечится?
Закрывать все остальные порты на это время не предлагайте, такая идея у мну уже была =)
Юзеров полностью отрубать низя...

• Как снизить время реакции шейпера?,c0nfED, 13:16 , 28-Апр-08
  • Как снизить время реакции шейпера?,heap, 23:29 , 28-Апр-08
    • Как снизить время реакции шейпера?,c0nfED, 09:43 , 29-Апр-08
      • Как снизить время реакции шейпера?,pavel_simple, 10:41 , 29-Апр-08
      • Как снизить время реакции шейпера?,heap, 15:47 , 29-Апр-08
        • Как снизить время реакции шейпера?,c0nfED, 09:42 , 30-Апр-08
• Как снизить время реакции шейпера?,Z0termaNN, 17:12 , 30-Апр-08
  • Как снизить время реакции шейпера?,den, 21:49 , 30-Апр-08
    • Как снизить время реакции шейпера?,c0nfED, 08:24 , 04-Май-08

опечатка в последней строчке листинга...
-o $IFACE --> -i $IFACE  =))

>опечатка в последней строчке листинга...
>-o $IFACE --> -i $IFACE  =))

Не вчитывался в детали - но как-то смутило следующее:
1. Я бы оставил burst на автоматический выбор.
2. Определяя классы в htb использовал бы prio (man tc-htb):
prio priority  In the round-robin process, classes with the lowest priority field are tried for packets first.  Mandatory.
3. В filter трафик бы при этом как раз и заворачивал в нужный класс типа 1:10 или 1:50 - тот у кого приоритет шире, а не в 1:1.

>1. Я бы оставил burst на автоматический выбор.

пробовал.
когда нужно протолкнуть канал параллельно с фтп-сессией - без большого бёрста никак.

>2. Определяя классы в htb использовал бы prio (man tc-htb):
> prio priority  In the round-robin process, classes with the lowest
>priority field are tried for packets first.  Mandatory.

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

>3. В filter трафик бы при этом как раз и заворачивал в
>нужный класс типа 1:10 или 1:50 - тот у кого приоритет
>шире, а не в 1:1.

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

Может есть какой-нить радикально другой способ, без шейпинга? (циски и прочие аппаратности не предлагайте =))
Пусть даже с кратковременной ПОЛНОЙ остановкой юзерского трафика...
Задача - бысто договорить радмин на загруженном диалапе любым некоммерческим програмным путем! =)

не стал гадать почему не робит как надо с tc+htb
предлагаю альтернативный вариант
http://freshmeat.net/projects/shaperd/

>Задача - бысто договорить радмин на загруженном диалапе любым некоммерческим програмным путем!

Дык может проблема в диалапе - и не столько времени занимает перестройка шейпера, сколько очередm на модеме и со стороны провайдера рассасываются?

>Дык может проблема в диалапе - и не столько времени занимает перестройка
>шейпера, сколько очередm на модеме и со стороны провайдера рассасываются?

Дело точно не в прове, т.к. тестили также и в условиях локалки на сильно сниженной скорости интерфейса. При этом статический шейпинг на весь интерфейс работает легко. Шейпили до 115 кбит/сек, получили практически идеальные модемные условия. А вот динамические изменения трафика по приоритетам внутри этих 115 кбит/с получаются как описано в сабже.

>[оверквотинг удален]
>
>В принципе, работает, тока уж шибко медленно реагирует.
>Т.е. с момента возникновения трафика на радминский порт, свою половину канала радмин
>получает через несколько минут.
>
>Кому-нить приходилось сталкиваться?
>Это как-нить лечится?
>Закрывать все остальные порты на это время не предлагайте, такая идея у
>мну уже была =)
>Юзеров полностью отрубать низя...

я бы подкрутил r2q.
в конце-концов можно htb заменить hfsc

ваша проблема, что вы хотите сделать из говна конфетку. Сначала разберитесь с L2, а потом крутите софтовые решения по управлению трафика. Проведите аналогичные измерения в среде ethernet или atm.

>ваша проблема, что вы хотите сделать из говна конфетку. Сначала разберитесь с
>L2, а потом крутите софтовые решения по управлению трафика. Проведите аналогичные
>измерения в среде ethernet или atm.

измерения на eth проводились и упомянуты выше.
но, возможно, вы и правы, говно хоть крась, хоть бели...
тем не менее, все же удалось слегка улучшить картину времени реакции.
при экспериментах приоритетным являлся http и ssh, тесты проводились при двух одновременных ftp-сессиях, параллельно с которыми прорубалась http-закачка файла и ssh-подключение.
все это в "почти модемном" соединении 100kbit.
если кому интересно, выглядит это так:

#!/bin/sh

SPD="100"
MSR="kbit"

CADD="tc class add dev eth0 parent"
QADD="tc qdisc add dev eth0 parent"

shape_on() {

tc qdisc add dev eth0 root handle 1: htb default 12

$CADD 1: classid 1:1 htb rate $SPD$MSR ceil $SPD$MSR

#$CADD 1:1 classid 1:10 htb rate $[$SPD/2]$MSR ceil $SPD$MSR
#$CADD 1:1 classid 1:11 htb rate $[$SPD/4]$MSR ceil $SPD$MSR
#$CADD 1:1 classid 1:12 htb rate $[$SPD/5]$MSR ceil $SPD$MSR

$CADD 1:1 classid 1:10 htb rate 1$MSR ceil $SPD$MSR
$CADD 1:1 classid 1:11 htb rate 1$MSR ceil $SPD$MSR
$CADD 1:1 classid 1:12 htb rate 1$MSR ceil $SPD$MSR

echo "  Adding filters for port 80"
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
  match ip dport 80 0xffff flowid 1:10

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
  match ip sport 80 0xffff flowid 1:10

echo "  Adding filters for ports 22 and 2223"
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
  match ip dport 22 0xffff flowid 1:11

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
  match ip sport 22 0xffff flowid 1:11

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
  match ip dport 2223 0xffff flowid 1:11

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
  match ip sport 2223 0xffff flowid 1:11

$QADD 1:10 handle 20: pfifo limit 50
$QADD 1:11 handle 30: pfifo limit 50
$QADD 1:12 handle 40: sfq perturb 10

}

shape_off(){
tc qdisc del dev eth0 root > /dev/null 2>&1
if [ x$? != x0 ]; then
  echo "Nothing to remove"
else
  echo "Removed"
fi

}

case $1 in
"start"|"restart")
  shape_off
  shape_on
;;
"stop")
  shape_off
;;
*)
  echo "Usage: $0 start|stop|restart"
;;
esac

echo "  Done"