просто генератор старый а прошивка развивается вот в нй и замутили не правильную работу чтоб платили бабло за шейпер. _________________ http://lavrik-vorcuta.blogspot.com/
modprobe imq
modprobe ipt_IMQ
ip link set imq0 up
iptables -t mangle -A PREROUTING -j IMQ --todev 0
2. Выше строки
Code:
TCAU="tc class add dev imq0"
вносим
Code:
wanif=`nvram get wan_iface`
3. В оставшемся коде вместо интерфейса imq0 вносим $wanif .
Шейпер работает и для download, и для upload. Приоритезация на глаз вроде тоже задействуется. Для ограничения download можно задействовать не только интерфейс br0, но и vlan1. Остальные интерфейсы не проверял, так как на статике задействуется мост br0-vlan1. Гарантированная полоса (rate) по-моему всё равно не работает, хотя не полностью уверен, после внесения скрипта в firewall, интернет стал работать получше, не особо замечаю активное присутствие других ПК в моей внутренней сети за роутером. Один недостаток - режется скорость на Web-интерфейсе и при br0, и при vlan1, но это мелочи. И ещё, для задействования скрипта перезагружать маршрутизатор вовсе не обязательно, всё применяется и так, можно удобно экспериментировать. И не забываем указывать реальную или немного меньшую скорость подключения, в противном случае скрипт не будет работать.
Проверил работоспособность гарантированной полосы - параметры применяются. Ура, теперь никто не будет мешать друг другу. Скриншоты (видны только зарегистрированным пользователям или только мне):
http://i057.radikal.ru/1005/44/70ba940a2dac.png http://i073.radikal.ru/1005/7d/d47a011a6f6e.png
На одном ПК закачка в 8 потоков, на другом в 1. Без QoS 8 потоков "забили" бы 1. Но гарантированная полоса заработала и скорость на ПК с 8 потоками упала на треть, согласно правилу, а потом восстановилась после прекращения закачки на ПК с одним потоком. Судя по первому графику, время реакции QoS достаточно хорошее, а вот DM долго раскачивается (2-ой скриншот).
Вариант рабочего скрипта на 3 ПК, у всех одинаковая скорость, но разные приоритеты. Download режется на vlan1, upload - на wan:
Code:
TCA="tc class add dev vlan1 "
TFA="tc filter add dev vlan1 "
TQA="tc qdisc add dev vlan1 "
SFQ="sfq perturb 10"
tc qdisc del dev vlan1 root
tc qdisc add dev vlan1 root handle 1: htb
tc class add dev vlan1 parent 1: classid 1:1 htb rate 2000kbit
$TCA parent 1:1 classid 1:10 htb rate 600kbit ceil 2000kbit prio 2
$TCA parent 1:1 classid 1:11 htb rate 600kbit ceil 2000kbit prio 1
$TCA parent 1:1 classid 1:12 htb rate 600kbit ceil 2000kbit prio 3
$TQA parent 1:10 handle 10: $SFQ
$TQA parent 1:11 handle 11: $SFQ
$TQA parent 1:12 handle 12: $SFQ
$TFA parent 1:0 prio 2 protocol ip handle 10 fw flowid 1:10
$TFA parent 1:0 prio 1 protocol ip handle 11 fw flowid 1:11
$TFA parent 1:0 prio 3 protocol ip handle 12 fw flowid 1:12
iptables -t mangle -A POSTROUTING -d 192.168.1.101 -j MARK --set-mark 10
iptables -t mangle -A POSTROUTING -d 192.168.1.102 -j MARK --set-mark 11
iptables -t mangle -A POSTROUTING -d 192.168.1.103 -j MARK --set-mark 12
wanif=`nvram get wan_iface`
TCAU="tc class add dev $wanif"
TFAU="tc filter add dev $wanif"
TQAU="tc qdisc add dev $wanif"
tc qdisc del dev $wanif root
tc qdisc add dev $wanif root handle 1: htb
tc class add dev $wanif parent 1: classid 1:1 htb rate 2000kbit
$TCAU parent 1:1 classid 1:10 htb rate 600kbit ceil 2000kbit prio 2
$TCAU parent 1:1 classid 1:11 htb rate 600kbit ceil 2000kbit prio 1
$TCAU parent 1:1 classid 1:12 htb rate 600kbit ceil 2000kbit prio 3
$TQAU parent 1:10 handle 10: $SFQ
$TQAU parent 1:11 handle 11: $SFQ
$TQAU parent 1:12 handle 12: $SFQ
$TFAU parent 1:0 prio 2 protocol ip handle 10 fw flowid 1:10
$TFAU parent 1:0 prio 1 protocol ip handle 11 fw flowid 1:11
$TFAU parent 1:0 prio 3 protocol ip handle 12 fw flowid 1:12
iptables -t mangle -A PREROUTING -s 192.168.1.101 -j MARK --set-mark 10
iptables -t mangle -A PREROUTING -s 192.168.1.102 -j MARK --set-mark 11
iptables -t mangle -A PREROUTING -s 192.168.1.103 -j MARK --set-mark 12
При создании своего скрипта важно задействовать стратегию SFQ, иначе скрипт получится косячным.
круто.
А что будет, когда появится еще один участник сети? например приходящий гость с ноутом. какой он получит приоритет и полосу?
и на сколько я понял, твоя ширина канала 2 мегабита, а гарантированную ты даёшь 600кбит ?
и на сколько я понял, твоя ширина канала 2 мегабита, а гарантированную ты даёшь 600кбит?
Да.
dE1l wrote:
А что будет, когда появится еще один участник сети? например приходящий гость с ноутом. какой он получит приоритет и полосу?
В вышеприведённом скрипте он получит полную полосу и стандартный приоритет, QoS на него не будет распространяться.
А вот в нижеприведённом скрипте можно ограничивать скорость и приоритет для всех ПК, прямо не указанных в скрипте. Кроме того, можно почти полностью запретить пользоваться интернетом гостевым ПК, установив rate и ceil на 1кбит. А сейчас для гостей установлено 200кбит гарантированной полосы и 1000кбит максимальной с низким приоритетом.
Чтобы было понятнее, разделил скрипт на три части. Первая - общая, вторая для download, а третья на upload. Таким образом можно "выбрасывать" или вторую, или третью часть, если нет необходимости шейпить оба направления.
Это будет работать на подключении с ненормированной шириной канала -- ёта? Т.е. нужен только приоритет и гарантированнная полоса, без явного указания ширины канала.
Как всё это очистить, удалить из роутера, в случае чего?
И стоит ли заморачиваться с dir-320? Тут все пишут, что у него слабое железо и qos его нагнёт.
Это будет работать на подключении с ненормированной шириной канала -- ёта? Т.е. нужен только приоритет и гарантированнная полоса, без явного указания ширины канала.
Нет, указывать общую ширину канала обязательно. Если в скрипте оставить только rate на каждый ПК, а ceil убрать вместе с общим rate, то тогда скорость будет ограничиваться на величину rate для каждого ПК. Такой способ годится для не динамического шейпера. Пример (часть скрипта):
На нестабильном соединении, с плавающей скоростью, толку от динамического шейпера мало. Например, у кого скорость дневного подключения отличается от ночной не смогут пользоватся одним скриптом, надо делать два, да и ещё придумать как их запускать автоматически в нужное время. А приоритет можно указать в Web-интерфейсе. Правда не уверен, что почувствуете разницу.
Heretic71 wrote:
Как всё это очистить, удалить из роутера, в случае чего?
Нажать <Edit>, очистить Command Shell и сохранить <Save Firewall>.
Heretic71 wrote:
И стоит ли заморачиваться с dir-320? Тут все пишут, что у него слабое железо и qos его нагнёт.
Я вообще не замечаю дополнительной нагрузки на DIR-300 b1 после применения скрипта, процессор и память нагружены также как и без QoS.
Скрипт постом выше подходит для стабильной полосы от провайдера, без провалов скорости. Если провайдер указывает скорость до каких-то пределов, не уточняя гарантированную полосу, то скорее всего QoS не будет работать корректно.
Ещё мне не понятно как ограничивать трафик при dual access подключениях. Если для локальных ресурсов провайдера возможно и подойдёт вышеприведённый скрипт, только надо увеличить скоростные показатели, то для VPN интернета, наверное, надо создавать другой скрипт. Но как быть с WAN, где указывается скорость upload? Скорее всего на VPN подключениях обратный трафик надо ограничивать через imq0, который сейчас не хочет работать. Так что пока не всё ещё решено.
У кого dual access пишите своё решение проблемы. А пока можно 100% сказать, что скрипт подходит для подключения к интернету посредством DHCP и Static IP. На PPPoE, PPTP, L2TP тоже должно работать. А вот для PPPoE, PPTP, L2TP (dual access) подойдёт только download часть, с изменением интерфейса скорей всего на ppp0. Для локальной сети провайдера тоже должен подойти, но не уверен, надо проверять.
На нестабильном соединении, с плавающей скоростью, толку от динамического шейпера мало.
ну а что мешает указать максимальную скорость соединения, заявленную провайдером? да, правильного распределения скорости мы не получим, но гарантированную полосу и приоритеты будут, что на мой взгляд самое главное
ну а что мешает указать максимальную скорость соединения, заявленную провайдером? да, правильного распределения скорости мы не получим, но гарантированную полосу и приоритеты будут, что на мой взгляд самое главное
Ничто не мешает, но будет задействоваться только приоритет, гарантированная полоса заработает только при максимальной скорости провайдера. Как только скорость от провайдера упадёт ниже заявленной, сумма rate всех классов (хостов) превысит реальную пропускную способность канала, соответственно динамический шейпер просто не будет применён. А когда скорость в канале опять вернётся до заявленной, всё заработает снова.
Но если для гарантированной полосы указать как можно меньший rate, то тогда скрипт будет всегда работать правильно. Минус в том, что умышленно урезается полоса, которая могла бы быть больше при стабильной скорости от провайдера.
Кто может точно и развёрнуто объяснить, как правильно рассчитать величины burst, cburst? И для чего нужен cburst? Нашёл много информации, но вопросов стало больше, чем ответов. Или дайте ссылку на внятное объяснение. Будет ли это работать в dd-wrt и насколько это вообще нужно? Вот тут: http://soft.triolan.com.ua/books/1070-shejjper-v-linux-vtoraja-statja.html в главе 5.Ускорения как бы есть формула, но где узнать интервал срабатывания таймера не на x86, x64, а на обычном роутере? Иначе непонятно как вычислить величину burst. А может проще на глазок, скажем 5-10% от скорости канала?
Приоритезация на глаз вроде тоже задействуется. Для ограничения download можно задействовать не только интерфейс br0, но и vlan1. Остальные интерфейсы не проверял, так как на статике задействуется мост br0-vlan1. Гарантированная полоса (rate) по-моему всё равно не работает, хотя не полностью уверен, после внесения скрипта в firewall, интернет стал работать получше, не особо замечаю активное присутствие других ПК в моей внутренней сети за роутером. Один недостаток - режется скорость на Web-интерфейсе и при br0, и при vlan1, но это мелочи. И ещё, для задействования скрипта перезагружать маршрутизатор вовсе не обязательно, всё применяется и так, можно удобно экспериментировать. И не забываем указывать реальную или немного меньшую скорость подключения, в противном случае скрипт не будет работать.
