Просмотр кода страницы Linux QOS:Тестирование различных вариантов управленя траффиком

[[Категория:not_tested]]
[[Категория:Linux]]
[[Категория:QOS]]
=Linux Shaper=
Эта тема всегда вызывала у меня некоторые затруднения и потому я решил систематизировать свои знания.

==Описание лаборатории==
Для тестирования я использую лабу из 3 виртуальных машин, виртуалбокс. Базовая ОС - Мак Ос
<PRE>
|-------|               |--------|               |-------|
|node-1 |-eth0-----eth1-|router0 |-eth2-----eth0-|node-2 |
|-------|               |--------|               |-------|
                            |
                           eth0
                            |
                           HOST
</PRE>
===node-1=== 
* 192.168.1.2
* Алиасами добавлены адреса 192.168.1.3-100 

===node-1=== 
* 192.168.2.2
* Алиасами добавлены адреса 192.168.2.3-100 

===Router0=== 
* eth1: 192.168.1.1
* eth2: 192.168.2.1
eth0 - служит для доступа к лабе и никак в тестах не участвует.
<BR>Все политики клсассы и прочее - только на транзитных интерфейсах eth1 и  eth2


==Базовое тестирование-ограничение скорости==
Так как планируется большое число тестов и большое число данных, то первым делом нужно подготовить автоматизацию.
Для генерации трафика я буду использовать iperf с переменным числом потоков, для сбора статистики - скрипт на питоне. Для визуализации - GnuPlot

===Как тестируем===
Тест проходит следующим образом:
* на node-1 запущены  множество экземпляров iperf  в режиме сервера
<PRE>
BASE_PORT=5000

for I in `seq 2 100`
do
    let PORT=BASE_PORT+I
    echo ${PORT}
    iperf -s -l 32k -w 512k -u -p ${PORT} -D
    iperf -s -l 32k -w 512k    -p ${PORT} -D
done
</PRE>
* на node-2 запускается iperf в 30  потоков, каждый - на другой порт и на другой IP, для того что бы в дальнейших тестах проверять классы трафика и 
для более равномерного распределения. sleep 30 - нужен для того что бы успеть запустить счетчики на ноде 1
<BR>
<B>В случае когда условия тестирования отличаются - я буду указывать отдельно</B>
<PRE>
#!/bin/bash

sleep 30

BASE_PORT=5000
for I in `seq 2 ${1}`
do
.
 IP=192.168.1.${I}
 let PORT=BASE_PORT+I
 #echo iperf -c ${IP}  -b 100000M  -i 1  -l 60K -t 120  -p ${PORT} -D
 iperf -c ${IP}  -b 100000M  -i 1  -l 60K -t 120  -p ${PORT} -D
 iperf -c ${IP}  -b 100000M  -i 1  -l 60K -t 120  -p ${PORT} -u -D
done
</PRE>
* В процессе работы собираем траффик наколенном скриптом на питоне и складываем в лог, потом рисуем график используя GnuPLOT
<PRE>
import time
import datetime as dt
import sys

stop_time=time.time()+300
iface='eth0'
sleep_time=0.5

tx_data_file = open('/sys/class/net/'+iface+'/statistics/tx_bytes', 'r')
rx_data_file = open('/sys/class/net/'+iface+'/statistics/rx_bytes', 'r')
res_file = open(str(sys.argv[1]),'w')

for l in rx_data_file:
  in_bytes_prev=int(l)

for l in tx_data_file:
  out_bytes_prev=int(l)

while True:
  try:
    rx_data_file.seek(0)
    tx_data_file.seek(0)

    for l in rx_data_file:
      in_bytes=int(l)
    for l in tx_data_file:
      out_bytes=int(l)


    in_bytes_diff=in_bytes-in_bytes_prev
    out_bytes_diff=out_bytes-out_bytes_prev

    in_bytes_prev=in_bytes
    out_bytes_prev=out_bytes
    time.sleep(sleep_time)

    res_file.write(str(time.time())+" "+str((in_bytes_diff)*8/sleep_time)+" "+str((out_bytes_diff)*8/sleep_time)+"\n")
    print str(time.time())+" "+str(in_bytes_prev)+" "+str(in_bytes)+" "+str((in_bytes_diff)*8)+" "+str(out_bytes_prev)+" "+str(out_bytes)+" "+str(out_bytes_diff)+" IN="+str((in_bytes_diff)*8/1024/1024/sleep_time)+" OUT="+str((out_bytes_diff)*8/1024/1024/sleep_time)

    if time.time()>stop_time:
      break
  except:
      break
res_file.close()
</PRE>
Скрипт для GnuPlot - заготовка из кототорой на лету формируем awk то что надо - подставляя входной файл, имя графика и т.д.
<PRE>
#!/usr/bin/gnuplot -persist

set terminal png  size 1400,600
# Размер и формат графика.

set output "/root/no_shaper.png"

set title "no_shaper"
# Заголовок

set nokey
# не знаю. Уточнить.
set key top left
# Расположение подписи
set key box
# Оформление (в рамке) подписи к графикам


set xlabel "Date"
# Метка по оси Х

set xdata time
# Описать что по оси Х время (формат ниже)
set timefmt "%s"
# Формат даты соответвует формату gnu date
# В моем случае был удобен такой формат.

set ylabel "Traffic"
#set format y '%.0s%cB'
set format y '%s'

plot \
"/root/no_shaper.log"  using 1:2 with lines  title "IN, bit/s"  smooth bezier, \
"/root/no_shaper.log"  using 1:2 with lines  title "IN, bit/s"  , \
"/root/no_shaper.log"  using 1:3 with lines  title "OUT, bit/s" smooth bezier, \
"/root/no_shaper.log"  using 1:3 with lines  title "OUT, bit/s"
[root@node-1 ~]# cat plot.sh
#!/usr/bin/gnuplot -persist

set terminal png  size 1400,600
# Размер и формат графика.

set output "___OUTPUT_FILE___"

set title "___TITLE_OF_PLOT___"
# Заголовок

set nokey
# не знаю. Уточнить.
set key top left
# Расположение подписи
set key box
# Оформление (в рамке) подписи к графикам


set xlabel "Date"
# Метка по оси Х

set xdata time
# Описать что по оси Х время (формат ниже)
set timefmt "%s"
# Формат даты соответвует формату gnu date
# В моем случае был удобен такой формат.

set ylabel "Traffic"
#set format y '%.0s%cB'
set format y '%s'

plot \
"___INPUT_FILE___"  using 1:2 with lines  title "IN, bit/s"  smooth bezier, \
"___INPUT_FILE___"  using 1:2 with lines  title "IN, bit/s"  , \
"___INPUT_FILE___"  using 1:3 with lines  title "OUT, bit/s" smooth bezier, \
"___INPUT_FILE___"  using 1:3 with lines  title "OUT, bit/s"
</PRE>

===Точка отсчета - без шейпера===
[[Изображение:No_shaper.png|800px|thumb|left|Тест без шейперов]]
<BR>

Для того что бы получить некоторую точку отсчета (учитывая что лаба - это ВМки) делаю первый прогон без ограничения трафика.
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

===Бесклассовые дисциплины===
Я не буду рассматривать в этом разделе дисциплины без возможности ограничения трафика - по той причине что на неогруженных интерфейсах это не имеет практического смысла  
====RED====
Отличная документация: "Подробнее с RED можно ознакомится в исходниках ядра"

====TBF====
Про TBF  много пишут но я никогда ее не использовал. Соответственно - нужно тестировать.<BR>
Как и все бесклассовые дисциплины крепиться или к листу (leaf) или к интерфейсу.<BR>
Об этом  напишу подробнее ниже.
<BR>
Напомню что eth1 -  интерфейс в сторону  node-1
<BR>
Удаляем текущую дисциплину
<PRE>
tc qdis del dev eth1 root
</PRE>
Убеждаемся что удалена (т е стоит по умолчанию pfifo_fast)
<PRE>
tc qdisc s  dev eth1
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc ingress ffff: parent ffff:fff1 ----------------
qdisc ingress ffff: parent ffff:fff1 ----------------
</PRE>
Второй раз удалить дисциплину по-умолчанию нельзя:
<PRE>
tc qdis del dev eth1 root
RTNETLINK answers: No such file or directory
</PRE>

Добавляем дисциплину tbf:
<PRE>
tc qdisc add dev eth1 root tbf rate 180kbit latency 20ms buffer 1540
</PRE>
Проверяем:
<PRE>
tc qdisc s  dev eth1
qdisc tbf 8002: root refcnt 2 rate 180000bit burst 1539b lat 20.0ms
qdisc ingress ffff: parent ffff:fff1 ----------------
</PRE>
=====Описание параметров=====
После длительного гугления я так и не нашел внятного описания параметров. Потому попробую процитировать
 
* rate — ограничение скорости
* latency — максимальный "возраст"пакета в очереди
* burst — размер буфера. В байтах.  (burst/buffer/maxburst - альтернативные названия что вносит некоторую путаницу)


Вот такое описание я нашел на Хабре, красным - мои вопросы<BR>
Дисциплина ТBF для своей работы использует механизм токенов. Токены генерируются системой с постоянной  <span style="color:#FF0000">какой???</span> скоростью  и помещаются в буфер(bucket). За каждый токен, вышедший из буфера с интерфейса уходит IP-пакет.<span style="color:#FF0000">А как  насчет размера пакета? скорость передачи зависит от размера пакета</span>
Если скорости передачи пакетов и генерации токенов совпадает, процесс передачи данных идет без задержки.
Если скорость передачи пакетов меньше чем скорость токенов, последние начинают накапливаться в буфере и затем могут использоваться для кратковременной передачи данных на скорости выше пороговой.
Если скорость передачи пакетов выше — токенов начинает не хватать. Пакеты данных ожидают новых токенов некоторое время <span style="color:#FF0000">Какое? думаю - пока не заполнится очередь заданая limit/latency</span>, а затем начинают отбрасываться.
<BR>
<BR>
Прямым следствием из этого я вижу следующее - если задать бурст ОЧЕНЬ большим то можно ожидать всплеска траффика в начале теста.
<BR>
Впрочем немного погуглив - найдено другое описание алгоритма
http://linux.die.net/man/8/tc-tbf

