9.2. Простые бесклассовые дисцплины обработки очереди.

Как уже говорилось, дисциплины обработки очереди определяют способ передачи данных. Бесклассовые дисциплины, в общем, получают данные, переупорядочивают, вносят задержку или уничтожают их.

Они могут использоватся для ограничения пропускной способности интерфейса целиком, без какого-либо разделения по классам. Крайне важно, чтобы вы поняли назначение этого типа очередей перед тем, как мы перейдем к классовым дисциплинам!

Наиболее распространенной дисциплиной является pfifo_fast -- она используется по-умолчанию.

Каждая из дисциплин имеет свои достоинства и недостатки. Не все из них досконально протестированы.

9.2.1. pfifo_fast

Эта дисциплина работает, как видно из названия, по принципу "первым пришел, первым ушел" (First In, First Out). Это означает, что ни один пакет не получает специальной обработки. Однако это не совсем так. Данная очередь имеет три, так называемых, "полосы". В каждой "полосе" пакеты обрабатываются по принципу FIFO. Но полоса 1 не будет обслуживаться до тех пор, пока есть пакеты в полосе 0. Аналогично, пока есть пакеты в полосе 1, не обрабатывается полоса 2.

Ядро учитывает значение поля пакета Type of Service, и направляет пакеты с установленным флагом 'минимальная задержка' в полосу 0.

Не путайте эту простую бесклассовую дисциплину с классовой дисциплиной PRIO! Хотя они ведут себя похожим образом, pfifo_fast является бесклассовой и вы не можете добавлять к ней другие дисциплины командой tc.

9.2.1.1. Параметры и использование

Вы не можете конфигурировать pfifo_fast, поскольку ее параметры жестко "зашиты". Вот ее конфигурация по умолчанию:

priomap

Определяет отображение пакетных приоритетов, присвоенных ядром, в полосы. Отображение основывается на значении поля 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)                  
                  

txqueuelen

Длина этой очереди определяется конфигурацией интерфейса, просмотреть которую можно командами ifconfig и ip. Для задания очереди длиной 10, выполните: ifconfig eth0 txqueuelen 10.

Вы не можете управлять этим параметром при помощи утилиты tc.

9.2.2. Token Bucket Filter

Token Bucket Filter (TBF) простая дисциплина очереди, которая передает поступающие пакеты со скоростью не превышающей административно заданный порог, но с возможностью превышающих его коротких всплесков.

TBF очень точная дисциплина, при этом она не создает серьезных нагрузок на сеть и процессор. Если вам нужно просто ограничить скорость на интерфейсе, то это первый кандидат на использование.

Реализована TBF в виде буфера, постоянно заполняющегося токенами с заданой скоростью. Наиболее важным параметром буфера является его размер, определяющий количество хранимых токенов.

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

Последняя ситуация очень важна, поскольку позволяет административно ограничивать доступную полосу пропускания.

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

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

9.2.2.1. Параметры и использование

Не смотря на то, что вам вероятно ничего не придется менять, дисциплина TBF имеет определенные параметры. В первую очередь это:

limit или latency

Limit -- это количество байт, которые могут быть помещены в очередь ожидания токенов. Эту же величину можно задать параметром latency, который определяет максимальный "возраст" пакета в очереди TBF. В последнем случае, во внимание принимается размер буфера, скорость и, если задана, пиковая скорость (peakrate).

burst/buffer/maxburst

Размер буфера в байтах. Максимальное количество байт, для которых токены могут быть доступны мгновенно. В целом, чем больше граничная скорость, тем больше должен быть размер буфера. Например, для ограничения на скорости 10 мбит/с на платформе Intel, вам нужен буфер размером как минимум 10 Кбайт, чтоб достичь заявленной скорости!

Если буфер слишком мал, пакеты могут уничтожаться. Это связано с тем, что каждый тик таймера будет генерироваться больше токенов, чем может поместиться в вашем буфере.

mpu

Пакет нулевого размера все равно использует полосу пропускания. В сетях ethernet, любой пакет имеет размер не менее 64 байт. MPU задает минимальное количество токенов для пакета.

rate

Ограничение скорости.

Если буфер заполнен токенами, то поступающие пакеты будут проходить очередь без всяких задержек. Если вас это не устраивает, используйте следующие параметры:

peakrate

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

Параметр peakrate задает скорость, с которой элемент может проходить очередь. Согласно теории, это достигается организацией достаточной задержки между проходящими пакетами.

mtu/minburst

Очевидно, что максимальное значение peakrate, равное 1 Мбит/сек, накладывало бы сильное ограничение на область применения этой дисциплины. Однако, задание больших значений peakrate возможно. Достигается это за счет прохождения за один интервал времени более одного пакета данных.

По умолчанию, значение mtu равно одному пакету, т.е. за раз проходит только один пакет.

Для расчета максимально возможного значения peakrate, умножьте mtu на 100 (или, точнее, на HZ, которое равно 100 для платформы Intel и 1024 для Alpha)

9.2.2.2. Пример конфигурации

Простая, но очень полезная конфигурация:

# tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540          
          
Чем же она так замечательна? Если у вас есть сетевое устройство с большой очередью, такое как DSL или кабельный модем, а вы обмениваетесь с ним данными через быстрое соединение, например ethernet, вы обнаружите, что закачки полностью уничтожают возможность интерактивной работы.

Это связано с тем, что закачки заполняют очередь модема, которая часто очень большая. Большой размер очереди позволяет достичь хороших результатов при передаче больших объемов данных, но ведь это не совсем то, что вам нужно. Вы хотите, чтобы оставалась интерактивность и вы могли бы делать еще что-то полезное во время закачки.

Приведенная команда ограничивает скорость отправки данных так, чтобы очередь в модеме не образовывалась. Таким образом, очередь будет находится в Linux, где мы можем контролировать ее размер.

Замените 220 Кбит на реальную скорость, минус несколько процентов. Если у вас действительно быстрый модем, можете немного увеличить параметр burst.

9.2.3. Stochastic Fairness Queueing.

Stochastic Fairness Queueing (SFQ) -- простая реализация семейства алгоритмов справедливой очередизации. Она не так точна, как другие дисциплины, но требует меньше рассчетов, и при этом поровну распределяет доступную полосу пропускания между сеансами.

Ключевым понятием в SFQ является диалог (или поток), который приблизительно соответствует сеансу TCP или потоку UDP. Трафик делится на достаточное количество очередей типа FIFO, по одной на каждый диалог. После этого, все очереди обрабатываются в циклическом порядке, тем самым обеспечивая каждому сеансу равные шансы на передачу данных.

Благодаря этому достигается очень ровное поведение, которое не позволяет какому-либо диалогу подавлять остальные. SFQ называется "стохастической", т.к. на самом деле для каждого сеанса очередь не формируется, а трафик делится на ограниченое количество очередей на основе хеш-алгоритма.

Из-за использования хеша, несколько сессий могут попасть в одну и ту же очередь, что уменьшает шансы на передачу каждого сеанса. Для того, чтобы эта проблема не ощущалась, SFQ часто меняет алгоритм хеширования, поэтому, если сессии и попадут в одну очередь, длиться это будет лишь несколько секунд.

Стоит заметить, что SFQ эффективен только если исходящий интерфейс полностью загружен! В противном случае очередь будет отсутствовать и, следовательно, никакого положительного эффекта наблюдаться не будет. Позже мы рассмотрим варианты комбинирования SFQ с другими дисциплинами для достижения наилучшего результата.

В частности, применение SFQ на ethernet интерфейсе к которому подключен кабельный модем или DSL маршрутизатор совершенно бессмыслено без органичения полосы пропускания!

9.2.3.1. Параметры и использование

SFQ в значительной степени самоконфигурирующаяся:

perturb

Интервал изменения алгоритма хеширования. Если не задан -- алгоритм меняться не будет, что не рекомендуется. Хорошим значением является 10 секунд.

quantum

Количество байт выводимых из очереди за один раз. По-умолчанию равно 1 пакету максимально возможного размера (MTU). Не устанавливайте этот параметр меньшим этого значения!

limit

Общее количество пакетов, которые могут быть помещены в очередь SFQ (последующие пакеты будут уничтожаться).

9.2.3.2. Пример конфигурации

Если у вас есть устройство, скорость соединения которого равна доступной полосе пропускания, например модем, следующий пример обеспечит разделение его возможностей между всеми пользователями:

# 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 секунд хеши будут перенастраиваться.