Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO
Повторюсь еще раз, полоса 0 получит младший номер дескриптора — 1! Полоса 1 — 2 и так далее.
9.5.3.2. Пример конфигурации.
В качестве примера создадим такое дерево:
1: корневая дисциплина
/ |
/ |
/ |
1:1 1:2 1:3 классы
| | |
10: 20: 30: дисциплины
sfq tbf sfq
полоса 0 1 2
Объемный трафик будет обслуживаться дисциплиной 30: , интерактивный — 20: или 10:.
Конфигурирование:
# tc qdisc add dev eth0 root handle 1: prio
## Эта команда создаст классы 1:1, 1:2, 1:3
# tc qdisc add dev eth0 parent 1:1 handle 10: sfq
# tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000
# tc qdisc add dev eth0 parent 1:3 handle 30: sfq
Теперь посмотрим – что у нас получилось:
# tc –s
qdisc ls dev eth0 qdisc sfq 30: quantum 1514b
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
qdisc sfq 10: quantum 1514b
Sent 132 bytes 2 pkts (dropped 0, overlimits 0)
qdisc prio 1: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 174 bytes 3 pkts (dropped 0, overlimits 0)
Как видите, через полосу 0 уже "проскочил" какой-то трафик, пока отрабатывали наши команды!
Теперь выполним передачу достаточно большого объема данных неким инструментом, который корректным образом устанавливает флаги TOS и проверим еще раз:
# scp tc [email protected]:./
[email protected]'s password:
tc 100% |*****************************| 353 KB 00:00
# tc –s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b
Sent 384228 bytes 274 pkts (dropped 0, overlimits 0)
qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms
Sent 2640 bytes 20 pkts (dropped 0, overlimits 0)
qdisc sfq 10: quantum 1514b
Sent 2230 bytes 31 pkts (dropped 0, overlimits 0)
qdisc prio 1: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 389140 bytes 326 pkts (dropped 0, overlimits 0)
На этот раз видно, что весь трафик был отправлен через дисциплину 30:, которая в нашем случае имеет наименьший приоритет. Чтобы убедиться в том, что интерактивный трафик поступает в высокоприоритетные полосы, выполним следующую команду:
# tc –s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b
Sent 384228 bytes 274 pkts (dropped 0, overlimits 0)
qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms
Sent 2640 bytes 20 pkts (dropped 0, overlimits 0)
qdisc sfq 10: quantum 1514b
Sent 14926 bytes 193 pkts (dropped 0, overlimits 0)
qdisc prio 1: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 401836 bytes 488 pkts (dropped 0, overlimits 0)
Как видите, все работает правильно, весь трафик был отправлен в 10: — через самую высокоприоритетную дисциплину.
9.5.4. Дисциплина CBQ.
Как уже упоминалось ранее, CBQ — одна из самых сложных дисциплин. Пожалуй я не погрешу против истины, если заявлю, что это самая объемная, самая непонятная и самая запутанная дисциплина организации очередей. Это не потому, что авторы алгоритма некомпетентны, а потому, что идеология этого алгоритма абсолютно не совпадает с идеологией Linux.
Кроме того, что эта дисциплина является классовой, она так же может выполнять и шейпинг трафика, правда именно эта ее сторона является самым слабым местом. Если вы попробуете ограничить 10 мегабитный канал величиной в 1 мегабит, то окажется, что соединение будет просто простаивать 90% всего времени. Вместо определения объема трафика, CBQ измеряет время в микросекундах между запросами и на основе полученного времени рассчитывается средняя загруженность канала.
Такой алгоритм работы не всегда дает нужные результаты. Например, что если сетевой интерфейс не может обеспечить полную загрузку канала на всю его возможную ширину, из-за некачественного драйвера? Как тогда правильно определить время простоя?
Проблема становится еще острее, если вам приходится иметь дело с такими вещами, как PPP через Ethernet или PPTP через TCP/IP. Эффективная пропускная способность в данном случае может быть определена как пропускная способность канала в пространство пользователя, а это величина очень не маленькая.
Те, кто близко сталкивался с CBQ отмечают, что эта дисциплина не всегда точна, и иногда допускает грубые просчеты при измерении времени.
Однако, в других случаях она показывает неплохие результаты. Прочитав этот документ, вы сможете сконфигурировать эту дисциплину и получить неплохие результаты в случае отказа от шейпинга.
9.5.4.1. Шейпинг в CBQ.
Как уже говорилось выше, ограничение пропускной способности в CBQ выполняется за счет определения промежутка времени между прохождением соседних пакетов среднего размера.
В процессе работы измеряется эффективное время простоя, как экспоненциальное взвешенное среднее по скользящему окну. Кстати, UNIX рассчитывает величину loadaverage (средняя величина нагрузки) аналогичным способом.
Расчетное время простоя вычитается из взвешенного среднего, в результате получается величина avgidle. Полностью загруженный канал имеет величину avgidle равную нулю – промежуток времени между пакетами точно совпадает с расчетным. В случае превышения заданного ограничения, величина avgidle становится отрицательной. Если превышение достигает некоторого порога, CBQ приостанавливает передачу.
С другой стороны, после нескольких часов простоя, величина avgidle может получиться слишком большой и это приведет к тому, что канал "распахнется" на всю ширину. Чтобы этого не происходило, величина avgidle ограничивается числом maxidle.
В случае перегрузки, теоретически, алгоритм CBQ должен приостанавить передачу на вычисленный временной интервал, потом передать следующую порцию данных и снова остановиться. Но в реализации алгоритма есть свои нюансы, смотрите ниже описание параметра minburst.
Рассмотрим параметры дисциплины CBQ, позволяющие настроить ограничение полосы пропускания:
avpkt
Усредненный размер одного пакета. Совместно с величиной maxburst (которая измеряется в пакетах) используется для вычисления значения maxidle.
bandwidth
Физическая пропускная способность устройства. Необходима для вычисления времени простоя.
cell
Время, необходимое на передачу пакета через интерфейс может увеличиваться с определенным шагом. Например, передача пакетов с размерами 800 и 806 байт займет одно и тоже время, а пакетов с размерами 810 байт – немного больше. Данный параметр задает размер шага, с которым увеличивается расчетное время передачи. Чаще всего устанавливается значение '8'. Значение должно быть степенью числа 2.
maxburst
Параметр используется для вычисления значения maxidle. Он задает количество усредненных пакетов, которые будут обработаны до того, как значение avgidle станет равным нулю. Параметр maxidle нельзя задать напрямую, только косвенно, с помощью этого параметра.
minburst
Как я уже говорил, в случае перегрузки, CBQ должна прекратить передачу данных. Идеальным решением является ожидание в течение расчетного промежутка времени, после этого передать один пакет и снова приостановить передачу. Однако, в Unix существует определенные сложности с измерением интервалов времен, короче 10 мс, потому лучше увеличить промежуток ожидания, после которого можно будет выполнить передачу уже не одного, а несколько пакетов, количество которых определяется параметром minburst . Соответственно, промежуток ожидания между передачей пакетов увеличивается пропорционально значению данного параметра.
Промежуток времени между передачей пакетов называется offtime . Большие значения параметра minburst позволяют более точно ограничить полосу пропускания на длительных временных интервалах, но на коротких интервалах трафик будет вести себя скачкообразно.
minidle
Отрицательное значение avgidle указывает, что канал перегружен, и нужно прекратить передачу на время, пока avgidle не увеличится достаточно для передачи следующего пакета. Однако, это может вызвать длительные периоды ожидания после интенсивных всплесков трафика. В таких случаях avgidle присваивается значение параметра minidle.
Величина minidle измеряется в отрицательных микросекундах, следовательно значение "10" говорит о том, что параметр avgidle не может опуститься ниже –10 микросекунд.
mpu
Минимальный размер пакета — необходим, поскольку даже "пустой" пакет дополняется до 64 байт для передачи по сети ethernet, и передача такого пакета занимает определенное время. Алгоритм CBQ должен знать минимальный размер, чтобы правильно рассчитать время простоя.