=====Результаты=====
[[Изображение:Tbf__rate__180000bit__burst__1539b__latency__20_0ms.png|600px|thumb|left|tbf]]
Результаты (для меня) достаточно неожиданные
* Таки да - достаточно четко  выставлена нужная скорость
* Явных потерь пингов я не наблюдаю
* Рост задержек явно не соответствует обещанным 20мс но и не запредельный
<PRE>
64 bytes from node-2 (192.168.2.2): icmp_seq=19 ttl=63 time=84.5 ms
64 bytes from node-2 (192.168.2.2): icmp_seq=20 ttl=63 time=84.6 ms
64 bytes from node-2 (192.168.2.2): icmp_seq=21 ttl=63 time=82.2 ms
64 bytes from node-2 (192.168.2.2): icmp_seq=28 ttl=63 time=86.0 ms
64 bytes from node-2 (192.168.2.2): icmp_seq=30 ttl=63 time=84.3 ms
64 bytes from node-2 (192.168.2.2): icmp_seq=37 ttl=63 time=84.1 ms
</PRE>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

=====Epic Fail=====
<PRE>
tc qdisc replace  dev eth1 root tbf rate 40Mbit   burst 159900000000000000 latency 10s
</PRE>
Kernel panic
<BR>
Судя по моим подсчетам - burst 159900000000000000  (который пересчитывается в байты при создании правила) израсходовал 1100Мб при том что на ВМке всего1 гиг - предположительная причина - перерасход памяти

=====Проверка предположения про burst=====
Как я писал выше,  предположение что установка огромного burst  вызовет всплеск трафика в начале теста требует подтверждения: настраиваю следующим образор
<PRE>
tc qdisc replace  dev eth1 root tbf rate 40Mbit   burst 159900000  latency 10s
</PRE>

[[Изображение:Tbf__rate__40Mbit__burst__Max__latency_10s.png|500px|thumb|center|]]

Как можно видеть по графику - предположение полностью подтверждается, наблюдаем явный пик трафика и потом переход к "нормальной скорости"

=====Проверка влияния burst и latency на поведение алгоритма=====
Попробуем собрать более-менее полную статистику по burst и latency. Для этого я в цикле прогоняю тесты при этом в каждом следующем тесте я делаю <B>burst=burst*N</B> что бы обеспечить более-менее приемлемую скорость  перебора. Аналогично - для latency. Все параметры теста вынесены в заголовок графика.

[[Изображение:001_tbf__rate___102400kbit__buffer_6160_latency_20ms.png|700px|thumb|center|]]
[[Изображение:001_tbf__rate___102400kbit__buffer_98560_latency_20ms.png|700px|thumb|center|]]
[[Изображение:001_tbf__rate___102400kbit__buffer_394240_latency_20ms.png|700px|thumb|center|]]
[[Изображение:003_tbf__rate___102400kbit__buffer_25231360_latency_20ms.png|700px|thumb|center|]]
[[Изображение:004_tbf__rate___102400kbit__buffer_413390602240_latency_5368709120ms.png|700px|thumb|center|]]
[[Изображение:004_tbf__rate___102400kbit__buffer_6614249635840_latency_85899345920ms.png|700px|thumb|center|]]


=====Выводы=====

Судя по тому что я вижу - TBF  неплохо подходит для простых случаев; хорошо масштабируемый до скоростей порядка 100Мбит.
Задирание буферов до запредельных значений смысла не имеет как и увеличение latency. 
<BR>
Насколько я могу судить  алгоритм достаточно точный - снимаемые с ноды значения соответвуют выставляемым на роутере.

===Классовые дисциплины===
Для простых случаев можно использовать и классовые дисциплины - при этом конструкции будут достаточно простые и понятные.
====HTB====
По-поводу HTB написано очень много - но вопросы с пониманием возникают постоянно. Потому я попробую собрать наиболее подробное и понятное описание из разных источников - такая компиляция.
<BR>
Вот неплохое описание:
<BR>
The Hierarchical Token Bucket (HTB) is an improved version of TBF that introduces the notion of classes. Each class is, in fact, a TBF-like qdisc, and classes are linked together as a tree, with a root and leaves. HTB introduces a number of features to improved the management of bandwidth, such as a the priority between classes, a way to borrow bandwidth from another class, or the possibility to plug another qdisc as an exit point (a SFQ for example).
<BR>
Т.е. для  начала считаем что HTB - это расширенная TBF с возможностью займа полосы и подключения к выходу других дисциплин.
=====Пробная настройка=====

