| Каталог документации / Раздел "Сети, протоколы, сервисы" / Оглавление документа |
| |
|
| Linux Advanced Routing & Traffic Control HOWTO | ||
|---|---|---|
| Назад | Глава 9. Дисциплины обработки очередей для управления пропускной способностью | Вперед |
Как уже говорилось, дисциплины обработки очереди определяют способ передачи данных. Бесклассовые дисциплины, в общем, получают данные, переупорядочивают, вносят задержку или уничтожают их.
Они могут использоватся для ограничения пропускной способности интерфейса целиком, без какого-либо разделения по классам. Крайне важно, чтобы вы поняли назначение этого типа очередей перед тем, как мы перейдем к классовым дисциплинам!
Наиболее распространенной дисциплиной является pfifo_fast -- она используется по-умолчанию.
Каждая из дисциплин имеет свои достоинства и недостатки. Не все из них досконально протестированы.
Эта дисциплина работает, как видно из названия, по принципу "первым пришел, первым ушел" (First In, First Out). Это означает, что ни один пакет не получает специальной обработки. Однако это не совсем так. Данная очередь имеет три, так называемых, "полосы". В каждой "полосе" пакеты обрабатываются по принципу FIFO. Но полоса 1 не будет обслуживаться до тех пор, пока есть пакеты в полосе 0. Аналогично, пока есть пакеты в полосе 1, не обрабатывается полоса 2.
Ядро учитывает значение поля пакета Type of Service, и направляет пакеты с установленным флагом 'минимальная задержка' в полосу 0.
Не путайте эту простую бесклассовую дисциплину с классовой дисциплиной PRIO! Хотя они ведут себя похожим образом, pfifo_fast является бесклассовой и вы не можете добавлять к ней другие дисциплины командой tc.
Вы не можете конфигурировать pfifo_fast, поскольку ее параметры жестко "зашиты". Вот ее конфигурация по умолчанию:
Определяет отображение пакетных приоритетов, присвоенных ядром, в полосы. Отображение основывается на значении поля TOS, которое выглядит следующим образом:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| PRECEDENCE | TOS | MBZ |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
Четыре бита TOS (поле TOS) определяются так:
Двоичн Десятичн Значение
---------------------------------------------------------
1000 8 Минимизировать задержку (md)
0100 4 Максимальная пропускная способность (mt)
0010 2 Максимальная надежность (mr)
0001 1 Минимальная стоимость (mmc)
0000 0 Обычное обслуживание
Поскольку справа еще есть 1 бит, реальное значение поля TOS вдвое больше значения битов TOS.
Команда tcpdump -v -v выводит значение всего поля TOS, а не только четырех бит. Оно приведено в
первой колонке таблицы:
TOS Биты Значение Приоритет Linux Полоса
-------------------------------------------------------------
0x0 0 Normal Service 0 Best Effort 1
0x2 1 Minimize Monetary Cost 1 Filler 2
0x4 2 Maximize Reliability 0 Best Effort 1
0x6 3 mmc+mr 0 Best Effort 1
0x8 4 Maximize Throughput 2 Bulk 2
0xa 5 mmc+mt 2 Bulk 2
0xc 6 mr+mt 2 Bulk 2
0xe 7 mmc+mr+mt 2 Bulk 2
0x10 8 Minimize Delay 6 Interactive 0
0x12 9 mmc+md 6 Interactive 0
0x14 10 mr+md 6 Interactive 0
0x16 11 mmc+mr+md 6 Interactive 0
0x18 12 mt+md 4 Int. Bulk 1
0x1a 13 mmc+mt+md 4 Int. Bulk 1
0x1c 14 mr+mt+md 4 Int. Bulk 1
0x1e 15 mmc+mr+mt+md 4 Int. Bulk 1
Куча цифр. Вторая колонка содержит значение четырех значимых битов поля TOS, а в третьей
расшифровывается значение. Например, 15 означает минимальную стоимость (Minimal Monetary Cost),
максимальную надежность (Maximum Reliability), максимальную полосу пропускания(Maximum
Throughput) И минимальную задержку (Minimum Delay).
В четвертой колонке приведены соответствующие уровни приоритетов, выставляемые ядром Linux.
В последней колонке демонстрируется результат отображения в полосы по-умолчанию. В командной строке это выглядит так:
1, 2, 2, 2, 1, 2, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1
Это означает, что, например, приоритет 4 отображается в первую полосу.
priomap позволяет задавать и более высокие приоритеты (> 7) ,
которые не соответствуют полю TOS, но они используются в других целях.
Ниже приводится таблица из документа RFC 1349 (за подробной информацией обратитесь к этому документу). Она показывает, каким образом приложения могут выставлять биты TOS:
TELNET 1000 (minimize delay)
FTP
Control 1000 (minimize delay)
Data 0100 (maximize throughput)
TFTP 1000 (minimize delay)
SMTP
Command phase 1000 (minimize delay)
DATA phase 0100 (maximize throughput)
Domain Name Service
UDP Query 1000 (minimize delay)
TCP Query 0000
Zone Transfer 0100 (maximize throughput)
NNTP 0001 (minimize monetary cost)
ICMP
Errors 0000
Requests 0000 (mostly)
Responses <same as request> (mostly)
Длина этой очереди определяется конфигурацией интерфейса, просмотреть которую можно командами ifconfig и ip. Для задания очереди длиной 10, выполните: ifconfig eth0 txqueuelen 10.
Вы не можете управлять этим параметром при помощи утилиты tc.
Token Bucket Filter (TBF) простая дисциплина очереди, которая передает поступающие пакеты со скоростью не превышающей административно заданный порог, но с возможностью превышающих его коротких всплесков.
TBF очень точная дисциплина, при этом она не создает серьезных нагрузок на сеть и процессор. Если вам нужно просто ограничить скорость на интерфейсе, то это первый кандидат на использование.
Реализована TBF в виде буфера, постоянно заполняющегося токенами с заданой скоростью. Наиболее важным параметром буфера является его размер, определяющий количество хранимых токенов.
Каждый прибывающий токен сопоставляеться с одним пакетом данных из очереди после чего удаляется. Связав этот алгоритм с двумя потоками -- токенов и данных, получим три возможных ситуации:
Данные прибывают со скоростью равной скорости входящих токенов. В этом случае каждый пакет имеет соответствующий токен и проходит очередь без задержки.
Данные прибывают со скоростью меньшей скорости поступления токенов. В этом случае лишь часть существующих токенов будет уничтожаться, потому они станут накапливаться до размера буфера. Далее, накопленные токены могут использоваться при всплесках, для передачи данных со скоростью превышающей скорость пребывающих токенов.
Данные прибывают быстрее, чем токены. Это означает, что в буфере скоро не останеться токенов, что заставит дисциплину приостановить передачу данных. Эта ситуация называется "превышением". Если пакеты продолжают поступать, они начинают уничтожаться.
Накопленные токены позволяют пропускать короткие всплески, но при продолжительном превышении пакеты будут задерживаться, а в крайнем случае -- уничтожаться.
Учтите, что в реальной реализации дисциплины, токены соответствуют байтам, а не пакетам.
Не смотря на то, что вам вероятно ничего не придется менять, дисциплина TBF имеет определенные параметры. В первую очередь это:
Limit -- это количество байт, которые могут быть помещены в очередь ожидания токенов. Эту же величину можно задать параметром latency, который определяет максимальный "возраст" пакета в очереди TBF. В последнем случае, во внимание принимается размер буфера, скорость и, если задана, пиковая скорость (peakrate).
Размер буфера в байтах. Максимальное количество байт, для которых токены могут быть доступны мгновенно. В целом, чем больше граничная скорость, тем больше должен быть размер буфера. Например, для ограничения на скорости 10 мбит/с на платформе Intel, вам нужен буфер размером как минимум 10 Кбайт, чтоб достичь заявленной скорости!
Если буфер слишком мал, пакеты могут уничтожаться. Это связано с тем, что каждый тик таймера будет генерироваться больше токенов, чем может поместиться в вашем буфере.
Пакет нулевого размера все равно использует полосу пропускания. В сетях ethernet, любой пакет имеет размер не менее 64 байт. MPU задает минимальное количество токенов для пакета.
Ограничение скорости.
Если на момент поступление пакета есть свободные токены, пакет пройдет очередь без каких-либо задержек. Так сказать, со скоростью света. Возможно, это не совсем то, чего вы хотите, особенно если вы используете большой буфер.
Параметр peakrate задает скорость, с которой элемент может проходить очередь. Согласно теории, это достигается организацией достаточной задержки между проходящими пакетами.
Очевидно, что максимальное значение peakrate, равное 1 Мбит/сек, накладывало бы сильное ограничение на область применения этой дисциплины. Однако, задание больших значений peakrate возможно. Достигается это за счет прохождения за один интервал времени более одного пакета данных.
По умолчанию, значение mtu равно одному пакету, т.е. за раз проходит только один пакет.
Для расчета максимально возможного значения peakrate, умножьте mtu на 100 (или, точнее, на HZ, которое равно 100 для платформы Intel и 1024 для Alpha)
Простая, но очень полезная конфигурация:
# tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540
Чем же она так замечательна? Если у вас есть сетевое устройство с большой очередью,
такое как DSL или кабельный модем, а вы обмениваетесь с ним данными через быстрое соединение,
например ethernet, вы обнаружите, что закачки полностью уничтожают возможность интерактивной работы.
Это связано с тем, что закачки заполняют очередь модема, которая часто очень большая. Большой размер очереди позволяет достичь хороших результатов при передаче больших объемов данных, но ведь это не совсем то, что вам нужно. Вы хотите, чтобы оставалась интерактивность и вы могли бы делать еще что-то полезное во время закачки.
Приведенная команда ограничивает скорость отправки данных так, чтобы очередь в модеме не образовывалась. Таким образом, очередь будет находится в Linux, где мы можем контролировать ее размер.
Замените 220 Кбит на реальную скорость, минус несколько процентов. Если у вас действительно быстрый модем, можете немного увеличить параметр burst.
Stochastic Fairness Queueing (SFQ) -- простая реализация семейства алгоритмов справедливой очередизации. Она не так точна, как другие дисциплины, но требует меньше рассчетов, и при этом поровну распределяет доступную полосу пропускания между сеансами.
Ключевым понятием в SFQ является диалог (или поток), который приблизительно соответствует сеансу TCP или потоку UDP. Трафик делится на достаточное количество очередей типа FIFO, по одной на каждый диалог. После этого, все очереди обрабатываются в циклическом порядке, тем самым обеспечивая каждому сеансу равные шансы на передачу данных.
Благодаря этому достигается очень ровное поведение, которое не позволяет какому-либо диалогу подавлять остальные. SFQ называется "стохастической", т.к. на самом деле для каждого сеанса очередь не формируется, а трафик делится на ограниченое количество очередей на основе хеш-алгоритма.
Из-за использования хеша, несколько сессий могут попасть в одну и ту же очередь, что уменьшает шансы на передачу каждого сеанса. Для того, чтобы эта проблема не ощущалась, SFQ часто меняет алгоритм хеширования, поэтому, если сессии и попадут в одну очередь, длиться это будет лишь несколько секунд.
Стоит заметить, что SFQ эффективен только если исходящий интерфейс полностью загружен! В противном случае очередь будет отсутствовать и, следовательно, никакого положительного эффекта наблюдаться не будет. Позже мы рассмотрим варианты комбинирования SFQ с другими дисциплинами для достижения наилучшего результата.
В частности, применение SFQ на ethernet интерфейсе к которому подключен кабельный модем или DSL маршрутизатор совершенно бессмыслено без органичения полосы пропускания!
SFQ в значительной степени самоконфигурирующаяся:
Интервал изменения алгоритма хеширования. Если не задан -- алгоритм меняться не будет, что не рекомендуется. Хорошим значением является 10 секунд.
Количество байт выводимых из очереди за один раз. По-умолчанию равно 1 пакету максимально возможного размера (MTU). Не устанавливайте этот параметр меньшим этого значения!
Общее количество пакетов, которые могут быть помещены в очередь SFQ (последующие пакеты будут уничтожаться).
Если у вас есть устройство, скорость соединения которого равна доступной полосе пропускания, например модем, следующий пример обеспечит разделение его возможностей между всеми пользователями:
# tc qdisc add dev ppp0 root sfq perturb 10
# tc -s -d qdisc ls
qdisc sfq 800c: dev ppp0 quantum 1514b limit 128p flows 128/1024 perturb 10sec
Sent 4812 bytes 62 pkts (dropped 0, overlimits 0)
Число 800c: это автоматически присваеваемый дескриптор, параметр limit говорит,
что в очереди может находиться до 128 пакетов. Доступно 1024 хеш-буфера, из которых 128 может быть
активно (максимальное число пакетов в очереди). Каждые 10 секунд хеши будут перенастраиваться.
| Назад | В начало документа | Вперед |
| Дисциплины обработки очередей для управления пропускной способностью | К началу раздела | Какие типы дисциплин нужно использовать. |
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |