Linux Advanced Routing & Traffic Control HOWTO (Hubert, Graf) - страница 43

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

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