У HTB  много малопонятных параметров - я постараюсь описать их по возможности подробно.<BR>
<B>ВАЖНО!!! Я НЕ использую никакую дисциплину в "листьях" - это тест ТОЛЬКО HTB </B>

Первым делом создаем  корневую дисциплину - у нее по сути есть всего 2 параметра
<PRE>
# tc qdisc add dev eth1 root handle 1: htb default 20
</PRE>

* default 20 — задаем класс по-умолчанию. В нем будут обрабатываться пакеты, не попавшие в другие классы дисциплины htb. 
Если его не указать, то будет назначен “default 0” и весь не классифицированный (не попавший под фильтры) трафик будет отправляться со скоростью интерфейса.
В моем случае когда надо ограничить весь трафик (базовый случай - аналог примера выше) это будет единственный класс и никаких фильтров применяться не будет. (примеры с фильтрами, приоритетами и деревьями классов - ниже, в другом разделе этого документа)

*  r2q      DRR quantums are computed as rate in Bps/r2q {10}
Есть несколько описаний но насколько я смог понять - это кванты трафика с которым работает HTB, очевидно что делать мелкие кванты при нынешних скоростях смысла нет. Приведу несколько описаний (автор - не я) 

** Второй параметр R2Q используется для квантования трафика в классах. В случае малых скоростей рекомендуется значение = 1, что позволяет шейпать с точностью до 4kbit. Если не указан, то =10, что для скоростей >120Kbit.


** Сейчас стоит рассмотреть понятие квантов трафика. В процессе конкурентной передачи данных нескольких классов обслуживание каждого из них начинается после того, как обработано некоторое количество байт предыдущего класса. Это количество байт называется квантом (quantum). Когда несколько классов претендуют на канал родительского, они получают части канала пропорциональные их квантам. Важно знать, что расчёт распределения канала тем точнее, чем меньше размер кванта (но квант всё же должен быть не меньше величины MTU). Как правило нет необходимости задавать кванты вручную, поскольку HTB рассчитывает их самостоятельно. Размер кванта класса устанавливается (при создании или изменении класса) равным запрошенной скорости делённой на глобальный параметр r2q. По умолчанию r2q равен 10, что приемлемо для скоростей выше 15 kbps (120 kbit), поскольку обычно MTU равен 1500. Для меньших скоростей величина r2q равна 1; это подходит для скоростей от 12 kbit.При желании можно установить величину кванта вручную. В этом случае параметр r2q игнорируется. Будут выведены предупреждения о том, что установленная величина не верна, но ими можно пренебречь.


http://forum.nag.ru/forum/index.php?showtopic=48277&st=0&p=609502&#entry609502

** Еще одно хорошее описание:
Уверен, многие сталкивались с проблемами:<BR> 
HTB: quantum of class 10001 is big. Consider r2q change или HTB: quantum of class 10001 is small. Consider r2q change.<BR>

<BR>Что делать вообще и как жить? На удивление информации нереально мало.
<BR>Но на форму nag.ru нашелся чудесный челвоек technolab, который дал следующие разъяснения:

<BR>MTU - максимальный размера блока в байтах который может быть передан.
<BR>Quantum - число байт, которые может передать поток перед переходом к следующему классу, по умолчанию = MTU интерфейса. Расчет распределения канала тем точнее, чем меньше это значение.
<BR>R2Q - глобальный параметр, по умолчанию R2Q = 10, если Quantum указан, то R2Q игнорируется.

<BR>Немного констант:
<BR>quantum = rate / r2q
<BR>mtu ≤ quantum ≤ 60000

<BR>Соответственно:
<BR>quantum is small => RATE / R2Q < MTU
<BR>quantum is big => RATE / R2Q > 60000

<BR>То есть, для шейпинга на скорсоти около 30 000 мегабит у нас интервал r2q лежит в районе 700-3000. Ограничения - нельзя делать делать меньше mtu и нельзя делать уж очень большим.
<BR>
<span style="color:#FF0000"> Вот этот момент не очень понятен - при больших скоростях r2q  надо брать достаточно большим что бы получался большой квантум - но как вычислили значения - не понятно
<BR> Пример с форума НАГа:
<PRE>
для примера на канал 900 мегабит
$TC->("qdisc add dev $dev root handle 1: htb r2q 37500");
автоматом будет посчитан quantum = 3000

ровно таким же макаром нужно считать для дочек 
</PRE>
<span style="color:#FF0000">
Сбивает с толку размерность<BR>
* mtu/mru - в байтах
* quantum - как производная от mtu - тоже в байтах 
* rate/ceil тоже надо указывать в байтах соответвенно имеем:

(quantum=3000)*(r2q=37500) = (rate=112500000  Мбайт/с) = (rate= 112500000*8/1000/1000 = 900 Mbit)
</span>
<BR>
<BR>

Создаем класс и прикрепляем его к корню:
<PRE>
# tc class add dev eth1 parent 1: classid 1:20 htb rate 180kbit ceil 180kbit
</PRE>

прикрепляем к root qdisc класс с идентификатором 1:1. Тем самым ограничиваем скорость на интерфейсе до 180Кбайт/c.

* classid 1:10 — идентификатор класса.
* rate 180kbit — устанавливаем нижний порог пропускной способности для класса. (в нашем простейшем случае - значения равны )
* ceil 180kbit — устанавливаем верхний порог пропускной способности для класса.
* burst - не устанавливаю
* cburst  - не устанавливаю
* prio 1 - приоритет, судя по документации классы работают в порядке приоритетов и пока есть трафик в классах с меньшим приоритетом классы с большим - не обрабатываются. Это утверждение требует проверки что будет сделано ниже - в классовых конфигурациях.
* quantum - не задаю, в базовом тесте полагаюсь на авторассчет
* mtu - я  не нашел описание должен ли МТУ класса быть равным МТУ интерфейса или больше него - но много примеров устанавливают МТУ 1600 (против 1500 на интерфейсе)

Кстати, в документации указано, что по факту в HTB шейпинг трафика происходит только в краевых классах, в нашем случае 1:20. Что часто сбивает с толку. Но в нашем случае это не нужно.

=====Результаты=====
Результаты пробного теста достаточно интересны (хотя и предсказуемые)
* Связь с сервером на время работы теста практически отсутствует, однако открыт вопрос - в каких таких буферах пинги стояли столько времени?
<BR>
<BR>
<BR> В качестве ответа на вопрос - следующая цитата:
<BR>
Within the one HTB instance many classes may exist. Each of these classes contains another qdisc, by default tc-pfifo(8).
<BR>
Т.е. сужествует  qdisc по умолчанию и это pfifo c огромными (судя по пингу) очередями


<PRE>
64 bytes from node-1 (192.168.1.2): icmp_seq=51 ttl=63 time=65415 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=55 ttl=63 time=65388 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=56 ttl=63 time=65325 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=74 ttl=63 time=64448 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=88 ttl=63 time=64280 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=94 ttl=63 time=64150 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=100 ttl=63 time=65329 ms
From 192.168.2.1 icmp_seq=172 Destination Host Unreachable
From 192.168.2.1 icmp_seq=173 Destination Host Unreachable
From 192.168.2.1 icmp_seq=174 Destination Host Unreachable
From 192.168.2.1 icmp_seq=175 Destination Host Unreachable
64 bytes from node-1 (192.168.1.2): icmp_seq=139 ttl=63 time=65715 ms
</PRE>
* Ограничение работает как и ожидалось 
[[Изображение:005_htb__rate___180kbit__default_burst_default_cburst_default_quantum.png|700px|thumb|center|]]

* burst  и cburst имеют разумные для такой скорости значения по-умолчанию
<PRE>
tc -s c s dev eth1
class htb 1:20 root prio 0 rate 180000bit ceil 180000bit burst 1599b cburst 1599b
 Sent 4276815 bytes 3106 pkt (dropped 1977877, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 3090 borrowed: 0 giants: 0
 tokens: 1081942 ctokens: 1081942
</PRE>

=====Повторное тестирование: разные скорости но настройки по-умолчанию=====
Для сбора статистики повторяем тест с разными скоростями
<PRE>
RATE=1
for I in `seq 1 7`
do
  let RATE=RATE*2
  tc qdis del root dev eth1
  tc qdisc replace  dev  eth1 root  handle 1:0 htb default 20
  tc class add dev eth1 parent 1: classid 1:20 htb rate ${RATE}Mbit ceil ${RATE}Mbit
...
done
</PRE>
Результат соответствует ожиданию - шейпер успешно отработал на скорости от 2Мбит до 128Мбит при автоматическом вычислении всех параметров, с ростом скоростей уменьшались только задержки пингов.
<BR>
Приведу только 2 крайних примера:<BR>
* 2 Mbit
[[Изображение:005_htb__rate___2Mbit__default_burst_default_cburst_default_quantum.png|700px|thumb|center|]] 
<PRE>
64 bytes from node-1 (192.168.1.2): icmp_seq=1 ttl=63 time=6007 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=3 ttl=63 time=5997 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=4 ttl=63 time=5995 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=5 ttl=63 time=5996 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=14 ttl=63 time=5982 ms
</PRE>
* 128Mbit
[[Изображение:005_htb__rate___128Mbit__default_burst_default_cburst_default_quantum.png|700px|thumb|center|]] 
<PRE>
64 bytes from node-1 (192.168.1.2): icmp_seq=504 ttl=63 time=105 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=506 ttl=63 time=103 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=510 ttl=63 time=101 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=512 ttl=63 time=100 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=513 ttl=63 time=101 ms
64 bytes from node-1 (192.168.1.2): icmp_seq=514 ttl=63 time=101 ms
</PRE>




===== HTB       =====

=====Burst cburst =====
* burst - это просто размер буффера в токенах и он должен быть достаточным, сверхбольшое его увеличение ничего не дает.
* cburst - аналог peack rate т.е. размер буфера токенов который будет использоваться при превышении над ceil.
<BR>Небольшая цитата:
<BR>
Сетевое устройство может передавать только один пакет в один момент времени и только с определенной устройством скоростью. Программам разделения канала остается только использовать эти параметры для расчетов деления канала на полосы требуемого размера. Таким образом, текущая и максимальная скорости передачи данных не могут быть урегулированы мгновенно. Они рассчитываются на основании усредненных данных о скорости отсылки пакетов. В действительности передача данных с учетом заданных свойств классов происходит следующим образом: устройству передается некоторое количество пакетов одного класса (которые отправляются в сеть со скоростью, определенной устройством, то есть максимально возможной), после чего некоторое время обрабатываются пакеты остальных классов. Параметры класса burst и cburst определяют количество данных, которое можно передать на максимальной скорости (скорости оборудования), после чего переключиться на обслуживание других классов.
<BR>
Чем меньше параметр cburst (в идеале он должен быть равен размеру одного пакета), тем лучше он сглаживает ускорение передачи данных, чтобы скорость передачи не превысила величину ceil. Так же действует параметр peakrate дисциплины TBF.
<BR>
Если параметр burst родительского класса меньше, чем у какого-нибудь из потомков, можно ожидать, что передача данных этого класса иногда будет останавливаться (так как дочерний класс пытается создать большее ускорение, чем позволено родительскому). HTB помнит о неудачной попытке ускорения в течение минуты.
<BR>
Возникает вопрос: для чего нужно регулировать ускорение? Дело в том, что это дешевый и простой способ улучшить время отклика на переполненных каналах. К резким колебания склонен, к примеру, веб-трафик. Вы запрашиваете страницу, создавая ускорение, потом читаете ее. За время чтения “накапливается энергия” для следующего ускорения.
<BR>
Параметры burst и cburst всегда должны быть не меньше, чем такие же параметры дочерних классов.
<BR>
Оперируя высокими скоростями на компьютере с низкой частотой таймера, необходимо минимизировать величины burst и cburst для всех классов. Интервал срабатывания таймера равен 10 ms для архитектуры i386 и 1 ms для Alpha. Минимальное эффективное ускорение рассчитывается по формуле (максимальная скорость)*(интервал таймера). Например, чтобы обеспечить скорость 10 mbit на компьютере i386 параметр burst должен быть равен 12kb.
<BR>
Заниженная величина burst приведет к тому, что данные будут передаваться на скорости, которая ниже запрошенной параметром rate. Последние версии tc по умолчанию самостоятельно рассчитывают и устанавливают минимальное значение burst.

<BR>
<B>С моей точки зрения практически во всех случаях можно положиться на автоматический расчет burst </B>
<BR> При задирании burst/cburst  поведение ожидаемое 
[[Изображение:007_htb__rate___1Mbit__default_burst_409600_cburst_409600_quantum.png|700px|thumb|center|]]
Отмечу что выстрелить себе в ногу htb не дает - burst нельзя поставить выше определенного (но мне неизвестного) значения и занять всю память - похоже что при превышении "лишние" знаки отбрасываются =)

===== HTB + TBF vs HTB + pfifo (default qdisc)=====
В этом тесте я пробую следующие конфигуации

* HTB  с qdisc  по-умолчанию (pfifo)

<PRE>
BASE_BUFFER=1540
BASE_LATENCY=20
RATE=1
BURST=1600
</PRE>
<PRE>
tc qdis del root dev eth1
tc qdisc replace  dev  eth1 root  handle 1:0 htb default 20
tc class add dev eth1 parent 1: classid 1:20 htb rate ${RATE}Mbit ceil ${RATE}Mbit burst ${BURST} cburst ${BURST}
</PRE>
[[Изображение:008_htb__rate___1Mbit__default_burst_1600_cburst_1600_quantum_no_leaf_qdisc.png|700px|thumb|center]]



* HTB + TBF, скорость qdisc = скорости htb leaf class
<PRE>
tc qdis del root dev eth1
tc qdisc replace  dev  eth1 root  handle 1:0 htb default 20
tc class add dev eth1 parent 1: classid 1:20 htb rate ${RATE}Mbit ceil ${RATE}Mbit burst ${BURST} cburst ${BURST}
tc qdisc add dev eth1 parent 1:20  tbf rate ${RATE}Mbit    buffer ${BASE_BUFFER} latency ${BASE_LATENCY}ms
</PRE>
[[Изображение:008_htb__rate___1Mbit__default_burst_1600_cburst_1600_quantum_tbf_leaf.png|700px|thumb|center]]


* HTB + TBF, скорость qdisc  в 2  раза больше  скорости htb leaf class
<PRE>
tc qdis del root dev eth1
tc qdisc replace  dev  eth1 root  handle 1:0 htb default 20
tc class add dev eth1 parent 1: classid 1:20 htb rate ${RATE}Mbit ceil ${RATE}Mbit burst ${BURST} cburst ${BURST}
let RATE=RATE*2
tc qdisc add dev eth1 parent 1:20  tbf rate ${RATE}Mbit    buffer ${BASE_BUFFER} latency ${BASE_LATENCY}ms
</PRE>
[[Изображение:008_htb__rate___1Mbit__default_burst_1600_cburst_1600_quantum_tbf_leaf_rate2.png|700px|thumb|center]]



* HTB + TBF, скорость qdisc  в 32  раза больше  скорости htb leaf class
<PRE>
tc qdis del root dev eth1
tc qdisc replace  dev  eth1 root  handle 1:0 htb default 20
tc class add dev eth1 parent 1: classid 1:20 htb rate ${RATE}Mbit ceil ${RATE}Mbit burst ${BURST} cburst ${BURST}
let RATE=RATE*32
tc qdisc add dev eth1 parent 1:20  tbf rate ${RATE}Mbit    buffer ${BASE_BUFFER} latency ${BASE_LATENCY}ms
</PRE>
[[Изображение:008_htb__rate___1Mbit__default_burst_1600_cburst_1600_quantum_tbf_leaf_rate32.png|700px|thumb|center]]
<PRE>
tc qdis del root dev eth1
tc qdisc replace  dev  eth1 root  handle 1:0 htb default 20
tc class add dev eth1 parent 1: classid 1:20 htb rate ${RATE}Mbit ceil ${RATE}Mbit burst ${BURST} cburst ${BURST}
let RATE=RATE*128
tc qdisc add dev eth1 parent 1:20  tbf rate ${RATE}Mbit    buffer ${BASE_BUFFER} latency ${BASE_LATENCY}ms
</PRE>

===== HTB + SFQ =====
SFQ  ( как я ВНЕЗАПНО узнал ) имеет достаточно большое число параметров

<BR>
http://stuff.onse.fi/man?program=tc-sfq&section=8
<BR>




*PARAMETERS
**divisor: Can be used to set a different hash table size,  available  from kernel 2.6.39 onwards.  The specified divisor must be a power of two and cannot be larger than 65536.  Default value: 1024.<span style="color:#FF0000">размер хеша, предположительно он должен быть не меньше числа flow</span>
**limit: Upper limit of the SFQ. Can be used to reduce the default length of 127 packets.  After linux-3.3, it can be raised.<span style="color:#FF0000">По сути - длинна буфера </span>
**depth: Limit  of packets per flow (after linux-3.3). Default to 127 and can be lowered.<span style="color:#FF0000">Этот параметр отвечает за то какая часть общего буфера определнного limit  может быть отдана каждому  flow </span>
**perturb: Interval in seconds for queue algorithm  perturbation.  Defaults to  0,  which  means that no perturbation occurs. Do not set too low for each perturbation may cause some  packet  reordering  or losses. Advised value: 60 This value has no effect when externalflow classification is used.  Its  better  to  increase  divisor value to lower risk of hash collisions.<span style="color:#FF0000">как часто делать ре-хеш</span>
**quantum: Amount  of  bytes a flow is allowed to dequeue during a round of the round robin process.  Defaults to the MTU of  the  interface which is also the advised value and the minimum value.<span style="color:#FF0000">квантум - порция данных которыми оперировать - делать кратным МТУ</span>
**flows: After  linux-3.3,  it is possible to change the default limit of flows.  Default value is 127<span style="color:#FF0000">Число флоу</span>
**headdrop: Default SFQ behavior is to perform tail-drop of packets  from  a flow.   You can ask a headdrop instead, as this is known to pro-vide a better feedback for TCP flows.
**redflowlimit: Configure the optional RED module on top of each SFQ flow.  Random  Early  Detection  principle  is  to perform packet marks or drops in a probabilistic way.  (man  tc-red  for  details  aboutRED). redflowlimit configures the hard limit on the real (not average) queue size per SFQ flow in bytes.
**min: Average  queue  size  at  which  marking  becomes a possibility. Defaults to max /3
**max: At this average queue size, the marking probability is  maximal. Defaults to redflowlimit /4
**probability: Maximum   probability   for   marking,  specified  as a floating point number from 0.0 to 1.0. Default value is 0.02
**avpkt: Specified in bytes. Used with burst to determine the  time  constant for average queue size calculations. Default value is 1000
**burst: Used  for  determining how fast the average queue size is influenced by the real queue size.Default value is : (2 * min + max) / (3 * avpkt)
**ecn: RED can either 'mark' or 'drop'. Explicit  Congestion  Notification  allows  RED to notify remote hosts that their rate exceeds the amount of bandwidth available.  Non-ECN  capable  hosts  can only  be  notified  by  dropping a packet.  If this parameter is specified, packets which indicate that  their  hosts  honor  ECN will  only be marked and not dropped, unless the queue size hits depth packets.
**harddrop: If average flow queue size is above max  bytes,  this  parameter forces a drop instead of ecn marking.


* HTB + SFQ

<B>Попробуем разные параметры</B>
<BR>
При установке flows=1 - получаем поведение FIFO  с коротким буфером (depth не может быть больше 127)
<BR>
Ожидаемое поведение - при нагрузке получим потери пинга близко к 100% 
<PRE>
[root@router0 ~]# tc -s -d q s dev eth1
qdisc htb 1: root refcnt 2 r2q 10 default 20 direct_packets_stat 0 ver 3.17
 Sent 28253598 bytes 19524 pkt (dropped 44841, overlimits 73764 requeues 0)
 backlog 0b 0p requeues 0
qdisc sfq 40: parent 1:20 limit 127p quantum 1514b depth 127 flows 1/1024 divisor 1024 perturb 10sec
 Sent 28253598 bytes 19524 pkt (dropped 44841, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
</PRE>
Собственно это мы и наблюдаем: даже АРП перестал ходить.

<PRE>
From router0 (192.168.2.1) icmp_seq=218 Destination Host Unreachable
From router0 (192.168.2.1) icmp_seq=219 Destination Host Unreachable
</PRE>

<B>Пробую указать divisor=1<BR> </B>
Видно что flows=1 (что логично - нет смысла создавать неиспользуемые потоки)
<PRE>
[root@router0 ~]# tc -s -d q s dev eth1
qdisc htb 1: root refcnt 2 r2q 10 default 20 direct_packets_stat 0 ver 3.17
 Sent 28419225 bytes 19618 pkt (dropped 201715, overlimits 240233 requeues 0)
 backlog 0b 0p requeues 0
qdisc sfq 40: parent 1:20 limit 127p quantum 1514b depth 127 flows 1/1 divisor 1 perturb 10sec
 Sent 28419225 bytes 19618 pkt (dropped 201715, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0

</PRE>
<PRE>
245 packets transmitted, 60 received, +9 errors, 75% packet loss, time 246003ms
</PRE>


<PRE>
BASE_BUFFER=1540
RATE=1
BURST=1600
PERTURB=10
LIMIT=127
</PRE>
<PRE>
  tc qdis del root dev eth1
  tc qdisc replace  dev  eth1 root  handle 1:0 htb default 20
  tc class add dev eth1 parent 1: classid 1:20 htb rate ${RATE}Mbit ceil ${RATE}Mbit burst ${BURST} cburst ${BURST}
  tc qdisc add dev eth0 parent 1:20 handle 40: sfq perturb ${PERTURB} limit ${LIMIT}
</PRE>
[[Изображение:010_htb__rate___1Mbit__default_burst_1600_cburst_1600_quantum_sfq_perturb_10__limit_127.png|700px|thumb|center]]
<PRE>
tc -s -d q s dev eth1
qdisc htb 1: root refcnt 2 r2q 10 default 20 direct_packets_stat 0 ver 3.17
 Sent 48001878 bytes 33888 pkt (dropped 220259, overlimits 280718 requeues 0)
 backlog 0b 0p requeues 0
qdisc sfq 40: parent 1:20 limit 65024p quantum 1514b depth 127 flows 512/16384 divisor 16384 perturb 1sec
 Sent 48001878 bytes 33888 pkt (dropped 220259, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
</PRE>



<PRE>
[root@router0 ~]# tc -s qdis s dev eth1
qdisc htb 1: root refcnt 2 r2q 10 default 20 direct_packets_stat 0
 Sent 19117534 bytes 24442 pkt (dropped 136167, overlimits 164327 requeues 0)
 backlog 0b 0p requeues 0
qdisc sfq 40: parent 1:20 limit 127p quantum 1514b depth 127 divisor 1024 perturb 10sec
 Sent 19117534 bytes 24442 pkt (dropped 143008, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
</PRE>
[[Изображение:010_htb__rate___1Mbit__default_burst_1600_cburst_1600_quantum_sfq_perturb_10__limit_127_1.png|700px|thumb|center]]

====HFSC====
* http://ace-host.stuart.id.au/russell/files/tc/doc/sch_hfsc.txt
* http://linux-ip.net/articles/hfsc.en/

==Источники==
* http://habrahabr.ru/post/138463/
* http://habrahabr.ru/post/138562/
* http://habrahabr.ru/post/133076/

* http://www.opennet.ru/base/net/linux_traffic_qos.txt.html
* http://www.opennet.ru/base/net/htb_manual.txt.html

* http://ace-host.stuart.id.au/russell/files/tc/doc/sch_hfsc.txt


* http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:networking:traffic_control#tbf_-_token_bucket_filter
* http://xgu.ru/wiki/QoS_%D0%B2_Linux



* http://forum.nag.ru/forum/index.php?showtopic=48277&st=0&p=609502&#entry609502